ReentrantLock-AQS源码分析

Posted 洛雪_

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了ReentrantLock-AQS源码分析相关的知识,希望对你有一定的参考价值。

说起AQS,就不得不说经典类ReentrantLock,是AQS的最好体现
不过可以先简单说下AQS特性

什么是AQS?

抽象的队列式同步器

​ 把所有请求线程构成一个CLH队列,当一个线程执行完毕lock.unlock时会激活自己后续节点,正在执行的线程不在队列中,等待执行的线程全部处于阻塞状态
​ 先通过CAS尝试获取锁。如果此时已经有线程占据了锁,那就加入CLH队列 队尾并且被挂起 自旋。当锁被释放之后,排在CLH队列队首的线程会被唤醒,然后CAS再次尝试获取锁。在这个时候,如果:

  1. 非公平锁:如果同时还有另一个线程进来尝试获取,那么有可能会让这个线程抢先获取;

  2. 公平锁:如果同时还有另一个线程进来尝试获取,当它发现自己不是在队首的话,就会排到队尾,由队首的线程获取到锁。

    AQS维护一个共享资源volatile的整型变量state,通过内置的FIFO来完成获取资源线程的排队工作。(这个内置的同步队列称为"CLH"队列:带头节点的双向非循环链表)。该队列由一个一个的Node结点组成,每个Node结点维护一个prev引用和next引用,分别指向自己的前驱和后继结点。AQS维护两个指针,分别指向队列头部head和尾部tail。

其他使用场景

​ 我们常用的CountDownLatch、ReentrantLock、Semaphore等类都是在内部定义了一个叫做Sync的内部类,而Sync类继承了AQS抽象类并重写了一些必要的方法

可重入锁ReentrantLock中,state可以用来表示当前线程获取锁的可重入次数;对于读写锁

ReentrantReadWriteLock来说,state的高16位表示获取到的读锁的线程的可重入次数,低16位是写锁;

对于Semaphore来说,state用来表示当前可用信号的个数

对于CountDownlatch来说,state用来表示计数器当前的值

两种同步方式(底层支撑)

1.独占式

ReentrantLock

互斥

2.共享式

CountDownLatch,ReadWriteLock

允许多线程读

自定义同步器

继承AbstractQueuedSynchronizer类

重写对应方法

在我们的组件中调用AQS模板方法

AQS的等待队列如图

不包含head,后面的才是阻塞队列

一般我们使用ReentrantLock的方式是这样的

public class OrderService 
    // 使用static,这样每个线程拿到的是同一把锁,当然,spring mvc中service默认就是单例,别纠结这个  true代表了公平锁的写法
    private static ReentrantLock reentrantLock = new ReentrantLock(true);

    public void createOrder() 
        // 比如我们同一时间,只允许一个线程创建订单
        reentrantLock.lock();
        // 通常,lock 之后紧跟着 try 语句
        try 
            // 这块代码同一时间只能有一个线程进来(获取到锁的线程),
            // 其他的线程在lock()方法上阻塞,等待获取到锁,再进来
            // 执行代码...
         finally 
            // 释放锁
            reentrantLock.unlock();
        
    

下面以公平锁的方式解析下源码

先看下都有哪些属性

// 头结点,你直接把它当做 当前持有锁的线程 可能是最好理解的
private transient volatile Node head;

// 阻塞的尾节点,每个新的节点进来,都插入到最后,也就形成了一个链表
private transient volatile Node tail;

// 这个是最重要的,代表当前锁的状态,0代表没有被占用,大于 0 代表有线程持有当前锁
// 这个值可以大于 1,是因为锁可以重入,每次重入都加上 1
private volatile int state;

// 代表当前持有独占锁的线程,举个最重要的使用例子,因为锁可以重入
// reentrantLock.lock()可以嵌套调用多次,所以每次用这个来判断当前线程是否已经拥有了锁
// if (currentThread == getExclusiveOwnerThread()) state++
private transient Thread exclusiveOwnerThread; //继承自AbstractOwnableSynchronizer
static final class FairSync extends Sync 
    private static final long serialVersionUID = -3000897897090466540L;
    //争锁
    final void lock() 
        acquire(1);
    

public final void acquire(int arg) 
        if (!tryAcquire(arg) &&
        //如果tryAcquire(arg) 返回true, 也就结束了;否则,acquireQueued方法会将线程压到队列中
        //因为有可能直接就成功了,也就不需要进队列排队;对于公平锁的语义就是:本来就没人持有锁,根本没必要进队列等待(又是挂起,又是等待被唤醒的
        //tryAcquire(arg)没有成功,这个时候需要把当前线程挂起,放到阻塞队列中。
            acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
            selfInterrupt();
    

tryAcquire是这样的

    protected final boolean tryAcquire(int acquires) 
        final Thread current = Thread.currentThread();
        int c = getState();
        //state == 0 此时此刻没有线程持有锁
        if (c == 0) 
            //锁可用,因为是公平锁,查看是否有其他人已经在等待
            if (!hasQueuedPredecessors() &&
                //没有则cas尝试获取锁,如果获取不到则证明并发获取了;
                compareAndSetState(0, acquires)) 
                    //获取到锁,标记
                setExclusiveOwnerThread(current);
                return true;
            
        
        //如果和标记的线程一致,则锁重入了,state+1
        else if (current == getExclusiveOwnerThread()) 
            int nextc = c + acquires;
            if (nextc < 0)
                throw new Error("Maximum lock count exceeded");
            setState(nextc);
            return true;
        
        return false;
    
//此时没有获取到锁
    // 此方法的作用是把线程包装成node,同时进入到队列中
    // 参数mode此时是Node.EXCLUSIVE,代表独占模式
    private Node addWaiter(Node mode) 
        Node node = new Node(Thread.currentThread(), mode);
        // 以下几行代码想把当前node加到链表的最后面去,也就是进到阻塞队列的最后
        Node pred = tail;

        // tail!=null => 队列不为空(tail==head的时候,其实队列是空的,不过不管这个吧)
        if (pred != null)  
            // 将当前的队尾节点,设置为自己的前驱 
            node.prev = pred; 
            // 用CAS把自己设置为队尾, 如果成功后,tail == node 了,这个节点成为阻塞队列新的尾巴
            if (compareAndSetTail(pred, node))  
                // 进到这里说明设置成功,当前node==tail, 将自己与之前的队尾相连,
                // 上面已经有 node.prev = pred,加上下面这句,也就实现了和之前的尾节点双向连接了
                pred.next = node;
                // 线程入队了,可以返回了
                return node;
            
        
        // 仔细看看上面的代码,如果会到这里,
        // 说明 pred==null(队列是空的) 或者 CAS失败(有线程在竞争入队)
        enq(node);
        return node;
    
// 采用自旋的方式入队
    // 之前说过,到这个方法只有两种可能:等待队列为空,或者有线程竞争入队,
    // 自旋在这边的语义是:CAS设置tail过程中,竞争一次竞争不到,我就多次竞争,总会排到的
    private Node enq(final Node node) 
        for (;;) 
            Node t = tail;
            // 如果队列为空
            if (t == null)  // Must initialize
                // 初始化head节点
                // 细心的读者会知道原来 head 和 tail 初始化的时候都是 null 的
                // 还是一步CAS,你懂的,现在可能是很多线程同时进来呢
                if (compareAndSetHead(new Node()))
                    // 给后面用:这个时候head节点的waitStatus==0, 看new Node()构造方法就知道了

                    // 这个时候有了head,但是tail还是null,设置一下,
                    // 把tail指向head,放心,马上就有线程要来了,到时候tail就要被抢了
                    // 注意:这里只是设置了tail=head,这里可没return哦,没有return,没有return
                    // 所以,设置完了以后,继续for循环,下次就到下面的else分支了
                    tail = head;
             else 
                // 下面几行,和上一个方法 addWaiter 是一样的,
                // 只是这个套在无限循环里,反正就是将当前线程排到队尾,有线程竞争的话排不上重复排
                node.prev = t;
                if (compareAndSetTail(t, node)) 
                    t.next = node;
                    return t;
                
            
        
    
// 回到这段代码了,该看acquireQueued了
    // if (!tryAcquire(arg) 
    //        && acquireQueued(addWaiter(Node.EXCLUSIVE), arg)) 
    //     selfInterrupt();    
    
    // 下面这个方法,参数node,没有获取到锁,且经过addWaiter(Node.EXCLUSIVE),此时已经进入阻塞队列
    // 注意一下:如果acquireQueued(addWaiter(Node.EXCLUSIVE), arg))返回true的话,
    // 意味着上面这段代码将进入selfInterrupt(),所以正常情况下,下面应该返回false
    // 这个方法非常重要,应该说真正的线程挂起,然后被唤醒后去获取锁,都在这个方法里了
    final boolean acquireQueued(final Node node, int arg) 
        boolean failed = true;
        try 
            boolean interrupted = false;
            for (;;) 
                //获取到前驱节点
                final Node p = node.predecessor();
                // p == head 说明当前节点虽然进到了阻塞队列,但是是阻塞队列的第一个,因为它的前驱是head
                // 注意,阻塞队列不包含head节点,head一般指的是占有锁的线程,head后面的才称为阻塞队列
                // 所以当前节点可以去试抢一下锁
                // 这里我们说一下,为什么可以去试试:
                // 首先,它是队头,这个是第一个条件,其次,当前的head有可能是刚刚初始化的node,
                // enq(node) 方法里面有提到,head是延时初始化的,而且new Node()的时候没有设置任何线程
                // 也就是说,当前的head不属于任何一个线程,所以作为队头,可以去试一试,
                // tryAcquire已经分析过了, 忘记了请往前看一下,就是简单用CAS试操作一下state
                if (p == head && tryAcquire(arg)) 
                    setHead(node);
                    p.next = null; // help GC
                    failed = false;
                    return interrupted;
                
                // 到这里,说明上面的if分支没有成功,要么当前node本来就不是队头,
                // 要么就是tryAcquire(arg)没有抢赢别人
                if (shouldParkAfterFailedAcquire(p, node) &&
                    parkAndCheckInterrupt())
                    interrupted = true;
            
         finally 
            // 什么时候 failed 会为 true?-->  tryAcquire() 方法抛异常的情况
            if (failed)
                cancelAcquire(node);
        
    
// 刚刚说过,会到这里就是没有抢到锁,这个方法说的是:"当前线程没有抢到锁,是否需要挂起当前线程?"
    // 第一个参数是前驱节点,第二个参数才是代表当前线程的节点
    private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) 
        int ws = pred.waitStatus;
        // 前驱节点的 waitStatus == -1 ,说明前驱节点状态正常,当前线程需要挂起,直接可以返回true
        if (ws == Node.SIGNAL)
            return true;

        // 前驱节点 waitStatus大于0 ,之前说过,大于0 说明前驱节点取消了排队。
        // 这里需要知道这点:进入阻塞队列排队的线程会被挂起,而唤醒的操作是由前驱节点完成的。
        // 所以下面这块代码说的是将当前节点的prev指向waitStatus<=0的节点,
        // 简单说,就是为了找个好爹,因为你还得依赖它来唤醒呢,如果前驱节点取消了排队,
        // 找前驱节点的前驱节点做爹,往前遍历总能找到一个好爹的
        if (ws > 0) 
            do 
                node.prev = pred = pred.prev;
             while (pred.waitStatus > 0);
            pred.next = node;
         else 
            // 仔细想想,如果进入到这个分支意味着什么
            // 前驱节点的waitStatus不等于-1和1,那也就是只可能是0,-2,-3
            // 在我们前面的源码中,都没有看到有设置waitStatus的,所以每个新的node入队时,waitStatu都是0
            // 正常情况下,前驱节点是之前的 tail,那么它的 waitStatus 应该是 0
            // 用CAS将前驱节点的waitStatus设置为Node.SIGNAL(也就是-1)
            compareAndSetWaitStatus(pred, ws, Node.SIGNAL);
        
        // 这个方法返回 false,那么会再走一次 for 循序,
        //     然后再次进来此方法,此时会从第一个分支返回 true
        return false;
    
//挂起
    private final boolean parkAndCheckInterrupt() 
        LockSupport.park(this);
        return Thread.interrupted();
    

分析:如果shouldParkAfterFailedAcquire返回true,则会parkAndCheckInterrupt挂起
如果返回false(第一次ws一定是0,因为前面没有设置,compareAndSetWaitStatus(pred, ws, Node.SIGNAL)设置后,依赖上面的自旋
再次进入status才为-1,返回true)
为什么shouldParkAfterFailedAcquire(p, node)返回false的时候不直接挂起线程?
=> 是为了应对在经过这个方法后,node已经是head的直接后继节点了??。

下面看下如何释放锁

    public final boolean release(int arg) 
        //修改锁计数器,如果计数器为0,说明锁被释放
        if (tryRelease(arg)) 
            Node h = head;
            //head节点的waitStatus不等于0,说明head节点的后继节点对应的线程,正在阻塞,等待被唤醒
            if (h != null && h.waitStatus != 0)
                //唤醒后继节点
                unparkSuccessor(h);
            return true;
        
        return false;
    
    
    protected final boolean tryRelease(int releases) 
        int c = getState() - releases;
        if (Thread.currentThread() != getExclusiveOwnerThread())
            throw new IllegalMonitorStateException();
        // 是否完全释放锁
        boolean free = false;
        // 其实就是重入的问题,如果c==0,也就是说没有嵌套锁了,可以释放了,否则还不能释放掉
        if (c == 0) 
            free = true;
            setExclusiveOwnerThread(null);
        
        setState(c);
        return free;
    
   
    private void unparkSuccessor(Node node) 
        int ws = node.waitStatus;
        if (ws < 0)
            compareAndSetWaitStatus(node, ws, 0);
        //后继节点
        Node s = node.next;
        // 下面的代码就是唤醒后继节点,但是有可能后继节点取消了等待(waitStatus==1)
        // 从tail队尾往前找,找到waitStatus<=0的所有节点中排在最前面的,期间不break,所以最终s=t是最前面的
        if (s == null || s.waitStatus > 0) 
            s = null;
            for (Node t = tail; t != null && t != node; t = t.prev)
                if (t.waitStatus <= 0)
                    s = t;
        
        if (s != null)
            //唤醒后继节点
            LockSupport.unpark(s.thread);
    

详细的说明已经都在代码中了,暂不做特殊的说明,
在整个过程中cas设置state很重要,那么state代表了什么?

state作用

  • 0:没有线程占有锁
  • cas设置为1,证明获取到了锁
  • 锁重入state+1

过程图上起来




可以看到都是把前驱结点waitStatus设置为-1

好了公平锁大致如此,非公平锁和公平锁有什么区别呢?
公平锁和非公平锁只有两处不同:

  1. 非公平锁在调用 lock 后,首先就会调用 CAS 进行一次抢锁,如果这个时候恰巧锁没有被占用,那么直接就获取到锁返回了。
  2. 非公平锁在 CAS 失败后,和公平锁一样都会进入到 tryAcquire 方法,在 tryAcquire 方法中,如果发现锁这个时候被释放了(state == 0),非公平锁会直接 CAS 抢锁,但是公平锁会判断等待队列是否有线程处于等待状态,如果有则不去抢锁,乖乖排到后面

关于中断

用lockInterruptibly(),内部实现如下

private void doAcquireInterruptibly(int arg) throws InterruptedException 
    final Node node = addWaiter(Node.EXCLUSIVE);
    boolean failed = true;
    try 
        for (;;) 
            final Node p = node.predecessor();
            if (p == head && tryAcquire(arg)) 
                setHead(node);
                p.next = null; // help GC
                failed = false;
                return;
            
            if (shouldParkAfterFailedAcquire(p, node) &&
                parkAndCheckInterrupt())
                // 就是这里了,一旦异常,马上结束这个方法,抛出异常。
                // 这里不再只是标记这个方法的返回值代表中断状态
                // 而是直接抛出异常,而且外层也不捕获,一直往外抛到 lockInterruptibly
                throw new InterruptedException();
        
     finally 
        // 如果通过 InterruptedException 异常出去,那么 failed 就是 true 了
        if (failed)
            cancelAcquire(node);
    

lock本身只是在park的时候相应中断标记了中断标识,调用房需要检查是否中断,而lockInterruptibly在检查后直接抛异常了

响应中断

每个线程都关联了一个中断状态,是一个 true 或 false 的 boolean 值,初始值为 false。
如果线程处于以下三种情况,那么当线程被中断的时候,能自动感知到:

  1. 来自 Object 类的 wait()、wait(long)、wait(long, int),
    方法上都有: throws InterruptedException
    重置中断状态为 false。
  2. 实现了 InterruptibleChannel 接口的类中的一些 I/O 阻塞操作,如 DatagramChannel 中的 connect 方法和 receive 方法等
    抛出 ClosedByInterruptException 并重置中断状态
  3. Selector 中的 select 方法,参考下我写的 NIO 的文章
    一旦中断,方法立即返回
    线程阻塞挂起LockSupport.park(Object obj),中断会导致唤醒,唤醒后不会重置中断状态

来吧,附上原地址,写的很不错的大佬,建议大家好好读一读:https://javadoop.com/post/AbstractQueuedSynchronizer

以上是关于ReentrantLock-AQS源码分析的主要内容,如果未能解决你的问题,请参考以下文章

ReentrantLock-AQS源码分析

LinkedList 源码分析(JDK 1.8)

LinkList及其源码解析

前驱图

Java源码阅读(不断补充)

软考-前驱图PV操作