Java并发编程-再谈 AbstractQueuedSynchronizer 1 ：独占模式（5）

look_w

实战举例：线程阻塞上述流程只是描述了构建数据结构的过程，并没有描述线程1、线程2阻塞的流程，因此接着继续用实际例子看一下线程1、线程2如何阻塞。贴一下acquireQueued、shouldParkAfterFailedAcquire两个方法源码：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

final boolean acquireQueued(final Node node, int arg) {     boolean failed = true;     try {         boolean interrupted = false;         for (;;) {             final Node p = node.prevecessor();             if (p == head && tryAcquire(arg)) {                 setHead(node);                 p.next = null; // help GC                 failed = false;                 return interrupted;             }             if (shouldParkAfterFailedAcquire(p, node) &&                 parkAndCheckInterrupt())                 interrupted = true;         }     } finally {         if (failed)             cancelAcquire(node);     } }

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

private static boolean shouldParkAfterFailedAcquire(Node prev, Node node) {     int ws = prev.waitStatus;     if (ws == Node.SIGNAL)         /*          * This node has already set status asking a release          * to signal it, so it can safely park.          */         return true;     if (ws > 0) {         /*          * prevecessor was cancelled. Skip over prevecessors and          * indicate retry.          */         do {             node.prev = prev = prev.prev;         } while (prev.waitStatus > 0);         prev.next = node;     } else {         /*          * waitStatus must be 0 or PROPAGATE.  Indicate that we          * need a signal, but don't park yet.  Caller will need to          * retry to make sure it cannot acquire before parking.          */         compareAndSetWaitStatus(prev, ws, Node.SIGNAL);     }     return false; }

首先是线程1，它的前驱节点是head节点，在它tryAcquire成功的情况下，执行第8行~第11行的代码。做几件事情：

• head为线程1对应的Node
• 线程1对应的Node的thread置空
• 线程1对应的Node的prev置空
• 原head的next置空，这样原head中的prev、next、thread都为空，对象内没有引用指向其他地方，GC可以认为这个Node是垃圾，对这个Node进行回收，注释”Help GC”就是这个意思
• failed=false表示没有失败

因此，如果线程1执行tryAcquire成功，那么数据结构将变为：

从上述流程可以总结到：只有前驱节点为head的节点会尝试tryAcquire，其余都不会，结合后面的release选继承者的方式，保证了先acquire失败的线程会优先从阻塞状态中解除去重新acquire。这是一种公平的acquire方式，因为它遵循”先到先得”原则，但是我们可以动动手脚让这种公平变为非公平，比如ReentrantLock默认的非公平模式，这个留在后面说。
那如果线程1执行tryAcquire失败，那么要执行shouldParkAfterFailedAcquire方法了，shouldParkAfterFailedAcquire拿线程1的前驱节点也就是head节点的waitStatus做了一个判断，因为waitStatus=0，因此执行第18行~第20行的逻辑，将head的waitStatus设置为SIGNAL即-1，然后方法返回false，数据结构变为：

看到这里就一个变化：head的waitStatus从0变成了-1。既然shouldParkAfterFailedAcquire返回false，acquireQueued的第13行~第14行的判断自然不通过，继续走for(;;)循环，如果tryAcquire失败显然又来到了shouldParkAfterFailedAcquire方法，此时线程1对应的Node的前驱节点head节点的waitStatus已经变为了SIGNAL即-1，因此执行第4行~第8行的代码，直接返回true出去。
shouldParkAfterFailedAcquire返回true，parkAndCheckInterrupt直接调用LockSupport的park方法：

1 2 3 4

private final boolean parkAndCheckInterrupt() {      LockSupport.park(this);      return Thread.interrupted(); }

至此线程1阻塞，线程2阻塞的流程与线程1阻塞的流程相同，可以自己分析一下。
另外再提一个问题，不知道大家会不会想：

• 为什么线程1对应的Node构建完毕不直接调用LockSupport的park方法进行阻塞？
• 为什么不直接把head的waitStatus直接设置为Signal而要从0设置为Signal？

我认为这是AbstractQueuedSynchronizer开发人员做了类似自旋的操作。因为很多时候获取acquire进行操作的时间很短，阻塞会引起上下文的切换，而很短时间就从阻塞状态解除，这样相对会比较耗费性能。
因此我们看到线程1自构建完毕Node加入数据结构到阻塞，一共尝试了两次tryAcquire，如果其中有一次成功，那么线程1就没有必要被阻塞，提升了性能。