Java锁

为解决程序中多个进程和线程对资源的抢占问题，在 Java 中引入了锁的概念

公平锁/非公平锁、
可重入锁/不可重入锁、
共享锁/排他锁、
乐观锁/悲观锁、
分段锁、
偏向锁/轻量级锁/重量级锁、
自旋锁

---

程序中常用

synchronized，ReentrantLock，ReentrantReadWriteLock。

ReentrantLock

Jdk1.5新增的ReentrantLock类和synchronized关键字一样可以实现线程间同步互斥，但是它在拓展功能上更加强大，比如嗅探锁定、多路分支等功能，使用的时候也比synchronized更加灵活。

使用Condition对象可以实现类似synchronized的wait()/notify()/notifyAll()同样的功能。Condition有更好的灵活性，比如可以实现多路通知功能，也就是在一个Lock对象中创建多个Condition（即对象监视器）实例，线程对象可以注册在指定的Condition中，从而可以有选择性的进行线程通知，在调度线程上更加灵活。

在使用notify()/notifyAll()方法进行通知时，被通知的线程是由JVM随机选择的，但是使用ReentrantLock和Condition可以实现“选择性通知”，这个功能是非常重要的，而且在Condition类时默认提供的。

而synchronized就相当于整个Lock对象中只有一个单一的Condition对象，所有的线程都注册在它一个对象身上，线程开始notifyAll时，需要通知所有的waiting线程，没有选择权，会出现相当大的效率问题。

signal()和signalAll()区别

signalAll通知所有使用了同一个Condition对象的线程。signal()通知所有使用了Condition对象的某一个线程，通过源码可以看到通知的线程是位于队首的那个。

image.png

公平和非公平锁

• 公平锁表示线程获取锁顺序是按照线程加锁的顺序来分配的，即FIFO顺序。
• 非公平锁就是一种获取锁的抢占机制，是随机获得锁的。有可能后申请的线程比先申请的线程优先获取锁，可能会造成优先级反转或者饥饿现象。

在公平的锁中，如果有另一个线程持有锁或者有其他线程在等待队列中等待这个所，那么新发出的请求的线程将被放入到队列中。

而非公平锁上，只有当锁被某个线程持有时，新发出请求的线程才会被放入队列中。

ReentrantLock的构造函数中，默认的无参构造函数将会把Sync对象创建为NonfairSync对象，这是一个“非公平锁”；

而另一个构造函数ReentrantLock(boolean fair)传入参数为true时将会把Sync对象创建为“公平锁”FairSync。

nonfairTryAcquire(int acquires)方法，对于非公平锁，只要CAS设置同步状态成功，则表示当前线程获取了锁，而公平锁则不同。

tryAcquire方法，该方法与nonfairTryAcquire(int acquires)比较，唯一不同的位置为判断条件多了hasQueuedPredecessors()方法，即加入了同步队列中当前节点是否有前驱节点的判断，如果该方法返回true，则表示有线程比当前线程更早地请求获取锁，因此需要等待前驱线程获取并释放锁之后才能继续获取锁。

可重入锁和不可重入锁

可重入锁又名递归锁，直指同一个线程在外层方法获得锁之后，在进入内层方法时，会自动获得锁。
ReentrantLock和Synchronized都是可重入锁。可重入锁的好处之一就是在一定程度上避免死锁

共享锁和独享锁

• 共享锁也叫S锁，读锁，该锁可以被多个线程持有；
• 独享锁也叫X锁，写锁，排他锁，该锁只能被一个线程持有。

共享锁【S锁】

若事务T对数据对象A加上S锁，则事务T可以读A但不能修改A，其他事务只能再对A加S锁，而不能加X锁，直到T释放A上的S锁。这保证了其他事务可以读A，但在T释放A上的S锁之前不能对A做任何修改。

排他锁【X锁】

又称写锁。若事务T对数据对象A加上X锁，事务T可以读A也可以修改A，其他事务不能再对A加任何锁，直到T释放A上的锁。这保证了其他事务在T释放A上的锁之前不能再读取和修改A。

对于ReentrantLock和Synchronized而言，是独享锁，读读、读写、写写的过程都是互斥的。对于ReadWriteLock而言，读锁是共享锁，写锁是独享锁，读锁的共享锁可以保证并发读是非常高效的，在读写锁中，读读不互斥、读写、写写的过程是互斥的。独享锁与共享锁也是通过AQS来实现的，通过实现不同的方法，来实现独享或者共享。

乐观锁与悲观锁

悲观锁：是认为别的线程会修改值。
独占锁是一种悲观锁，synchronized就是一种独占锁。synchronized加锁后就能够确保程序执行时不会被其它线程干扰，得到正确的结果。

乐观锁：本质上是乐观的，认为别的线程不会去修改值。如果发现值被修改了，可以再次重试。CAS机制（Compare And Swap）就是一种乐观锁。

死锁

两个或两个以上的进程在执行过程中，
由于竞争资源或者由于彼此通信而造成的一种阻塞的现象，
若无外力作用，它们都将无法推进下去。
此时称系统处于死锁状态或系统产生了死锁。

死锁的发生必须具备以下四个必要条件。

• 1）互斥条件：指进程对所分配到的资源进行排它性使用，即在一段时间内某资源只由一个进程占用。如果此时还有其它进程请求资源，则请求者只能等待，直至占有资源的进程用毕释放。

• 2）请求和保持条件：指进程已经保持至少一个资源，但又提出了新的资源请求，而该资源已被其它进程占有，此时请求进程阻塞，但又对自己已获得的其它资源保持不放。

• 3）不剥夺条件：指进程已获得的资源，在未使用完之前，不能被剥夺，只能在使用完时由自己释放。

• 4）环路等待条件：指在发生死锁时，必然存在一个进程——资源的环形链，即进程集合{P0，P1，P2，···，Pn}中的P0正在等待一个P1占用的资源；P1正在等待P2占用的资源，……，Pn正在等待已被P0占用的资源。

只要打破四个必要条件之一就能有效预防死锁的发生。

• 打破互斥条件：改造独占性资源为虚拟资源，大部分资源已无法改造。

• 打破不可抢占条件：当一进程占有一独占性资源后又申请一独占性资源而无法满足，则退出原占有的资源。

• 打破占有且申请条件：采用资源预先分配策略，即进程运行前申请全部资源，满足则运行，不然就等待，这样就不会占有且申请。

• 打破循环等待条件：实现资源有序分配策略，对所有设备实现分类编号，所有进程只能采用按序号递增的形式申请资源。
  避免死锁常见的算法有有序资源分配法、银行家算法。

总结：

• 死锁是必然发生在多操作者（M>=2个）情况下，争夺多个资源（N>=2个，且N<=M）才会发生这种情况。

• 很明显，单线程自然不会有死锁。

• 单资源呢？不会产生死锁。

• 同时，死锁还有几个要求
  1、争夺资源的顺序不对，如果争夺资源的顺序是一样的，也不会产生死锁；
  2、争夺者拿到资源不放手

活锁

• 两个线程在尝试拿锁的机制中，发生多个线程之间互相谦让，不断发生同一个线程总是拿到同一把锁，在尝试拿另一把锁时因为拿不到，而将本来已经持有的锁释放的过程。

• 解决办法：每个线程休眠随机数，错开拿锁的时间。

线程饥饿

低优先级的线程，总是拿不到执行时间

各种锁

自旋锁

• 原理
  自旋锁原理非常简单，如果持有锁的线程能在很短时间内释放锁资源，那么那些等待竞争锁的线程就不需要做内核态和用户态之间的切换进入阻塞挂起状态，它们只需要等一等（自旋），等持有锁的线程释放锁后即可立即获取锁，这样就避免用户线程和内核的切换的消耗。
  但是线程自旋是需要消耗CPU的，说白了就是让CPU在做无用功，线程不能一直占用CPU自旋做无用功，所以需要设定一个自旋等待的最大时间。

如果持有锁的线程执行的时间超过自旋等待的最大时间扔没有释放锁，就会导致其它争用锁的线程在最大等待时间内还是获取不到锁，这时争用线程会停止自旋进入阻塞状态。

• 自旋锁的优缺点
  自旋锁尽可能的减少线程的阻塞，这对于锁的竞争不激烈，且占用锁时间非常短的代码块来说性能能大幅度的提升，因为自旋的消耗会小于线程阻塞挂起操作的消耗！
  但是如果锁的竞争激烈，或者持有锁的线程需要长时间占用锁执行同步块，这时候就不适合使用自旋锁了，因为自旋锁在获取锁前一直都是占用cpu做无用功，占着XX不XX，线程自旋的消耗大于线程阻塞挂起操作的消耗，其它需要cup的线程又不能获取到cpu，造成cpu的浪费。

• 自旋锁时间阈值
  自旋锁的目的是为了占着CPU的资源不释放，等到获取到锁立即进行处理。但是如何去选择自旋的执行时间呢？如果自旋执行时间太长，会有大量的线程处于自旋状态占用CPU资源，进而会影响整体系统的性能。因此自旋次数很重要
  JVM对于自旋次数的选择，jdk1.5默认为10次，在1.6引入了适应性自旋锁，适应性自旋锁意味着自旋的时间不在是固定的了，而是由前一次在同一个锁上的自旋时间以及锁的拥有者的状态来决定，基本认为一个线程上下文切换的时间是最佳的一个时间。
  JDK1.6中-XX:+UseSpinning开启自旋锁； JDK1.7后，去掉此参数，由jvm控制；

锁的状态

一共有四种状态：
无锁状态，偏向锁状态，轻量级锁状态和重量级锁状态

它会随着竞争情况逐渐升级。锁可以升级但不能降级，目的是为了提高获得锁和释放锁的效率。

• 偏向锁
  引入背景：大多数情况下锁不仅不存在多线程竞争，而且总是由同一线程多次获得，为了让线程获得锁的代价更低而引入了偏向锁，减少不必要的CAS操作。
  偏向锁，顾名思义，它会偏向于第一个访问锁的线程，如果在运行过程中，同步锁只有一个线程访问，不存在多线程争用的情况，则线程是不需要触发同步的，减少加锁／解锁的一些CAS操作（比如等待队列的一些CAS操作），这种情况下，就会给线程加一个偏向锁。 如果在运行过程中，遇到了其他线程抢占锁，则持有偏向锁的线程会被挂起，JVM会消除它身上的偏向锁，将锁恢复到标准的轻量级锁。它通过消除资源无竞争情况下的同步原语，进一步提高了程序的运行性能。

• 偏向锁获取过程：
  步骤1、 访问Mark Word中偏向锁的标识是否设置成1，锁标志位是否为01，确认为可偏向状态。
  步骤2、 如果为可偏向状态，则测试线程ID是否指向当前线程，如果是，进入步骤5，否则进入步骤3。
  步骤3、 如果线程ID并未指向当前线程，则通过CAS操作竞争锁。如果竞争成功，则将Mark Word中线程ID设置为当前线程ID，然后执行5；如果竞争失败，执行4。
  步骤4、 如果CAS获取偏向锁失败，则表示有竞争。当到达全局安全点（safepoint）时获得偏向锁的线程被挂起，偏向锁升级为轻量级锁，然后被阻塞在安全点的线程继续往下执行同步代码。（撤销偏向锁的时候会导致stop the word）

步骤5、 执行同步代码。

image.png

CAS （Compare And Swap）

乐观锁的一种实现方式

CAS基本原理

• 什么是原子操作？
  假定有两个操作A和 B（A和B可能都很复杂），如果从执行A的线程来看，当另一个线程执行B时，要么将B全部执行完，要么完全不执行B，那么A和B对彼此来说是原子的。

• 如何实现原子操作？

1、实现原子操作可以使用锁，锁机制，满足基本的需求是没有问题的了，

但是有的时候我们的需求并非这么简单，我们需要更有效，更加灵活的机制，synchronized关键字是基于阻塞的锁机制，也就是说当一个线程拥有锁的时候，访问同一资源的其它线程需要等待，直到该线程释放锁。

这里会有些问题:
首先，如果被阻塞的线程优先级很高很重要怎么办？其次，如果获得锁的线程一直不释放锁怎么办？（这种情况是非常糟糕的）。

还有一种情况，如果有大量的线程来竞争资源，那 CPU将会花费大量的时间和资源来处理这些竞争，同时，还有可能出现一些例如死锁之类的情况，最后，其实锁机制是一种比较粗糙，粒度比较大的机制，相对于像计数器这样的需求有点儿过于笨重。

2、实现原子操作还可以使用当前的处理器基本都支持 CAS（）的指令

只不过每个厂家所实现的算法并不一样，每一个CAS操作过程都包含三个运算符: 一个内存地址V，一个期望的值A和一个新值B，操作的时候如果这个地址上存放的值等于这个期望的值A，则将地址上的值赋为新值B，否则不做任何操作。

CAS 的基本思路：
如果这个地址上的值和期望的值相等，则给其赋予新值，否则不做任何事儿，但是要返回原值是多少。循环 CAS 就是在一个循环里不断的做cas操作，直到成功为止。

image.png image.png

CAS实现原子操作的三大问题

ABA问题。

因为 CAS 需要在操作值的时候，检查值有没有发生变化，如果没有发生变化则更新，但是如果一个值原来是A，变成了B，又变成了A，那么使用 CAS 进行检查时会发现它的值没有发生变化，但是实际上却变化了。

ABA问题的解决思路就是使用版本号。在变量前面追加上版本号，每次变量更新的时候把版本号加1，那么A→B→A就会变成1A一2B一3A。

举个通俗点的例子，你倒了一杯水放桌子上，干了点别的事，然后同事把你水喝了又给你重新倒了一杯水，你回来看水还在，拿起来就喝，如果你不管水中间被人喝过，只关心水还在，这就是ABA问题。

如果你是一个讲卫生讲文明的小伙子，不但关心水在不在，还要在你离开的时候水被人动过没有，因为你是程序员，所以就想起了放了张纸在旁边，写上初始值0，别人喝水前麻烦先做个累加才能喝水。

循环时间长开销大。

自旋 CAS 如果长时间不成功，会给CPU带来非常大的执行开销。

如果JVM能支持处理器提供的pause指令那么效率会有一定的提升，pause指令有两个作用，第一它可以延迟流水线执行指令（de-pipeline）,使CPU不会消耗过多的执行资源，延迟的时间取决于具体实现的版本，在一些处理器上延迟时间是零。第二它可以避免在退出循环的时候因内存顺序冲突（memory order violation）而引起CPU流水线被清空（CPU pipeline flush），从而提高CPU的执行效率。

只能保证一个共享变量的原子操作。

当对一个共享变量执行操作时，我们可以使用循环 CAS 的方式来保证原子操作，但是对多个共享变量操作时，循环 CAS 就无法保证操作的原子性，这个时候就可以用锁。

还有一个取巧的办法，就是把多个共享变量合并成一个共享变量来操作。比如，有两个共享变量j=2，j=a，合并一下 i=2a，然后用 CAS 来操作i。

从Java 1.5开始，JDK提供了AtomicReference类来保证引用对象之间的原子性，就可以把多个变量放在一个对象里来进行 CAS操作。

JDK中相关原子操作类的使用

AtomicInteger

• int addAndGet（int delta）:以原子方式将输入的数值与实例中的值Atomiclnteger里的value）相加，并返回结果。

• boolean compareAndSet（int expect， int update）:如果输入的数值等于预期值，则以原子方式将该值设置为输入的值。

• int getAndIncrement（）:以原子方式将当前值加1，注意，这里返回的是自增前的值。

• int getAndSet （int newValue）:以原子方式设置为newValue的值，并返回旧值。

AtomicIntegerArray

主要是提供原子的方式更新数组里的整型，其常用方法如下。《

• int addAndGet （int i， int delta）:以原子方式将输入值与数组中索引 i 的元素相加。
• boolean compareAndSet（int j， int expect， int update）:如果当前值等于预期值，则以原子方式将数组位置的元素设置成update值。
  需要注意的是，数组 value通过构造方法传递进去，然后
  AtomicIntegerArray 会将当前数组复制一份，所以当AtomicIntegerArray对内部的数组元素进行修改时，不会影响传入的数组。

原子更新引用类型

原子更新基本类型的AtomicInteger，只能更新一个变量，如果要原子更新多个变量，就需要使用这个原子更新引用类型提供的类。

---

Atomic包提供了以下3个类。

AtomicReference<V> 原子更新引用类型

AtomicStampedReference 利用版本戳的形式记录了每次改变以后的版本号，这样的话就不会存在ABA问题了。这就是AtomicStampedReference的解决方案。

AtomicMarkableReference跟 AtomicStampedReference差不多，
AtomicStampedReference是使用 pair 的 int stamp作为计数器使用，

AtomicMarkableReference 的 pair 使用的是boglean mark。还是那个水的例子，AtomicStamRedReference可能关心的是动过几次,AtomicMarkableReference关心的是有没有被人动过，方法都比较简单。

AtomicMarkableReference:
原子更新带有标记位的引用类型。可以原子更新一个布尔类型的标记位和引用类型。构造方法是

public AtomicMarkableReference(V initialRef, boolean initialMark) {
        this.pair = AtomicMarkableReference.Pair.of(initialRef, initialMark);
}