ReentrantLock类的hasQueuedPredecessors方法和head节点的含义

PART 1

1、如果h==t成立，h和t均为null或是同一个具体的节点，无后继节点，返回false。
2、如果h!=t成立，head.next是否为null，如果为null，返回true。什么情况下h!=t的同时h.next==null？？，有其他线程第一次正在入队时，可能会出现。见AQS的enq方法，compareAndSetHead(node)完成，还没执行tail=head语句时，此时tail=null,head=newNode,head.next=null。
3、如果h!=t成立，head.next != null，则判断head.next是否是当前线程，如果是返回false，否则返回true（head节点是获取到锁的节点，但是任意时刻head节点可能占用着锁，也可能释放了锁（unlock()）,未被阻塞的head.next节点对应的线程在任意时刻都是有必要去尝试获取锁）

1 public final boolean hasQueuedPredecessors() {
2     Node t = tail; 
3     Node h = head;
4     Node s;
5     return h != t &&
6         ((s = h.next) == null || s.thread != Thread.currentThread());
7 }

PART 2　　解释为什么要判断：s.thread != Thread.currentThread()

评论区3楼的提问差点让我以为我这里理解错并写错了，现在是12月，文章是4月份写的，都快忘光了...仔细再把文章和源码读了读，发现本文写的确实不够详细，有个地方还写的有点问题，漏了一些细节，因此来补充一下。 ---20191217

1、

根据ReentrantLock的解锁流程，也就是下面四个方法，可以看到当线程释放锁之后还是会在队列的head节点，但会把head的后续可唤醒节点进行唤醒（unpark）
也就是说任意时刻，head节点可能占用着锁（除了第一次执行enq()入队列时，head仅仅是个new Node()，没有实际对应任何线程，但是却“隐式”对应第一个获得锁但并未入队列的线程，和后续的head在含义上保持一致），也可能释放了锁（unlock()）,未被阻塞的head.next节点对应的线程在任意时刻都是有必要去尝试获取锁

1 public void unlock() {
2     sync.release(1);
3 }

2、

尝试释放锁，释放成功后把head.next从阻塞中唤醒

从这里以及后续的3和4可以看出，虽然线程已经释放了锁（state设置为0），但是并没有把head指向链表的下个节点（即进行类似head = head.next的操作）

这里就对应的第1点里说的，如果这里能看到，那么久可以直接看第5点了

1 public final boolean release(int arg) {
2     if (tryRelease(arg)) {
3         Node h = head;
4         if (h != null && h.waitStatus != 0)
5             unparkSuccessor(h);
6         return true;
7     }
8     return false;
9 }

3、

把state-1
当state=0时，把exclusiveOwnerThread设置为null，说明线程释放了锁

 1 protected final boolean tryRelease(int releases) {
 2     int c = getState() - releases;
 3     if (Thread.currentThread() != getExclusiveOwnerThread())
 4         throw new IllegalMonitorStateException();
 5     boolean free = false;
 6     if (c == 0) {
 7         free = true;
 8         setExclusiveOwnerThread(null);
 9     }
10     setState(c);
11     return free;
12 }

4、

把head.next指向下一个waitStatus<=0的节点，并把该节点从阻塞中唤醒

 1 private void unparkSuccessor(Node node) {
 2     int ws = node.waitStatus;
 3     if (ws < 0)
 4         compareAndSetWaitStatus(node, ws, 0);
 5 
 6     Node s = node.next;
 7     if (s == null || s.waitStatus > 0) {
 8         // 这里没看懂为什么要从tail节点倒序遍历？
 9         // 不是应该从head.next节点开始遍历更快嘛？
10         s = null;
11         for (Node t = tail; t != null && t != node; t = t.prev)
12             if (t.waitStatus <= 0)
13                 s = t;
14     }
15     if (s != null)
16         LockSupport.unpark(s.thread);
17 }

5、

需要提前知道一点：hasQueuedPredecessors()方法只在tryAcquire()方法里面被调用执行过，hasQueuedPredecessors()返回false表示要尝试获取锁

线程加锁的流程是：.lock() -> .acquire() -> tryAcquire()

这里我们先假设一个场景：A线程获取到了锁，然后B线程尝试去获取锁但是获取不到，此时链表的head是对用A线程，head.next对应B线程

当在B线程在第2行的tryAcquire()里面无法获取到锁时，线程B会通过下面第3行的addWaiter()方法被加入到等待链表当中，然后在第3行的acquireQueued()方法和第38行的parkAndCheckInterrupt()中park进入等待状态

在A线程释放锁之后，B线程会从38行处开始重新苏醒然后进入for(;;)循环，当B线程执行到第28行即再次执行tryAcquire()时，然后就会依次执行hasQueuedPredecessors()和s.thread != Thread.currentThread()。由前文可知，此时head仍然指向A线程，head.next也就是此处的s指向的是B线程，也同时是当前线程，所以s.thread != Thread.currentThread()为false，即此时需要尝试获取锁（再次重复这句话：未被阻塞的head.next节点对应的线程在任意时刻都是有必要去尝试获取锁）。

当此处B线程终于获得锁之后，会在第30行处把head指向B线程对应的链表结点。

 1 public final void acquire(int arg) {
 2     if (!tryAcquire(arg) &&
 3         acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
 4         selfInterrupt();
 5 }
 6 
 7 protected final boolean tryAcquire(int acquires) {
 8     // 省略部分不重要的
 9     
10     if (c == 0) {
11         if (!hasQueuedPredecessors() &&
12             compareAndSetState(0, acquires)) {
13             setExclusiveOwnerThread(current);
14             return true;
15         }
16     }
17     
18     // 省略部分不重要的
19 }
20 
21 final boolean acquireQueued(final Node node, int arg) {
22     boolean failed = true;
23     try {
24         boolean interrupted = false;
25         for (;;) {
26             final Node p = node.predecessor();
27             // 这里又执行了tryAcquire
28             if (p == head && tryAcquire(arg)) {
29                 // 把head指向当前节点
30                 setHead(node);
31                 p.next = null; // help GC
32                 failed = false;
33                 return interrupted;
34             }
35             // 获取不到锁，会在此处进入线程等待状态
36             // 后续被唤醒的话，也是从这里出来，然后继续for循环
37             if (shouldParkAfterFailedAcquire(p, node) &&
38                 parkAndCheckInterrupt())
39                 interrupted = true;
40         }
41     } finally {
42         if (failed)
43             cancelAcquire(node);
44     }
45 }

来源：oschina

链接：https://my.oschina.net/u/4353583/blog/4328878

标签