以前虽然看过一次AQS的源码实现，但在过一段时间后与同学交流时，发觉自己理解并不够深，印像太浅。需要做一个记录整理，帮助自己消化。
AQS中Node的设计：
几个点：
1. Node实现作者： "CLH" (Craig, Landin, and * Hagersten) ，有名的CLH queue
2. 是一个FIFO的链表的实现，对于队列的控制经常要做double-check。
3. Node节点通过一个int waiteStatus代表一些不同意义的状态。
- SIGNAL=-1，代表是需要当前Node节点需要唤起后一个Node节点。在Node节点enqueue时，会设置前一个节点的状态。这样链式的唤醒，完成这样的一个交接棒。
- CONDITION = -2 ，
4. nextWaiter一个标志位，就是用于表明是采用的共享锁还是排他锁。同时也是其对应condition队列的引用节点。
来看一下Node操作的一个double-check设计
node的equeue操作：
1.private Node addWaiter(Node mode) {
2. Node node = new Node(Thread.currentThread(), mode);
3. // Try the fast path of enq; backup to full enq on failure
4. Node pred = tail;
5. if (pred != null) {
6. node.prev = pred;
7. if (compareAndSetTail(pred, node)) { // 位置1
8. pred.next = node;
9. return node;
10. }
11. }
12. enq(node);
13. return node;
14. }
15.
16.private Node enq(final Node node) {
17. for (;;) {
18. Node t = tail;
19. if (t == null) { // Must initialize // 位置3
20. Node h = new Node(); // Dummy header
21. h.next = node;
22. node.prev = h;
23. if (compareAndSetHead(h)) { // 位置4
24. tail = node;
25. return h;
26. }
27. }
28. else {
29. node.prev = t;
30. if (compareAndSetTail(t, node)) { // 位置2
31. t.next = node;
32. return t;
33. }
34. }
35. }
36. }
代码中标记了4个位置：
1. node默认的equeue操作都是接在tail节点之后，prev节点指定完成后，进行一个cas设置操作，将当前加入的节点做为tail。 因为会有并发操作，原先的tail节点会有所变化，位置1处会出现失败。这样就进入第2步的check机制
2. 位置2，每次都取一次当前的tail节点，尝试通过cas设置操作，将当前节点做为tail，有并发变化/竞争导致处理失败，继续重复这一动作，直到完成为之。
3. 在位置1和2处理的一种异常情况，就是tail节点为空，有可能该节点是第一个进行enqueue，也有可能是node节点被所有唤醒。这时需要重新创建队列，创建一个空的Head node节点，将自己做为tail节点。
4. 同样考虑并发因素，位置3在处理时，可能已有线程创建了Head节点，这样就又回到位置2上的处理，将node节点添加在tail节点之后。
位置2,3,4都是基于一种发展的锁机制实现，尝试N次竞争后，总能成功。
node的dequeue操作：
一个比较巧妙的设计，需要细细品味。
出库分为两个动作：
动作1：
1.private void setHead(Node node) {
2. head = node;
3. node.thread = null;
4. node.prev = null;
5. }
轮到自己出库后，进行head节点的gc处理，断开自己node节点和链表的一些应用。同时将自己添加为head。
说明：刚开始对出库时将自己node设置为head，一直想不明白。后来仔细看了下是否轮到出库时的判断就可以明白了。
1.final Node p = node.predecessor(); // 位置1
2. if (p == head && tryAcquire(arg)) {
3. setHead(node);
4. p.next = null; // help GC
5. return interrupted;
6.}
轮到出库时的判断：
在位置1上，每次判断都是获取当前节点的prev节点，判断==head节点。最后就可以这么理解，head节点其实是一个“傀儡”，代表的是上一个出库的节点，因为是一个FIFO队列，如果当前的上一个节点已经出库，那就可以轮到自己
动作2：
1.private void unparkSuccessor(Node node) {
2. /*
3. * Try to clear status in anticipation of signalling. It is
4. * OK if this fails or if status is changed by waiting thread.
5. */
6. compareAndSetWaitStatus(node, Node.SIGNAL, 0);
7.
8. /*
9. * Thread to unpark is held in successor, which is normally
10. * just the next node. But if cancelled or apparently null,
11. * traverse backwards from tail to find the actual
12. * non-cancelled successor.
13. */
14. Node s = node.next;
15. if (s == null || s.waitStatus > 0) { //位置1
16. s = null;
17. for (Node t = tail; t != null && t != node; t = t.prev)
18. if (t.waitStatus <= 0)
19. s = t;
20. }
21. if (s != null)
22. LockSupport.unpark(s.thread);
23. }
这里没啥特殊的，就是在位置1上，当一个节点需要出库后，唤醒下一个非cancel的节点。这里的LockSupport的代码设计也有一点取巧，后续可以再写点。
acquire , release , cancel三个动作设计
按照原先作者的设计：
1.Acquire:
2. while (!tryAcquire(arg)) {
3. enqueue thread if it is not already queued;
4. possibly block current thread;
5. }
6.
7.Release:
8. if (tryRelease(arg))
9. unblock the first queued thread;
预留了5个protected方法，用于client自己实现相关的处理，进行业务行为控制，因为cocurrent很多Lock,Future的实现都是基于此扩展，定义了自己的处理。
具体的一些方法使用，后续再补。
acquire动作:
独占锁：
- public final void acquire(int arg)
- public final void acquireInterruptibly(int arg) throws InterruptedException
- public final boolean tryAcquireNanos(int arg, long nanosTimeout) throws InterruptedException
public final void acquire(int arg)
1.public final void acquire(int arg) {
2. if (!tryAcquire(arg) &&
3. acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
4. selfInterrupt();
5. }
说明：
1. tryAcquire自定义的扩展，一般用value值进行控制，类似P/V原语的控制。
2. addWaiter是一个入库的动作，前面已经介绍。
3. 来看一下accquireQueued方法
1.final boolean acquireQueued(final Node node, int arg) {
2. try {
3. boolean interrupted = false;
4. for (;;) {
5. final Node p = node.predecessor(); <span style="color: rgb(255, 0, 0);"> <span style="color: rgb(0, 0, 0);"> // 位置1</span></span>
6. if (p == head && tryAcquire(arg)) {
7. setHead(node);
8. p.next = null; // help GC
9. return interrupted;
10. }
11. if (shouldParkAfterFailedAcquire(p, node) && // 位置2
12. parkAndCheckInterrupt()) // 位置3
13. interrupted = true;
14. }
15. } catch (RuntimeException ex) {
16. cancelAcquire(node); // 位置4
17. throw ex;
18. }
19. }
位置1： 前面已经介绍过，就是对比一下我的上一个节点是否已经出队列，如果已经出队列，就认为当前轮到自己出队列，返回interrupted的标志。
位置2： 执行了一个动作，就是设置一下当前节点的上一个节点的waitStatus状态为SINGLE，让其在出队列的时候能唤醒自己进行处理。
位置3： 在设置了上一个节点为SINGLE后，当前线程就可以进行park，转到阻塞状态，直到等到被唤醒。 (唤醒条件有2个： 前一个节点的唤醒和Thread.interupte事件)
位置4： 就是一个cancel动作。
public final void acquireInterruptibly(int arg) throws InterruptedException
和accquire方法的区别，就是针对Thread.interrupt会响应一个InterruptedException异常，立马返回。而accquire会一直等待直到自己可以出队列。
看一下其核心方法：
1.private void doAcquireInterruptibly(int arg)
2. throws InterruptedException {
3. final Node node = addWaiter(Node.EXCLUSIVE);
4. try {
5. for (;;) {
6. final Node p = node.predecessor(); // 位置1
7. if (p == head && tryAcquire(arg)) {
8. setHead(node);
9. p.next = null; // help GC
10. return;
11. }
12. if (shouldParkAfterFailedAcquire(p, node) && // 位置2
13. parkAndCheckInterrupt())
14. break; // 位置3
15. }
16. } catch (RuntimeException ex) {
17. cancelAcquire(node);
18. throw ex;
19. }
20. // Arrive here only if interrupted
21. cancelAcquire(node);
22. throw new InterruptedException(); // 位置4
23. }
位置1，2和accquire一样，唯一的区别小点就在位置3上直接进行了break，跳出响应位置4了InterruptedException。
public final boolean tryAcquireNanos(int arg, long nanosTimeout) throws InterruptedException
和accquire, accquireInterruptibly方法的区别，就在于在支持Interrupted响应的基础上，还支持了Timeout超时的控制，在指定时间内无法获取对应锁，抛出对应的TimeoutException
来看一下核心方法：
1.private boolean doAcquireNanos(int arg, long nanosTimeout)
2. throws InterruptedException {
3. long lastTime = System.nanoTime();
4. final Node node = addWaiter(Node.EXCLUSIVE);
5. try {
6. for (;;) {
7. final Node p = node.predecessor(); // 位置1
8. if (p == head && tryAcquire(arg)) {
9. setHead(node);
10. p.next = null; // help GC
11. return true;
12. }
13. if (nanosTimeout <= 0) { // 位置2
14. cancelAcquire(node);
15. return false;
16. }
17. if (nanosTimeout > spinForTimeoutThreshold && // 位置3
18. shouldParkAfterFailedAcquire(p, node)) // 位置4
19. LockSupport.parkNanos(this, nanosTimeout); // 位置5
20. long now = System.nanoTime(); // 位置6
21. nanosTimeout -= now - lastTime;
22. lastTime = now;
23. if (Thread.interrupted()) // 位置7
24. break;
25. }
26. } catch (RuntimeException ex) {
27. cancelAcquire(node);
28. throw ex;
29. }
30. // Arrive here only if interrupted
31. cancelAcquire(node);
32. throw new InterruptedException(); // 位置8
33. }
位置1： 和先前的accquire一样
位置2：6都是对超时时间的处理，nanosTimeout为当前还需要等待的时间，每次检查一下nanosTimeout时间，并在循环过程中减去对应的处理时间。
位置3：一个自旋锁的优化判断
位置4：和先前的accquire一样，设置上一个Node节点的waitStatus状态。
位置5：和先前accquire有点不同，使用LockSupport指定时间的park方法，完成对应的时间控制。
共享锁：
- public final void acquireShared(int arg)
- public final void acquireSharedInterruptibly(int arg) throws InterruptedException
- public final boolean tryAcquireSharedNanos(int arg, long nanosTimeout) throws InterruptedException
public final void acquireShared(int arg)
和独占锁处理方式基本类似，来看一下核心代码：
1.private void doAcquireShared(int arg) {
2. final Node node = addWaiter(Node.SHARED);
3. try {
4. boolean interrupted = false;
5. for (;;) {
6. final Node p = node.predecessor();
7. if (p == head) {
8. int r = tryAcquireShared(arg);
9. if (r >= 0) {
10. setHeadAndPropagate(node, r); // 位置1
11. p.next = null; // help GC
12. if (interrupted)
13. selfInterrupt();
14. return;
15. }
16. }
17. if (shouldParkAfterFailedAcquire(p, node) &&
18. parkAndCheckInterrupt())
19. interrupted = true;
20. }
21. } catch (RuntimeException ex) {
22. cancelAcquire(node);
23. throw ex;
24. }
25. }
这里设计上有点小技巧，原先思考一个共享锁的典型场景：读写锁。 一旦写锁释放，应该是唤起所有的读锁。而原先在看setHeadAndPropagate，并没有一个循环释放锁的过程。后来思考了下，采用的是一个链式释放的过程，前一个shared的锁对象释放下一个，在释放的时候继续进行tryAccquireShared控制。
一点感悟：在写并发程序时，一些传统编程的思路要有所改变。
public final void acquireSharedInterruptibly(int arg) throws InterruptedException
public final boolean tryAcquireSharedNanos(int arg, long nanosTimeout) throws InterruptedException
这两个实现上和独占锁类似，也就是setHeadAndPropagate处理上的不同点而已。
release动作:
public final boolean release(int arg)
1.if (tryRelease(arg)) {
2. Node h = head;
3. if (h != null && h.waitStatus != 0)
4. unparkSuccessor(h);
5. return true;
6. }
7. return false;
没啥特别好将的，一看基本也就明白了，出队列的时候，同时唤醒下一个Node。
cancel动作:
private void cancelAcquire(Node node)
代码就不贴了，几个处理：
1. 从链表上删除cancel节点
2. 如果cancel节点是head，则尝试唤醒cancel节点的下一个节点。
ConditionObject的理解
几个主要方法：
- public final void await() throws InterruptedException
- public final void awaitUninterruptibly()
- public final long awaitNanos(long nanosTimeout) throws InterruptedException
- public final boolean awaitUntil(Date deadline) throws InterruptedException
- public final boolean await(long time, TimeUnit unit) throws InterruptedException
- public final void signal()
- public final void signalAll()
先理解一下ConditionObject的应用场景，和Objectd的wait,single方法使用场景的区别。
就拿生产者/消费者程序看，假想用object.wait和single实现：
伪代码如下：
1.Array queue;
2.Object empty = new Object();
3.Object full = new Object();
4.
5.// 生产者
6.if(queue 是否满了)
7. full.wait() //阻塞等待
8.else
9. put(queue , data) //放入数据
10. empty.single(); // 已经放了一个，通知一下
11.
12.
13.// 消费者
14.if(queue 是否空了)
15. empty.wait() // 阻塞等待
16.else
17. data = get(queue);
18. full.single() // 已经消费了，通知一下
存在的问题：
1. 如何保证put和get数据是满足是线程安全的？ CAS设计 or 使用同步原语？
很明显，CAS的设计满足不了queue的两个操作，第一数据入库，第二下标+1，存在安全隐患。所以需要使用对queue进行同步控制。但这样会引出思索的问题，拿到queue的锁后，一直在等待empty或者full通知。
这里ConditionObject就能很好的解决这个问题，不存在死的问题。它的执行一个条件的await操作时，会首先释放当前所持有的Lock，让其他的线程可以进行生产/消费处理。说白了2个object是基于同一个Node等待队列链表。
整体概念
在整个AQS存在两种链表。 一个链表就是整个Sync Node链表，横向链表。另一种链表就是Condition的wait Node链表，相对于Sync node，它属于node节点的一个纵向链表。当纵向列表被single通知后，会进入对应的Sync Node进行排队处理。
通过这样的纵横队列，实现了ConditionObject共享lock锁数据。