电子技术论坛_中国专业的电子工程师学习交流社区-中电网技术论坛

标题: Java并发编程-再谈 AbstractQueuedSynchronizer 1 ：独占模式（5） [打印本页]

作者: look_w 时间: 2019-1-17 19:40 标题: Java并发编程-再谈 AbstractQueuedSynchronizer 1 ：独占模式（5）

实战举例：线程阻塞上述流程只是描述了构建数据结构的过程，并没有描述线程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就没有必要被阻塞，提升了性能。

欢迎光临电子技术论坛_中国专业的电子工程师学习交流社区-中电网技术论坛 (http://bbs.eccn.com/)