AQS 锁核心类详解
AQS(AbstractQuenedSynchronizer 抽象队列同步器) 是一个用来构建锁和同步器的框架,使用 AQS能简单且高效地构造出应用广泛的大量的同步器,比如我们提到的ReentrantLock,Semaphore,其他的诸如 ReentrantReadWriteLock,SynchronousQueue,FutureTask等等皆是基于 AQS的。AQS是一种提供了原子式管理同步状态、阻塞和唤醒线程功能以及队列模型的简单框架。当然,我们自己也能利用 AQS非常轻松容易地构造出符合我们自己需求的同步器。AQS 框架如下:上图中有颜色的为Method,无颜色的为Attribution。
总的来说,AQS框架共分为五层,自上而下由浅入深,从 AQS对外暴露的 API到底层基础数据。当有自定义同步器接入时,只需重写第一层所需要的部分方法即可,不需要关注底层具体的实现流程。当自定义同步器进行加锁或者解锁操作时,先经过第一层的API进入AQS内部方法,然后经过第二层进行锁的获取,接着对于获取锁失败的流程,进入第三层和第四层的等待队列处理,而这些处理方式均依赖于第五层的基础数据提供层。
AQS核心思想:如果被请求的共享资源空闲,则将当前请求资源的线程设置为有效的工作线程,并且将共享资源设置为锁定状态。如果被请求的共享资源被占用,那么就需要一套线程阻塞等待以及被唤醒时锁分配的机制,这个机制 AQS是用 CLH队列锁实现的,即将暂时获取不到锁的线程加入到队列中。
CLH(Craig,Landin,and Hagersten)队列是一个虚拟的双向队列(虚拟的双向队列即不存在队列实例,仅存在结点之间的关联关系)。AQS是将每条请求共享资源的线程封装成一个 CLH锁队列的一个结点(Node)来实现锁的分配。CLH锁是一个自旋锁。能确保无饥饿性。提供先来先服务的公平性。
AQS使用一个 int成员变量来表示同步状态,通过内置的 FIFO队列来完成获取资源线程的排队工作。AQS使用 CAS对该同步状态进行原子操作实现对其值的修改。
private volatile int state;//共享变量,使用volatile修饰保证线程可见性
状态信息通过 procted类型的 getState,setState,compareAndSetState进行操作
1 //返回同步状态的当前值
2 protected final int getState() {
3 return state;
4 }
5 // 设置同步状态的值
6 protected final void setState(int newState) {
7 state = newState;
8 }
9 //原子地(CAS操作)将同步状态值设置为给定值update如果当前同步状态的值等于expect(期望值)
10 protected final boolean compareAndSetState(int expect, int update) {
11 return unsafe.compareAndSwapInt(this, stateOffset, expect, update);
12 }
AQS定义两种资源共享方式: 【1】Exclusive(独占):只有一个线程能执行,如 ReentrantLock。又可分为公平锁和非公平锁: ● **公平锁:**按照线程在队列中的排队顺序,先到者先拿到锁; ● **非公平锁:**当线程要获取锁时,无视队列顺序直接去抢锁,谁抢到就是谁的;
【2】Share(共享):多个线程可同时执行,如Semaphore/CountDownLatch。
ReentrantReadWriteLock 可以看成是组合式,因为 ReentrantReadWriteLock也就是读写锁允许多个线程对某资源进行读。
不同的自定义同步器争用共享资源的方式也不同。自定义同步器在实现时只需要实现共享资源 state 的获取与释放方式即可,至于具体线程等待队列的维护(如获取资源失败入队/唤醒出队等),AQS已经在上层已经帮我们实现好了。
AQS核心思想是,如果被请求的共享资源空闲,那么就将当前请求资源的线程设置为有效的工作线程,将共享资源设置为锁定状态;如果共享资源被占用,就需要一定的阻塞等待唤醒机制来保证锁分配。这个机制主要用的是 CLH队列的变体实现的,将暂时获取不到锁的线程加入到队列中。
CLH:Craig、Landin and Hagersten队列,是单向链表,AQS中的队列是 CLH变体的虚拟双向队列(FIFO),AQS是通过将每条请求共享资源的线程封装成一个节点来实现锁的分配。主要原理图如下:
AQS使用一个 Volatile的 int类型的成员变量来表示同步状态,通过内置的 FIFO队列来完成资源获取的排队工作,通过 CAS完成对 State值的修改。
同步器的设计基于模板模式【链接】,如果需要自定义同步器一般的方式是:使用者继承 AbstractQueuedSynchronizer 并重写指定的方法。(这些重写方法很简单,无非是对于共享资源 state的获取和释放) 将 AQS组合在自定义同步组件的实现中,并调用其模板方法,而这些模板方法会调用使用者重写的方法。自定义同步器时需要重写下面几个 AQS提供的模板方法:
1 isHeldExclusively()//该线程是否正在独占资源。只有用到condition才需要去实现它。
2 tryAcquire(int)//独占方式。尝试获取资源,成功则返回true,失败则返回false。
3 tryRelease(int)//独占方式。尝试释放资源,成功则返回true,失败则返回false。
4 tryAcquireShared(int)//共享方式。尝试获取资源。负数表示失败;0表示成功,但没有剩余可用资源;正数表示成功,且有剩余资源。
5 tryReleaseShared(int)//共享方式。尝试释放资源,成功则返回true,失败则返回false。
默认情况下,每个方法都抛出 UnsupportedOperationException。 这些方法的实现必须是内部线程安全的,并且通常应该简短而不是阻塞。AQS类中的其他方法都是final ,所以无法被其他类使用,只有这几个方法可以被其他类使用。
以 ReentrantLock为例,state初始化为0,表示未锁定状态。A线程 lock()时,会调用 tryAcquire()独占该锁并将 state+1。此后,其他线程再 tryAcquire()时就会失败,直到 A线程 unlock()到 state=0(即释放锁)为止,其它线程才有机会获取该锁。当然,释放锁之前,A线程自己是可以重复获取此锁的(state会累加),这就是可重入的概念。但要注意,获取多少次就要释放多么次,这样才能保证 state是能回到零态的。
AbstractQueuedSynchronizer 类底层的数据结构是使用 CLH(Craig,Landin,and Hagersten) 队列是一个虚拟的双向队列。其中Sync queue,即同步队列,是双向链表,包括 head结点和 tail结点,head结点主要用作后续的调度。而 Condition queue不是必须的,其是一个单向链表,只有当使用 Condition时,才会存在此单向链表。并且可能会有多个 Condition queue。
**类的继承关系:**AQS继承自 AbstractOwnableSynchronizer抽象类,并且实现了 Serializable接口,可以进行序列化。
public abstract class AbstractQueuedSynchronizer extends AbstractOwnableSynchronizer implements java.io.Serializable
其中 AbstractOwnableSynchronizer抽象类的源码如下:
1 public abstract class AbstractOwnableSynchronizer implements java.io.Serializable {
2
3 // 版本序列号
4 private static final long serialVersionUID = 3737899427754241961L;
5 // 构造方法
6 protected AbstractOwnableSynchronizer() { }
7 // 独占模式下的线程
8 private transient Thread exclusiveOwnerThread;
9
10 // 设置独占线程
11 protected final void setExclusiveOwnerThread(Thread thread) {
12 exclusiveOwnerThread = thread;
13 }
14
15 // 获取独占线程
16 protected final Thread getExclusiveOwnerThread() {
17 return exclusiveOwnerThread;
18 }
19 }
AbstractOwnableSynchronizer抽象类中,可以设置独占资源线程和获取独占资源线程。分别为 setExclusiveOwnerThread与getExclusiveOwnerThread方法,这两个方法会被子类调用。AbstractQueuedSynchronizer类有两个内部类,分别为 Node类与 ConditionObject类。下面分别做介绍。
先来看下AQS中最基本的数据结构Node,Node即为上面 CLH变体队列中的节点。
解释一下几个方法和属性值的含义:
方法和属性值 | 含义 |
---|---|
waitStatus | 当前节点在队列中的状态 |
thread | 表示处于该节点的线程 |
prev | 前驱指针 |
predecessor | 返回前驱节点,没有的话抛出npe |
nextWaiter | 指向下一个处于CONDITION状态的节点(由于本篇文章不讲述Condition Queue队列,这个指针不多介绍) |
next | 后继指针 |
线程两种锁的模式:
模式 | 含义 |
---|---|
SHARED | 表示线程以共享的模式等待锁 |
EXCLUSIVE | 表示线程正在以独占的方式等待锁 |
waitStatus有下面几个枚举值:每个节点包含了一个 Thread类型的引用,并且每个节点都存在一个状态,具体状态如下:
枚举 | 含义 |
---|---|
0 | 当一个Node被初始化的时候的默认值 |
CANCELLED | 为1,表示线程获取锁的请求已经取消了 |
CONDITION | 为-2,表示节点在等待队列中,节点线程等待唤醒 |
PROPAGATE | 为-3,当前线程处在SHARED情况下,该字段才会使用 |
SIGNAL | 为-1,表示线程已经准备好了,就等资源释放了 |
1 static final class Node {
2 // 模式,分为共享与独占
3 // 共享模式
4 static final Node SHARED = new Node();
5 // 独占模式
6 static final Node EXCLUSIVE = null;
7 // 结点状态
8 // CANCELLED,值为1,表示当前的线程被取消
9 // SIGNAL,值为-1,表示当前节点的后继节点包含的线程需要运行,也就是unpark
10 // CONDITION,值为-2,表示当前节点在等待condition,也就是在condition队列中
11 // PROPAGATE,值为-3,表示当前场景下后续的acquireShared能够得以执行
12 // 值为0,表示当前节点在sync队列中,等待着获取锁
13 static final int CANCELLED = 1;
14 static final int SIGNAL = -1;
15 static final int CONDITION = -2;
16 static final int PROPAGATE = -3;
17
18 // 结点状态
19 volatile int waitStatus;
20 // 前驱结点
21 volatile Node prev;
22 // 后继结点
23 volatile Node next;
24 // 结点所对应的线程
25 volatile Thread thread;
26 // 下一个等待者
27 Node nextWaiter;
28
29 // 结点是否在共享模式下等待
30 final boolean isShared() {
31 return nextWaiter == SHARED;
32 }
33
34 // 获取前驱结点,若前驱结点为空,抛出异常
35 final Node predecessor() throws NullPointerException {
36 // 保存前驱结点
37 Node p = prev;
38 if (p == null) // 前驱结点为空,抛出异常
39 throw new NullPointerException();
40 else // 前驱结点不为空,返回
41 return p;
42 }
43
44 // 无参构造方法
45 Node() { // Used to establish initial head or SHARED marker
46 }
47
48 // 构造方法
49 Node(Thread thread, Node mode) { // Used by addWaiter
50 this.nextWaiter = mode;
51 this.thread = thread;
52 }
53
54 // 构造方法
55 Node(Thread thread, int waitStatus) { // Used by Condition
56 this.waitStatus = waitStatus;
57 this.thread = thread;
58 }
59 }
View Code
此类实现了 Condition接口,Condition接口定义了条件操作规范,具体如下:Condition接口中定义了await、signal方法,用来等待条件、释放条件。
1 public interface Condition {
2
3 // 等待,当前线程在接到信号或被中断之前一直处于等待状态
4 void await() throws InterruptedException;
5
6 // 等待,当前线程在接到信号之前一直处于等待状态,不响应中断
7 void awaitUninterruptibly();
8
9 //等待,当前线程在接到信号、被中断或到达指定等待时间之前一直处于等待状态
10 long awaitNanos(long nanosTimeout) throws InterruptedException;
11
12 // 等待,当前线程在接到信号、被中断或到达指定等待时间之前一直处于等待状态。此方法在行为上等效于: awaitNanos(unit.toNanos(time)) > 0
13 boolean await(long time, TimeUnit unit) throws InterruptedException;
14
15 // 等待,当前线程在接到信号、被中断或到达指定最后期限之前一直处于等待状态
16 boolean awaitUntil(Date deadline) throws InterruptedException;
17
18 // 唤醒一个等待线程。如果所有的线程都在等待此条件,则选择其中的一个唤醒。在从 await 返回之前,该线程必须重新获取锁。
19 void signal();
20
21 // 唤醒所有等待线程。如果所有的线程都在等待此条件,则唤醒所有线程。在从 await 返回之前,每个线程都必须重新获取锁。
22 void signalAll();
23 }
类的属性:包含了头结点head,尾结点tail,状态state、自旋时间spinForTimeoutThreshold,还有 AQS抽象的属性在内存中的偏移地址,通过该偏移地址,可以获取和设置该属性的值,同时还包括一个静态初始化块,用于加载内存偏移地址。
1 public abstract class AbstractQueuedSynchronizer extends AbstractOwnableSynchronizer
2 implements java.io.Serializable {
3 // 版本号
4 private static final long serialVersionUID = 7373984972572414691L;
5 // 头结点
6 private transient volatile Node head;
7 // 尾结点
8 private transient volatile Node tail;
9 // 状态
10 private volatile int state;
11 // 自旋时间
12 static final long spinForTimeoutThreshold = 1000L;
13
14 // Unsafe类实例
15 private static final Unsafe unsafe = Unsafe.getUnsafe();
16 // state内存偏移地址
17 private static final long stateOffset;
18 // head内存偏移地址
19 private static final long headOffset;
20 // state内存偏移地址
21 private static final long tailOffset;
22 // tail内存偏移地址
23 private static final long waitStatusOffset;
24 // next内存偏移地址
25 private static final long nextOffset;
26 // 静态初始化块
27 static {
28 try {
29 stateOffset = unsafe.objectFieldOffset
30 (AbstractQueuedSynchronizer.class.getDeclaredField("state"));
31 headOffset = unsafe.objectFieldOffset
32 (AbstractQueuedSynchronizer.class.getDeclaredField("head"));
33 tailOffset = unsafe.objectFieldOffset
34 (AbstractQueuedSynchronizer.class.getDeclaredField("tail"));
35 waitStatusOffset = unsafe.objectFieldOffset
36 (Node.class.getDeclaredField("waitStatus"));
37 nextOffset = unsafe.objectFieldOffset
38 (Node.class.getDeclaredField("next"));
39
40 } catch (Exception ex) { throw new Error(ex); }
41 }
42 }
**类的构造方法:**此类构造方法为空抽象构造方法,供子类调用。
1 protected AbstractQueuedSynchronizer() { }
类的核心方法acquire:该方法以独占模式获取(资源),忽略中断,即线程在 acquire过程中,中断此线程是无效的。源码如下:
1 public final void acquire(int arg) {
2 if (!tryAcquire(arg) && acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
3 selfInterrupt();
4 }
由上述源码可以知道,当一个线程调用 acquire时,调用方法流程如下:
【1】首先调用 tryAcquire方法,调用此方法的线程会试图在独占模式下获取对象状态。此方法应该查询是否允许它在独占模式下获取对象状态,如果允许,则获取它。在 AbstractQueuedSynchronizer源码中默认会抛出一个异常,即需要子类去重写此方法完成自己的逻辑。之后会进行分析。 【2】若 tryAcquire失败,则调用 addWaiter方法,addWaiter方法完成的功能是将调用此方法的线程封装成为一个结点并放入Sync queue。 【3】调用 acquireQueued方法,此方法完成的功能是Sync queue中的结点不断尝试获取资源,若成功,则返回true,否则,返回false。 【4】由于 tryAcquire默认实现是抛出异常,所以此时,不进行分析,之后会结合一个例子进行分析。
首先分析 addWaiter方法:
1 // 添加等待者
2 private Node addWaiter(Node mode) {
3 // 新生成一个结点,默认为独占模式
4 Node node = new Node(Thread.currentThread(), mode);
5 // Try the fast path of enq; backup to full enq on failure
6 // 保存尾结点
7 Node pred = tail;
8 if (pred != null) { // 尾结点不为空,即已经被初始化
9 // 将node结点的prev域连接到尾结点
10 node.prev = pred;
11 if (compareAndSetTail(pred, node)) { // 比较pred是否为尾结点,是则将尾结点设置为node
12 // 设置尾结点的next域为node
13 pred.next = node;
14 return node; // 返回新生成的结点
15 }
16 }
17 enq(node); // 尾结点为空(即还没有被初始化过),或者是compareAndSetTail操作失败,则入队列
18 return node;
19 }
addWaiter 方法使用快速添加的方式往 sync queue尾部添加结点,如果 sync queue队列还没有初始化,则会使用 enq插入队列中,enq方法源码如下:
1 private Node enq(final Node node) {
2 for (;;) { // 无限循环,确保结点能够成功入队列
3 // 保存尾结点
4 Node t = tail;
5 if (t == null) { // 尾结点为空,即还没被初始化
6 if (compareAndSetHead(new Node())) // 头结点为空,并设置头结点为新生成的结点
7 tail = head; // 头结点与尾结点都指向同一个新生结点
8 } else { // 尾结点不为空,即已经被初始化过
9 // 将node结点的prev域连接到尾结点
10 node.prev = t;
11 if (compareAndSetTail(t, node)) { // 比较结点t是否为尾结点,若是则将尾结点设置为node
12 // 设置尾结点的next域为node
13 t.next = node;
14 return t; // 返回尾结点
15 }
16 }
17 }
18 }
enq方法会使用无限循环来确保节点的成功插入。现在,分析 acquireQueue方法。其源码如下:
1 // sync队列中的结点在独占且忽略中断的模式下获取(资源)
2 final boolean acquireQueued(final Node node, int arg) {
3 // 标志
4 boolean failed = true;
5 try {
6 // 中断标志
7 boolean interrupted = false;
8 for (;;) { // 无限循环
9 // 获取node节点的前驱结点
10 final Node p = node.predecessor();
11 if (p == head && tryAcquire(arg)) { // 前驱为头结点并且成功获得锁
12 setHead(node); // 设置头结点
13 p.next = null; // help GC
14 failed = false; // 设置标志
15 return interrupted;
16 }
17 if (shouldParkAfterFailedAcquire(p, node) &&
18 parkAndCheckInterrupt())
19 interrupted = true;
20 }
21 } finally {
22 if (failed)
23 cancelAcquire(node);
24 }
25 }
首先获取当前节点的前驱节点,如果前驱节点是头结点并且能够获取(资源),代表该当前节点能够占有锁,设置头结点为当前节点,返回。否则,调用 shouldParkAfterFailedAcquire 和 parkAndCheckInterrupt 方法,首先,我们看shouldParkAfterFailedAcquire方法,代码如下:
1 // 当获取(资源)失败后,检查并且更新结点状态
2 private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) {
3 // 获取前驱结点的状态
4 int ws = pred.waitStatus;
5 if (ws == Node.SIGNAL) // 状态为SIGNAL,为-1
6 /*
7 * This node has already set status asking a release
8 * to signal it, so it can safely park.
9 */
10 // 可以进行park操作
11 return true;
12 if (ws > 0) { // 表示状态为CANCELLED,为1
13 /*
14 * Predecessor was cancelled. Skip over predecessors and
15 * indicate retry.
16 */
17 do {
18 node.prev = pred = pred.prev;
19 } while (pred.waitStatus > 0); // 找到pred结点前面最近的一个状态不为CANCELLED的结点
20 // 赋值pred结点的next域
21 pred.next = node;
22 } else { // 为PROPAGATE -3 或者是0 表示无状态,(为CONDITION -2时,表示此节点在condition queue中)
23 /*
24 * waitStatus must be 0 or PROPAGATE. Indicate that we
25 * need a signal, but don't park yet. Caller will need to
26 * retry to make sure it cannot acquire before parking.
27 */
28 // 比较并设置前驱结点的状态为SIGNAL
29 compareAndSetWaitStatus(pred, ws, Node.SIGNAL);
30 }
31 // 不能进行park操作
32 return false;
33 }
只有当该节点的前驱结点的状态为 SIGNAL时,才可以对该结点所封装的线程进行 park操作。否则,将不能进行 park操作。再看parkAndCheckInterrupt方法,源码如下:
1 // 进行park操作并且返回该线程是否被中断
2 private final boolean parkAndCheckInterrupt() {
3 // 在许可可用之前禁用当前线程,并且设置了blocker
4 LockSupport.park(this);
5 return Thread.interrupted(); // 当前线程是否已被中断,并清除中断标记位
6 }
parkAndCheckInterrupt方法里的逻辑是首先执行 park操作,即禁用当前线程,然后返回该线程是否已经被中断。再看 final块中的cancelAcquire方法,其源码如下:
View Code
该方法完成的功能就是取消当前线程对资源的获取,即设置该结点的状态为 CANCELLED,接着我们再看 unparkSuccessor方法,源码如下:
1 // 释放后继结点
2 private void unparkSuccessor(Node node) {
3 /*
4 * If status is negative (i.e., possibly needing signal) try
5 * to clear in anticipation of signalling. It is OK if this
6 * fails or if status is changed by waiting thread.
7 */
8 // 获取node结点的等待状态
9 int ws = node.waitStatus;
10 if (ws < 0) // 状态值小于0,为SIGNAL -1 或 CONDITION -2 或 PROPAGATE -3
11 // 比较并且设置结点等待状态,设置为0
12 compareAndSetWaitStatus(node, ws, 0);
13
14 /*
15 * Thread to unpark is held in successor, which is normally
16 * just the next node. But if cancelled or apparently null,
17 * traverse backwards from tail to find the actual
18 * non-cancelled successor.
19 */
20 // 获取node节点的下一个结点
21 Node s = node.next;
22 if (s == null || s.waitStatus > 0) { // 下一个结点为空或者下一个节点的等待状态大于0,即为CANCELLED
23 // s赋值为空
24 s = null;
25 // 从尾结点开始从后往前开始遍历
26 for (Node t = tail; t != null && t != node; t = t.prev)
27 if (t.waitStatus <= 0) // 找到等待状态小于等于0的结点,找到最前的状态小于等于0的结点
28 // 保存结点
29 s = t;
30 }
31 if (s != null) // 该结点不为为空,释放许可
32 LockSupport.unpark(s.thread);
33 }
该方法的作用就是为了释放node节点的后继结点。对于cancelAcquire与unparkSuccessor方法,如下示意图可以清晰的表示:
其中 node为参数,在执行完 cancelAcquire方法后的效果就是 unpark了 s结点所包含的 t4线程。现在,再来看 acquireQueued方法的整个的逻辑。逻辑如下: 【1】判断结点的前驱是否为 head并且是否成功获取(资源)。 【2】若步骤1均满足,则设置结点为head,之后会判断是否 finally模块,然后返回。 【3】若步骤2不满足,则判断是否需要park当前线程,是否需要park当前线程的逻辑是判断结点的前驱结点的状态是否为SIGNAL,若是,则park当前结点,否则,不进行park操作。 【4】若 park了当前线程,之后某个线程对本线程unpark后,并且本线程也获得机会运行。那么,将会继续进行步骤①的判断。
**类的核心方法 release:**以独占模式释放对象,其源码如下:
1 public final boolean release(int arg) {
2 if (tryRelease(arg)) { // 释放成功
3 // 保存头结点
4 Node h = head;
5 if (h != null && h.waitStatus != 0) // 头结点不为空并且头结点状态不为0
6 unparkSuccessor(h); //释放头结点的后继结点
7 return true;
8 }
9 return false;
10 }
其中,tryRelease的默认实现是抛出异常,需要具体的子类实现,如果 tryRelease成功,那么如果头结点不为空并且头结点的状态不为0,则释放头结点的后继结点,unparkSuccessor方法已经分析过,不再累赘。
通过ReentrantLock理解AQS:ReentrantLock中公平锁和非公平锁在底层是相同的,这里以非公平锁为例进行分析。在非公平锁中,有一段这样的代码:
1 // java.util.concurrent.locks.ReentrantLock
2
3 static final class NonfairSync extends Sync {
4 ...
5 final void lock() {
6 if (compareAndSetState(0, 1))
7 setExclusiveOwnerThread(Thread.currentThread());
8 else
9 acquire(1);
10 }
11 ...
12 }
看一下这个Acquire是怎么写的:
1 // java.util.concurrent.locks.AbstractQueuedSynchronizer
2
3 public final void acquire(int arg) {
4 if (!tryAcquire(arg) && acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
5 selfInterrupt();
6 }
再看一下tryAcquire方法:
1 // java.util.concurrent.locks.AbstractQueuedSynchronizer
2
3 protected boolean tryAcquire(int arg) {
4 throw new UnsupportedOperationException();
5 }
可以看出,这里只是AQS的简单实现,具体获取锁的实现方法是由各自的公平锁和非公平锁单独实现的(以ReentrantLock为例)。如果该方法返回了True,则说明当前线程获取锁成功,就不用往后执行了;如果获取失败,就需要加入到等待队列中。下面会详细解释线程是何时以及怎样被加入进等待队列中的。
对于 AbstractQueuedSynchronizer的分析,最核心的就是 sync queue的分析。 【1】每一个结点都是由前一个结点唤醒; 【2】当结点发现前驱结点是 head并且尝试获取成功,则会轮到该线程运行。 【3】condition queue中的结点向 sync queue中转移是通过 signal操作完成的。 【4】当结点的状态为 SIGNAL时,表示后面的结点需要运行。
【1】什么是 AQS? 为什么它是核心? 【2】AQS的核心思想是什么? 它是怎么实现的? 底层数据结构等? 【3】AQS有哪些核心的方法? 【4】AQS定义什么样的资源获取方式? AQS定义了两种资源获取方式:独占(只有一个线程能访问执行,又根据是否按队列的顺序分为公平锁和非公平锁,如ReentrantLock) 和共享(多个线程可同时访问执行,如Semaphore、CountDownLatch、 CyclicBarrier )。ReentrantReadWriteLock可以看成是组合式,允许多个线程同时对某一资源进行读。 【4】AQS底层使用了什么样的设计模式? 法返回了True,则说明当前线程获取锁成功,就不用往后执行了;如果获取失败,就需要加入到等待队列中。下面会详细解释线程是何时以及怎样被加入进等待队列中的。
对于 AbstractQueuedSynchronizer的分析,最核心的就是 sync queue的分析。 【1】每一个结点都是由前一个结点唤醒; 【2】当结点发现前驱结点是 head并且尝试获取成功,则会轮到该线程运行。 【3】condition queue中的结点向 sync queue中转移是通过 signal操作完成的。 【4】当结点的状态为 SIGNAL时,表示后面的结点需要运行。
【1】什么是 AQS? 为什么它是核心? 【2】AQS的核心思想是什么? 它是怎么实现的? 底层数据结构等? 【3】AQS有哪些核心的方法? 【4】AQS定义什么样的资源获取方式? AQS定义了两种资源获取方式:独占(只有一个线程能访问执行,又根据是否按队列的顺序分为公平锁和非公平锁,如ReentrantLock) 和共享(多个线程可同时访问执行,如Semaphore、CountDownLatch、 CyclicBarrier )。ReentrantReadWriteLock可以看成是组合式,允许多个线程同时对某一资源进行读。 【4】AQS底层使用了什么样的设计模式? 【5】AQS的应用示例?