AQS(AbstractQueuedSynchronizer)解析

AQS概念

AQS是用于构建锁和同步器的框架。ReentrantLock、信号量、闭锁、FutureTask等等都是基于AQS构建的。其内部封装了对等待线程队列维护，同时开放接口自定义共享资源的获取和释放。

AQS负责管理同步器类中状态的整数信息，通过getState，setState和compareAndSetState等方法操作状态。

支持共享和独占两种获取资源的方式。如果是独占获取，需要实现 tryAcquire 、 tryRelease 和 isHeldExclusively 方法。如果是共享获取，实现 tryAcquireShared 和 tryReleaseShared 等方法。

boolean tryAcquire(int arg) ：独占方式。获取资源成功后返回true，否则返回false

boolean tryRelease(int arg) ：独占方式。释放资源成功后返回true，否则返回false

int tryAcquireShared(int arg) ：共享方式。获取资源失败返回负数，获取成功则返回剩余资源数量，0表示无剩余资源

boolean tryReleaseShared(int arg) ：共享方式。释放资源，允许唤醒后续节点返回true，否则返回false

AQS源码

1 重要的内部类

 1 static final class Node {
 2     //共享模式
 3     static final Node SHARED = new Node();
 4     //独占模式
 5     static final Node EXCLUSIVE = null;
 6 
 7     //表示当前节点已经取消调度，如超时和中断，是终结状态
 8     static final int CANCELLED =  1;
 9     //表示当前节点的下一个节点等待当前节点唤醒，当节点入队时会将前一个节点置为该状态
10     static final int SIGNAL    = -1;
11     //表示当前节点等待在Condition上
12     static final int CONDITION = -2;
13     //共享模式下，前继节点会唤醒之后的一个及多个相邻节点
14     static final int PROPAGATE = -3;
15 
16     //当前节点等待资源的状态
17     volatile int waitStatus;
18     //前一个节点
19     volatile Node prev;
20     //后一个节点
21     volatile Node next;
22     //当前节点代表的线程
23     volatile Thread thread;
24     Node nextWaiter;
25 
26     final boolean isShared() {
27         return nextWaiter == SHARED;
28     }
29 
30     Node() {}
31 
32     Node(Thread thread, Node mode) {
33         this.nextWaiter = mode;
34         this.thread = thread;
35     }
36 
37     Node(Thread thread, int waitStatus) {
38         this.waitStatus = waitStatus;
39         this.thread = thread;
40     }
41 }

　　Node节点代表了在队列中等待资源的线程，头节点除外，初始状态为0。

2 acquire方法

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

　　独占访问资源的顶层入口。

　　1.tryAcquire方法由实现类自己实现，定义独占访问资源的逻辑。修改state的值代表占用了资源。

　　2.addWaiter方法将当前线程加入到等待队列

　　3.acquireQueued将不停尝试tryAcquire方法直到成功，期间不响应中断。如果被通知中断则在成功后返回true

　　4.如果重试期间被中断过，在获得资源后才会通过selfInterrupt中断自己

　　一上来就会尝试获取锁，而不管等待队列中或许还有其他线程在等待，这里体现了非公平性。

　　2.1 addWaiter

 1 private Node addWaiter(Node mode) {
 2     Node node = new Node(Thread.currentThread(), mode);
 3     //tail记录了队列的尾节点
 4     Node pred = tail;
 5     if (pred != null) {
 6         //将新节点的前指针指向旧的尾节点
 7         node.prev = pred;
 8         /**
 9          * 这个方法内部：unsafe.compareAndSwapObject(this, tailOffset, pred, node);
10          * tailOffset是tail属性在对象内存中的偏移量，根据偏移量找到tail存储的对象，比较和pred是否相同，相同则用node替换tail现有的值
11          */
12         if (compareAndSetTail(pred, node)) {
13             //将旧的尾节点后指针指向新节点
14             pred.next = node;
15             return node;
16         }
17     }
18     //失败或者首次插入调用enq
19     enq(node);
20     return node;
21 }

　　2.2 enq

 1 private Node enq(final Node node) {
 2     //CAS+自旋
 3     for (; ; ) {
 4         Node t = tail;
 5         if (t == null) {
 6             /**
 7              * 第一个放入队列
 8              * 这个方法内部：unsafe.compareAndSwapObject(this, headOffset, null, update);
 9              * 将新节点设置到head属性
10              */
11             if (compareAndSetHead(new Node()))
12                 tail = head;
13         } else {
14             node.prev = t;
15             if (compareAndSetTail(t, node)) {
16                 t.next = node;
17                 return t;
18             }
19         }
20     }
21 }

　　注意标红处，头节点是一个默认占位节点，表示已经占有资源的节点。后续节点占有资源之后，会将自己设置为头节点，并释放内部封装的线程。

　　2.3 acquireQueued

 1 final boolean acquireQueued(final Node node, int arg) {
 2     boolean failed = true;
 3     try {
 4         //标记轮询过程中是否遭遇中断
 5         boolean interrupted = false;
 6         for (;;) {
 7             //前指针指向的节点
 8             final Node p = node.predecessor();
 9             //前指针是头节点，则开始尝试获取资源
10             if (p == head && tryAcquire(arg)) {
11                 //获取成功，将自己设置为头节点，并将自己的前向指针和封装的线程置为空。头节点必然是正在占有资源的节点
12                 setHead(node);
13                 //将前节点后指针置空，方便GC回收
14                 p.next = null;
15                 failed = false;
16                 return interrupted;
17             }
18             /**
19              * shouldParkAfterFailedAcquire：将前置节点的状态设置为SIGNAL，以便自己陷入等待后，前置节点释放资源后会将自己唤醒。设置完毕返回true，这个方法会删除无效节点
20              * parkAndCheckInterrupt：进入wait状态，被唤醒后返回中断状态
21              */
22             if (shouldParkAfterFailedAcquire(p, node) &&
23                     parkAndCheckInterrupt())
24                 //到了这里说明是被中断唤醒的，设置中断标识
25                 interrupted = true;
26         }
27     } finally {
28         if (failed)
29             cancelAcquire(node);
30     }
31 }

　　如果在队列中处于第2名，会尝试竞争资源，成功后自己变为头节点。否则通知还在等待的前节点，让他有幸获得资源，使用完释放后通知自己，自己会在行23处等待。

　　2.4 shouldParkAfterFailedAcquire

 1 private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) {
 2     int ws = pred.waitStatus;
 3     if (ws == Node.SIGNAL)
 4         //如果前置节点的状态已经是SIGNAL（代表了前置节点释放完资源后，会唤醒自己），可以安心进入等待状态
 5         return true;
 6     if (ws > 0) {
 7         //如果前置节点状态>0，说明它已经咸鱼了，这个时候需要跳过这个节点
 8         //下面的循环不停前推，直到找到一个还在努力的少年
 9         do {
10             node.prev = pred = pred.prev;
11         } while (pred.waitStatus > 0);
12         //这里完成新的前节点的相互关联，中间的咸鱼链因为不再被引用，会被GC回收。
13         pred.next = node;
14     } else {
15         //前置节点是正常的节点，会将它的状态设置为SIGNAL，CAS失败会回到外层继续循环
16         compareAndSetWaitStatus(pred, ws, Node.SIGNAL);
17     }
18     return false;
19 }

　　2.5 parkAndCheckInterrupt

1 private final boolean parkAndCheckInterrupt() {
2     //进入wait状态，跟竞争内置锁失败进入阻塞状态不同
3     LockSupport.park(this);
4     //被唤醒了，可能是unPark或者被中断，返回自己的中断状态
5     return Thread.interrupted();
6 }

3 release方法

 1 public final boolean release(int arg) {
 2     //释放资源
 3     if (tryRelease(arg)) {
 4         Node h = head;
 5         if (h != null && h.waitStatus != 0)
 6             //唤醒后续的节点
 7             unparkSuccessor(h);
 8         return true;
 9     }
10     return false;
11 }

　　1.tryRelease释放资源，即将state的值还原

　　2.唤醒队列中正在等待的节点，是最靠前的节点，也就是等待最久的节点，这部分体现了公平性。

　　3.1 unparkSuccessor

 1 private void unparkSuccessor(Node node) {
 2     int ws = node.waitStatus;
 3     if (ws < 0)
 4         //将节点的等待状态设置为初始状态
 5         compareAndSetWaitStatus(node, ws, 0);
 6 
 7     Node s = node.next;
 8     if (s == null || s.waitStatus > 0) {
 9         //状态大于0的节点是无效节点，它已经放弃竞争了
10         s = null;
11         //从尾节点开始反向遍历，寻找最靠前的等待节点。为什么不从前向后？
12         for (Node t = tail; t != null && t != node; t = t.prev)
13             //如果当前节点是有效节点，记录下来
14             if (t.waitStatus <= 0)
15                 s = t;
16     }
17     if (s != null)
18         //使用unpark唤醒
19         LockSupport.unpark(s.thread);
20 }

　　这里唤醒的是离head最近的有效节点，虽然其前置节点不一定就是头节点，但是经过2.4的shouldParkAfterFailedAcquire方法删除无效节点之后，其前置节点一定是头节点。

　　回答标红的位置，直观上讲肯定是从前向后更快，但是看新节点进入等待队列的逻辑，2.1和2.2，逻辑是差不多的，都是先将新节点的前向指针关联到尾节点，然后CAS尝试设置将尾节点设置成新节点，再将旧的尾节点后向指针设置到新节点，关键在最后一步，在并发场景下，发生时间片切换，当前线程被挂起了。从前向后遍历的话，到了这里就无法找到下一个节点，主要还是两个节点设置前后关联这个操作不是原子的。

4 acquireShared方法

1 public final void acquireShared(int arg) {
2     if (tryAcquireShared(arg) < 0)
3         //尝试获取资源，如果失败则进入等待队列
4         doAcquireShared(arg);
5 }

　　4.1 doAcquireShared

 1 private void doAcquireShared(int arg) {
 2     //在队列尾添加新节点
 3     final Node node = addWaiter(Node.SHARED);
 4     boolean failed = true;
 5     try {
 6         boolean interrupted = false;
 7         //循环尝试获取资源
 8         for (;;) {
 9             final Node p = node.predecessor();
10             //正处在第二节点
11             if (p == head) {
12                 //尝试获取资源
13                 int r = tryAcquireShared(arg);
14                 //获取成功
15                 if (r >= 0) {
16                     //将自己设置为头结点，并且可能的情况下唤醒后续节点
17                     setHeadAndPropagate(node, r);
18                     p.next = null;
19                     if (interrupted)
20                         //如果等待过程中被中断，这里恢复中断
21                         selfInterrupt();
22                     failed = false;
23                     return;
24                 }
25             }
26             //等待获取资源
27             if (shouldParkAfterFailedAcquire(p, node) &&
28                     parkAndCheckInterrupt())
29                 interrupted = true;
30         }
31     } finally {
32         if (failed)
33             cancelAcquire(node);
34     }
35 }

　　注意代码11行的这个判断条件，必须是第二个节点才会尝试获取资源。获取资源有两种途径，一个是tryAcquireShared直接获取，不需要设置头节点。一种是doAcquireShared，在等待队列中被唤醒并获取资源，这种情况需要设置自己是头节点。

　　这里有一个问题，同时获取资源的线程有多个，那么在等待队列中被唤醒的节点也会有多个，一种特殊的情况，头节点尚未释放资源，第二个节点被其余线程唤醒了，那么走到13行，将自己设置成新的头节点，并将自己的前置指针置空。这种情况是否会出问题？不会有问题，之前的头节点代表的线程使用完毕后依然通过releaseShared释放资源

　　4.2 setHeadAndPropagate

 1 private void setHeadAndPropagate(Node node, int propagate) {
 2     Node h = head;
 3     //将当前节点设置为头结点，获取了资源的节点都是头节点
 4     setHead(node);
 5     //如果还有剩余资源 后面这部分判断条件没有看懂，请参考：https://blog.csdn.net/anlian523/article/details/106319294/
 6     if (propagate > 0 || h == null
 7             || h.waitStatus < 0
 8             || (h = head) == null 
 9             || h.waitStatus < 0) {
10         Node s = node.next;
11         if (s == null || s.isShared())
12             //
13             doReleaseShared();
14     }
15 }

　　上面行7是判断的原头节点，头节点的等待状态可能小于0，需要看下面5.1的解释，也就是同时有多个线程释放了资源并执行了 doReleaseShared 唤醒队列中等待的节点。行8又重新赋值了一下，因为这中间可能其他节点将头节点替换了，需要再次判断下。

　　跟独占方式不同的是，自己获得资源之后，如果发现还有资源剩余，是会继续唤醒后续节点的，不用等到释放资源的时候唤醒。

　　获取资源的方式有两处，一处是 acquireShared 每个线程第一次会尝试获取，第二处是 doAcquireShared 在等待队列中被唤醒后尝试获取。

5 releaseShared方法

1 public final boolean releaseShared(int arg) {
2     //尝试释放资源
3     if (tryReleaseShared(arg)) {
4         //唤醒其他节点
5         doReleaseShared();
6         return true;
7     }
8     return false;
9 }

　　5.1 doReleaseShared

 1 private void doReleaseShared() {
 2 
 3     for (; ; ) {
 4         Node h = head;
 5         if (h != null && h != tail) {
 6             int ws = h.waitStatus;
 7             //有节点让自己释放时通知
 8             if (ws == Node.SIGNAL) {
 9                 /**
10                  * 先将头节点的状态还原。
11                  * 当访问头节点时，头节点状态为-1，代表头节点正占用资源，后面有节点正等待唤醒
12                  * 若头节点状态为0，代表头节点已经释放了资源，正准备唤醒节点 或者 已经唤醒了节点，但后续节点尚未将自己设置为新的头节点
13                  */
14                 if (!compareAndSetWaitStatus(h, Node.SIGNAL, 0))
15                     continue;
16                 //唤醒下一个最靠前的等待节点
17                 unparkSuccessor(h);
18             }
19             //到这里，说明有两条或以上的线程准备释放资源
20             //1. 头节点已经释放过资源了，此时它的状态是0，并且唤醒的那个节点还未替换头节点
21             //2. 有其他线程通过releaseShared方法释放了资源，尝试唤醒其他节点
22             //出现这种情况会将头节点状态设置为-3
23             else if (ws == 0 && !compareAndSetWaitStatus(h, 0, Node.PROPAGATE))
24                 continue;
25         }
26         //如果头节点发生变化，说明已经成功唤醒了，退出循环
27         if (h == head)
28             break;
29     }
30 }

　　在并发场景下，doReleaseShared可能被同时执行多次，第一次执行的线程，将head的状态由-1设置为0，并唤醒新的节点，在新节点尚未替换head时，第二次执行的线程，又将head的状态从0设置为-3，注意只会设置两次，第三次的话会进入自旋等待！这里说明一下共享模式下头节点状态的含义：

　　1. 头节点状态为-1，说明还没有开始唤醒其他节点，可能是没有资源剩余了，也可能是代码还没执行到下面

　　2. 头节点状态为0，正在唤醒或已经唤醒下一个节点但新节点还没替换头节点

　　3. 头节点状态为-3，在2的基础上，又有一个线程释放了资源，此时需要额外唤醒一个节点，这个唤醒操作是由2产生的新节点来执行的，请看4.2#6代码。新节点替换了头节点之后，发现原头节点的状态小于0，即使此时可能 propagate == 0，自己也应该继续唤醒另一个节点了。　　

　　doReleaseShared的入口有两处，一处是 releaseShared 每个线程用完之后释放并唤醒其余节点，第二处是 setHeadAndPropagate 当有节点被唤醒并获得资源后，若资源还有余，会唤醒其余节点。

关于公平锁和非公平锁

　　AQS获取资源有两种方式：一种是执行 acquire / acquireShared 方法，不论等待队列是否有线程，都会通过 tryAcquire / tryAcquireShared 方法直接尝试获取。第二种是在等待队列中，按照先入先出的顺序唤醒。

　　是否是公平锁交给实现类规定，AQS只定义了等待队列中获取资源是公平的，如果实现类在 tryAcquire / tryAcquireShared 中规定必须在等待队列为空的情况下才能获取资源，那么就是公平锁，否则是非公平锁。

关于LockSupport

　　https://blog.csdn.net/tangtong1/article/details/102829724?utm_medium=distribute.pc_relevant_t0.none-task-blog-2%7Edefault%7EBlogCommendFromMachineLearnPai2%7Edefault-1.control&dist_request_id=&depth_1-utm_source=distribute.pc_relevant_t0.none-task-blog-2%7Edefault%7EBlogCommendFromMachineLearnPai2%7Edefault-1.control

参考：https://www.cnblogs.com/waterystone/p/4920797.html

posted @ 2021-04-05 19:46 walker993 阅读(151) 评论(0) 编辑收藏举报

刷新页面返回顶部

walker993

AQS(AbstractQueuedSynchronizer)解析

AQS概念

AQS源码

1 重要的内部类

2 acquire方法

2.1 addWaiter

2.2 enq

2.3 acquireQueued

2.4 shouldParkAfterFailedAcquire

2.5 parkAndCheckInterrupt

3 release方法

3.1 unparkSuccessor

4 acquireShared方法

4.1 doAcquireShared

4.2 setHeadAndPropagate

5 releaseShared方法

5.1 doReleaseShared

关于公平锁和非公平锁

关于LockSupport

公告

　　2.1 addWaiter

　　2.2 enq

　　2.3 acquireQueued

　　2.4 shouldParkAfterFailedAcquire

　　2.5 parkAndCheckInterrupt

　　3.1 unparkSuccessor

　　4.1 doAcquireShared

　　4.2 setHeadAndPropagate

　　5.1 doReleaseShared