多线程的应用与原理分析6（ReentrantLock）

女爷i 2022-04-23 05:20 176阅读 0赞

> **文章最前**： 我是Octopus，这个名字来源于我的中文名--章鱼；我热爱编程、热爱算法、热爱开源。所有源码在我的个人[github][] ；这博客是记录我学习的点点滴滴，如果您对 Python、Java、AI、算法有兴趣，可以关注我的动态，一起学习，共同进步。

**相关文章：**

1.  [多线程的应用与原理分析1][1]
2.  [多线程的应用与原理分析2（线程的状态）][2]
3.  [多线程的应用与原理分析3（原子性、可见性、有序性）][3]
4.  [多线程的应用与原理分析4（synchronized）][4_synchronized]
5.  [多线程的应用与原理分析5（ReentrantLock）][5_ReentrantLock]
6.  [多线程的应用与原理分析6（ReentrantLock）][6_ReentrantLock]
7.  [多线程的应用与原理分析7（Condition）][7_Condition]
8.  [多线程的应用与原理分析8（countdownlatch）][8_countdownlatch]
9.  [多线程的应用与原理分析9（原子操作）][9]
10. [多线程的应用与原理分析10（Semaphore）][10_Semaphore]
11. [多线程的应用与原理分析11（线程池）][11]

--------------------

** ReentrantLock的实现原理分析**

之所以叫重入锁是因为同一个线程如果已经获得了锁，那么后续该线程调用lock方法时不需要再次获取锁，也就是不会阻塞；重入锁提供了两种实现，一种是非公平的重入锁，另一种是公平的重入锁。怎么理解公平和非公平呢？如果在绝对时间上，先对锁进行获取的请求一定先被满足获得锁，那么这个锁就是公平锁，反之，就是不公平的。简单来说公平锁就是等待时间最长的线程最优先获取锁。  
**非公平锁的实现流程时序图**  
                             ![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3p5MzQ1MjkzNzIx_size_16_color_FFFFFF_t_70][]

**源码分析**

ReentrantLock.lock

public void lock() {
         sync.lock();
    }

这个是获取锁的入口，调用了sync.lock； sync是一个实现了AQS的抽象类，这个类的主要作用是用来实现同步控制的，并且sync有两个实现，一个是NonfairSync(非公平锁)、另一个是FailSync(公平锁)； 我们先来分析一下非公平锁的实现；

NonfairSync.lock

final void lock() {
        if (compareAndSetState(0, 1)) //这是跟公平锁的主要区别,一上来就试探锁是否空闲,如果可以插队，
             //则设置获得锁的线程为当前线程
            //exclusiveOwnerThread属性是AQS从父类AbstractOwnableSynchronizer中继承的属性，用来保存 
            //当前占用
            //同步状态的线程
            setExclusiveOwnerThread(Thread.currentThread());
        else
            acquire(1); //尝试去获取锁
    }

由于ReentrantLock是可重入锁，所以持有锁的线程可以多次加锁，经过判断加锁线程就是当前持有锁的线程时（即  
exclusiveOwnerThread==Thread.currentThread()），即可加锁，每次加锁都会将state的值+1，state等于几，就代表当前持有锁的线程加了几次锁， 解锁时每解一次锁就会将state减1，state减到0后，锁就被释放掉，这时其它线程可以加锁；

AbstractQueuedSynchronizer.acquire  
         如果CAS操作未能成功，说明state已经不为0，此时继续acquire(1)操作,acquire是AQS中的方法 当多个线程同时进入这个方法时，首先通过cas去修改state的状态，如果修改成功表示竞争锁成功，竞争失败的，tryAcquire会返回false；

public final void acquire(int arg) {
        if (!tryAcquire(arg) && acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
            selfInterrupt();
    }

方法的主要作用是  
       Ø 尝试获取独占锁，获取成功则返回，否则；  
       Ø 自旋获取锁，并且判断中断标识，如果中断标识为true，则设置线程中断；  
       Ø addWaiter方法把当前线程封装成Node，并添加到队列的尾部；

NonfairSync.tryAcquire  
        tryAcquire方法尝试获取锁，如果成功就返回，如果不成功，则把当前线程和等待状态信息构适成一个Node节点，并将结点放入同步队列的尾部。然后为同步队列中的当前节点循环等待获取锁，直到成功；

protected final boolean tryAcquire(int acquires) {
         return nonfairTryAcquire(acquires);
    }

nofairTryAcquire

这里可以看非公平锁的涵义，即获取锁并不会严格根据争用锁的先后顺序决定。这里的实现逻辑类似synchroized关键字的偏向锁的做法，即可重入而不用进一步进行锁的竞争，也解释了ReentrantLock中Reentrant的意义；

final boolean nonfairTryAcquire(int acquires) {
        final Thread current = Thread.currentThread();
        int c = getState(); //获取当前的状态，前面讲过，默认情况下是0表示无锁状态
        if (c == 0) {
            if (compareAndSetState(0, acquires)) { //通过cas来改变state状态的值，如果更新成功，表
            示获取锁成功, 这个操作外部方法lock()就做过一次，这里再做只是为了再尝试一次，尽量以最简单的 
            方式获取锁。
                setExclusiveOwnerThread(current);
                return true;
        }
        } else if (current == getExclusiveOwnerThread()) {//如果当前线程等于获取锁的线程，
          //直接累加重入次数
          int nextc = c + acquires;
          if (nextc < 0) // overflow 如果这个状态值越界，抛出异常；如果没有越界，则设置后返回true
          throw new Error("Maximum lock count exceeded");
          setState(nextc);
          return true;
        }
          //如果状态不为0，且当前线程不是owner，则返回false。
         return false; //获取锁失败，返回false
    }

addWaiter  
      当前锁如果已经被其他线程锁持有，那么当前线程来去请求锁的时候，会进入这个方法,这个方法主要是把当前线程  
封装成node，添加到AQS的链表中:

![20190124103101308.png][]

acquireQueued  
      addWaiter返回了插入的节点，作为acquireQueued方法的入参,这个方法主要用于争抢锁  
原来的head节点释放锁以后，会从队列中移除，原来head节点的next节点会成为head节点  
                            ![20190124103225248.png][]

shouldParkAfterFailedAcquire  
       从上面的分析可以看出，只有队列的第二个节点可以有机会争用锁，如果成功获取锁，则此节点晋升为头节点。对于第三个及以后的节点，if (p == head)条件不成立，首先进行shouldParkAfterFailedAcquire(p, node)操作shouldParkAfterFailedAcquire  
方法是判断一个争用锁的线程是否应该被阻塞。它首先判断一个节点的前置节点的状态是否为Node.SIGNAL，如果是，是说明此节点已经将状态设置-如果锁释放，则应当通知它，所以它可以安全的阻塞了，返回true。  
parkAndCheckInterrupt  
       如果shouldParkAfterFailedAcquire返回了true，则会执行：“parkAndCheckInterrupt()”方法，它是通过  
LockSupport.park(this)将当前线程挂起到WATING状态，它需要等待一个中断、unpark方法来唤醒它，通过这样一种FIFO的机制的等待，来实现了Lock的操作；

private final boolean parkAndCheckInterrupt() {
        LockSupport.park(this);// LockSupport提供park()和unpark()方法实现阻塞线程和解除线程阻塞
        return Thread.interrupted();
    }

ReentrantLock.unlock  
       加锁的过程分析完以后，再来分析一下释放锁的过程，调用release方法，这个方法里面做两件事，1，释放锁 ；2，唤醒park的线程；

public final boolean release(int arg) {
        if (tryRelease(arg)) {
            Node h = head;
            if (h != null && h.waitStatus != 0)
                unparkSuccessor(h);
                return true;
            } 
            return false;
    }

tryRelease  
        这个动作可以认为就是一个设置锁状态的操作，而且是将状态减掉传入的参数值（参数是1），如果结果状态为0，就将排它锁的Owner设置为null，以使得其它的线程有机会进行执行。 在排它锁中，加锁的时候状态会增加1（当然可以自己修改这个值），在解锁的时候减掉1，同一个锁，在可以重入后，可能会被叠加为2、3、4这些值，只有unlock()的次数与lock()的次数对应才会将Owner线程设置为空，而且也只有这种情况下才会返回true。  
LockSupport  
        LockSupport类是Java6引入的一个类，提供了基本的线程同步原语。LockSupport实际上是调用了Unsafe类里的  
函数，归结到Unsafe里，只有两个函数：

public native void unpark(Thread jthread);
    public native void park(boolean isAbsolute, long time);

unpark函数为线程提供“许可(permit)”，线程调用park函数则等待“许可”。这个有点像信号量，但是这个“许可”是不能叠加的，“许可”是一次性的。在使用LockSupport之前，我们对线程做同步，只能使用wait和notify，但是wait和notify其实不是很灵活，并且耦合性很高，调用notify必须要确保某个线程处于wait状态，而park/unpark模型真正解耦了线程之间的同步，先后顺序没有没有直接关联，同时线程之间不再需要一个Object或者其它变量来存储状态，不再需要关心对方的状态。

分析了独占式同步状态获取和释放过程后，做个简单的总结：在获取同步状态时，同步器维护一个同步队列，获取状态失败的线程都会被加入到队列中并在队列中进行自旋；移出队列（或停止自旋）的条件是前驱节点为头节点且成功获取了同步状态。在释放同步状态时，同步器调用tryRelease(int arg)方法释放同步状态，然后唤醒头节点的后继节点。

公平锁和非公平锁的区别  
        锁的公平性是相对于获取锁的顺序而言的，如果是一个公平锁，那么锁的获取顺序就应该符合请求的绝对时间顺序，也就是FIFO。 在上面分析的例子来说，只要CAS设置同步状态成功，则表示当前线程获取了锁，而公平锁则不一样，差异点有两个；

FairSync.tryAcquire

final void lock() {
        acquire(1);
    }

非公平锁在获取锁的时候，会先通过CAS进行抢占，而公平锁则不会  
FairSync.tryAcquire  
        这个方法与nonfairTryAcquire(int acquires)比较，不同的地方在于判断条件多了hasQueuedPredecessors()方法，也就是加入了\[同步队列中当前节点是否有前驱节点\]的判断，如果该方法返回true，则表示有线程比当前线程更早地请求获取锁，因此需要等待前驱线程获取并释放锁之后才能继续获取锁。

[github]: https://github.com/zhangyu345293721
[1]: https://blog.csdn.net/zy345293721/article/details/86565631
[2]: https://blog.csdn.net/zy345293721/article/details/86583663
[3]: https://blog.csdn.net/zy345293721/article/details/86596268
[4_synchronized]: https://blog.csdn.net/zy345293721/article/details/86607632
[5_ReentrantLock]: https://blog.csdn.net/zy345293721/article/details/86617801
[6_ReentrantLock]: https://blog.csdn.net/zy345293721/article/details/86621392
[7_Condition]: https://blog.csdn.net/zy345293721/article/details/86622891
[8_countdownlatch]: https://blog.csdn.net/zy345293721/article/details/86636846
[9]: https://blog.csdn.net/zy345293721/article/details/86645245
[10_Semaphore]: https://blog.csdn.net/zy345293721/article/details/86644996
[11]: https://blog.csdn.net/zy345293721/article/details/86646019
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3p5MzQ1MjkzNzIx_size_16_color_FFFFFF_t_70]: /images/20220323/79ae57223f084fd38c493f8595d2397d.png
[20190124103101308.png]: /images/20220323/0a0db32826a0466a84167fc4398a2793.png
[20190124103225248.png]: /images/20220323/0a07d838a7834eb9838dfe7518cf42cd.png