AQS深入理解 shouldParkAfterFailedAcquire源码分析状态为0或PROPAGATE的情况分析

绝地灬酷狼 2023-02-14 02:10 3阅读 0赞

### 文章目录 ###

*  流程分析
 *   *  谁是调用shouldParkAfterFailedAcquire的线程
     *  什么时候会从parkAndCheckInterrupt中唤醒
     *  释放锁后，唤醒head后继的条件
 *  shouldParkAfterFailedAcquire源码分析
 *  关于shouldParkAfterFailedAcquire的疑问
 *   *  为什么检测到0后，一定要设置成SIGNAL，然后继续下一次循环。直接返回true不行吗
     *   *  node刚成为新队尾，但还没有将旧队尾的状态设置为SIGNAL
         *  node的前驱为head
         *  总结
     *  为什么检测到PROPAGATE后，一定要设置成SIGNAL，然后继续下一次循环。直接返回true不行吗
 *  总结

# 流程分析 #

[JUC框架 系列文章目录][JUC_]

## 谁是调用shouldParkAfterFailedAcquire的线程 ##

以获取独占锁的方法`acquireQueued`为例

final boolean acquireQueued(final Node node, int arg) { 
            boolean failed = true;
            try { 
                boolean interrupted = false;
                for (;;) { 
                    final Node p = node.predecessor();
                    if (p == head && tryAcquire(arg)) { 
                        setHead(node);
                        p.next = null; // help GC
                        failed = false;
                        return interrupted;
                    }
                    // 执行到这里，说明
                    // 已经尝试过获取锁了，但还是失败了（当然有可能是因为p != head）
                    if (shouldParkAfterFailedAcquire(p, node) &&
                        parkAndCheckInterrupt())
                        interrupted = true;
                }
            } finally { 
                if (failed)
                    cancelAcquire(node);
            }
        }

首先要知道调用`acquireQueued`的线程一定是`node`的代表线程，也就是最开始调用`lock()`方法的那个线程，在`acquireQueued`的死循环中，尽管可能 重复着 阻塞和被唤醒 的过程，但不管怎么说，**执行`acquireQueued`的任何代码的线程，一定是参数`node`的代表线程。**

与`acquireQueued`相对，再以获取共享锁的`doAcquireShared`方法为例：

private void doAcquireShared(int arg) { 
            final Node node = addWaiter(Node.SHARED);//注意，这个node在这里
            boolean failed = true;
            try { 
                boolean interrupted = false;
                for (;;) { 
                    final Node p = node.predecessor();
                    if (p == head) { 
                        int r = tryAcquireShared(arg);
                        if (r >= 0) { 
                            setHeadAndPropagate(node, r);
                            p.next = null; // help GC
                            if (interrupted)
                                selfInterrupt();
                            failed = false;
                            return;
                        }
                    }
                    // 执行到这里，说明
                    // 已经尝试过获取锁了，但还是失败了（当然有可能是因为p != head）
                    if (shouldParkAfterFailedAcquire(p, node) &&
                        parkAndCheckInterrupt())
                        interrupted = true;
                }
            } finally { 
                if (failed)
                    cancelAcquire(node);
            }
        }

同样的，**执行`doAcquireShared`的任何代码的线程，一定是参数`node`的代表线程**。其次你也会发现，`doAcquireShared`的方法逻辑，和`acquireQueued`方法的逻辑大体一致，只是在获取锁成功后干的事情略有不同：

*  获取独占锁成功是，`tryAcquire`返回了true，但调用的是`setHead`。
 *  获取共享锁成功是，`tryAcquireShared`返回了true，但调用的是`setHeadAndPropagate`。
 *  另外，补上中断状态的时机不同。共享锁补上的时机是直接在`doAcquireShared`里，而独占锁补上中断状态的时机是，`acquireQueued`函数返回后，在`acquire`里做的。

总结：

*  执行`shouldParkAfterFailedAcquire`的线程，一定是参数`node`的代表线程，不管是独占锁还是共享锁。
 *  执行`shouldParkAfterFailedAcquire`前，线程在此次循环中，已经尝试过获取锁了，但还是失败了。

## 什么时候会从parkAndCheckInterrupt中唤醒 ##

还是以独占锁和共享锁二者一起考虑。

*  最通常的情况，head节点的代表线程即exclusiveOwnerThread这个线程，唤醒了阻塞在`parkAndCheckInterrupt`的线程，此时这个阻塞线程一定是head的后继。
 *  其他情况，阻塞在`parkAndCheckInterrupt`的线程被中断了，此时线程马上被唤醒，继续for循环。任何时候别的线程都可以来中断阻塞线程。
 *  阻塞在`parkAndCheckInterrupt`的线程超时了，此时线程马上被唤醒，继续for循环。

总结：

*  考虑所有情况的话，阻塞在`parkAndCheckInterrupt`的线程可以在任何时候被唤醒。

## 释放锁后，唤醒head后继的条件 ##

首先分析独占锁：

public final boolean release(int arg) { 
        if (tryRelease(arg)) { //这里已经释放了独占锁
            Node h = head;
            if (h != null && h.waitStatus != 0)
                unparkSuccessor(h);
            return true;
        }
        return false;
    }

可见唤醒head后继的条件是，head的状态不为0就可以了。

private void unparkSuccessor(Node node) { 
            int ws = node.waitStatus;
            if (ws < 0)
                compareAndSetWaitStatus(node, ws, 0);
    
            Node s = node.next;
            if (s == null || s.waitStatus > 0) { 
                s = null;
                for (Node t = tail; t != null && t != node; t = t.prev)
                    if (t.waitStatus <= 0)
                        s = t;
            }
            if (s != null)
                LockSupport.unpark(s.thread);
        }

根据`unparkSuccessor`的逻辑可知，在独占锁中，head的状态为0（因为`if (ws < 0) compareAndSetWaitStatus(node, ws, 0);`），代表head的后继节点即将被唤醒，或者已经被唤醒。head的状态为0属于一种中间状态，因为：

*  如果head的后继唤醒后能获得锁，那么head的后继就会成为新head，只要新head不为tail，那么新head的状态一般都为`SIGNAL`。
 *  如果head的后继唤醒后不能获得锁，那么这个线程又会执行`shouldParkAfterFailedAcquire`，再把head的状态置为`SIGNAL`。

再看共享锁：

public final boolean releaseShared(int arg) { 
        if (tryReleaseShared(arg)) { //这里已经释放了共享锁
            doReleaseShared();
            return true;
        }
        return false;
    }
    
    private void doReleaseShared() { 
        for (;;) { 
            Node h = head;
            if (h != null && h != tail) { 
                int ws = h.waitStatus;
                if (ws == Node.SIGNAL) { 
                    if (!compareAndSetWaitStatus(h, Node.SIGNAL, 0))
                        continue;            // loop to recheck cases
                    unparkSuccessor(h);
                }
                else if (ws == 0 &&
                         !compareAndSetWaitStatus(h, 0, Node.PROPAGATE))
                    continue;                // loop on failed CAS
            }
            if (h == head)                   // loop if head changed
                break;
        }
    }

可见唤醒head后继的条件稍微有点苛刻，必须head的状态为`SIGNAL`且设置状态从`SIGNAL`变成0成功，才可以去唤醒head后继。

总之：

*  head的状态为0，代表head的后继节点即将被唤醒，或者已经被唤醒。
 *  head的状态为0，属于一种中间状态。
 *  最重要的，**head的状态为0，代表有人刚释放了锁**。

# shouldParkAfterFailedAcquire源码分析 #

本函数，简单的讲就是把node的有效前驱（有效是指node不是CANCELLED的）找到，并且将有效前驱的状态设置为`SIGNAL`，之后便返回true代表马上可以阻塞了。

private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) { 
            int ws = pred.waitStatus;
            if (ws == Node.SIGNAL)
                /* * 前驱节点已经设置了SIGNAL，闹钟已经设好，现在我可以安心睡觉（阻塞）了。 * 如果前驱变成了head，并且head的代表线程exclusiveOwnerThread释放了锁， * 就会来根据这个SIGNAL来唤醒自己 */
                return true;
            if (ws > 0) { 
                /* * 发现传入的前驱的状态大于0，即CANCELLED。说明前驱节点已经因为超时或响应了中断， * 而取消了自己。所以需要跨越掉这些CANCELLED节点，直到找到一个<=0的节点 */
                do { 
                    node.prev = pred = pred.prev;
                } while (pred.waitStatus > 0);
                pred.next = node;
            } else { 
                /* * 进入这个分支，ws只能是0或PROPAGATE。 * CAS设置ws为SIGNAL */
                compareAndSetWaitStatus(pred, ws, Node.SIGNAL);
            }
            return false;
        }

*  如果前驱节点的状态为`SIGNAL`，说明闹钟标志已设好，返回true表示设置完毕。
 *  如果前驱节点的状态为`CANCELLED`，说明前驱节点本身不再等待了，需要跨越这些节点，然后找到一个有效节点，再把node和这个有效节点的前驱后继连接好。
 *  如果是其他情况，那么CAS尝试设置前驱节点为`SIGNAL`。

由于shouldParkAfterFailedAcquire函数在`acquireQueued`的调用中处于一个死循环中（独占锁对应的是`acquireQueued`里的死循环，共享锁对应的是`doAcquireShared`的死循环），且因为shouldParkAfterFailedAcquire函数若返回false，那么此函数必将至少执行两次才能阻塞自己。

*  `shouldParkAfterFailedAcquire`只有在检测到前驱的状态为`SIGNAL`才能返回true，只有true才会执行到`parkAndCheckInterrupt`。
 *  `shouldParkAfterFailedAcquire`返回false后，进入下一次循环，当前线程又会再次尝试获取锁（`p == head && tryAcquire(arg)`）。或者说，每次执行`shouldParkAfterFailedAcquire`，都说明当前循环 尝试过获取锁了，但失败了。
 *  如果刚开始前驱的状态为0，那么需要第一次执行`compareAndSetWaitStatus(pred, ws, Node.SIGNAL)`返回false并进入下一次循环，第二次才能进入`if (ws == Node.SIGNAL)`分支，所以说 至少执行两次。
 *  死循环保证了最终一定能设置前驱为`SIGNAL`成功的。（考虑当前线程一直不能获取到锁）

# 关于shouldParkAfterFailedAcquire的疑问 #

private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) { 
            int ws = pred.waitStatus;
            if (ws == Node.SIGNAL)
                return true;
            if (ws > 0) { 
                do { 
                    node.prev = pred = pred.prev;
                } while (pred.waitStatus > 0);
                pred.next = node;
            } else { 
            	// 为什么检测到0或PROPAGATE后，一定要设置成SIGNAL，
            	// 然后继续下一次循环(因为返回的false)。直接返回true不行吗
                compareAndSetWaitStatus(pred, ws, Node.SIGNAL);
            }
            return false;
        }

## 为什么检测到0后，一定要设置成SIGNAL，然后继续下一次循环。直接返回true不行吗 ##

首先得思考，什么时候`node`的前驱`pred`的状态为0。

### node刚成为新队尾，但还没有将旧队尾的状态设置为SIGNAL ###

这种情况是最常见的，比如现在AQS的等待队列中有很多node正在等待，当前线程现在刚执行完毕`addWaiter`（node刚成为新队尾），然后现在开始执行获取锁的死循环（独占锁对应的是`acquireQueued`里的死循环，共享锁对应的是`doAcquireShared`的死循环），此时node的前驱，也就是旧队尾的状态肯定还是0（也就是默认初始化的值），然后死循环执行两次，第一次执行`shouldParkAfterFailedAcquire`自然会检测到前驱状态为0，然后将0设置为`SIGNAL`；第二次执行`shouldParkAfterFailedAcquire`，直接返回true。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FubGlhbjUyMw_size_16_color_FFFFFF_t_70]  
很明显，这种情况线程会进行`if (p == head && tryAcquire(arg))`这样的判断两次（共享锁也是这样，只不过是分开写的）。

*  做`if (p == head && tryAcquire(arg))`判断两次，是有好处的。
 *  在获取共享锁的死循环，每次都会重新获取`node`的前驱（`node.predecessor()`）
 *  上图中，也有可能在第三步和第四步之间，从head到新tail之间的node都取消掉了，使得新tail的前驱变成了head，说不定此时获取锁也能成功呢，所以这第二次`if (p == head && tryAcquire(arg))`判断是很有必要的。

### node的前驱为head ###

*  除了上一章的情况外，`pred`作为一个肯定不为队尾的节点，它的状态为0的情况，只能是本文章节**释放锁后，唤醒head后继的条件**中，所说的中间状态。**这种中间状态只可能在head上出现，所以`pred`肯定是head。所以`node`现在是head后继。**

再结合前面总结出的两个结论：

*  考虑所有情况的话，阻塞在`parkAndCheckInterrupt`的线程可以在任何时候被唤醒。
 *  执行`shouldParkAfterFailedAcquire`前，线程在此次循环中，已经尝试过获取锁了，但还是失败了。

那么shouldParkAfterFailedAcquire中检测到0的情况可以是下面：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FubGlhbjUyMw_size_16_color_FFFFFF_t_70 1]  
考虑本章场景，在`shouldParkAfterFailedAcquire`中，如果检测到`node`的前驱的状态为0，那么设置状态为SIGNAL，但设置状态其实是无所谓的。重点在于，这样`shouldParkAfterFailedAcquire`会返回false，继续下一次循环，也就能再一次尝试获取锁。  
按照本章场景，再一次尝试获取锁，肯定能成功。

### 总结 ###

检测到0后，一定要设置成SIGNAL的原因：

*  设置前驱状态为SIGNAL，以便当前线程阻塞后，前驱能根据SIGNAL状态来唤醒自己。（具体看章节**释放锁后，唤醒head后继的条件**）

设置成SIGNAL后会返回false的原因：

*  返回false后，下一次循环开始，会重新获取node的前驱，前驱如果就是head，那么还会重新尝试获取锁。这次重新尝试是有必要的，某些场景下，重新尝试获取锁会成功。

## 为什么检测到PROPAGATE后，一定要设置成SIGNAL，然后继续下一次循环。直接返回true不行吗 ##

PROPAGATE只能在使用共享锁的时候出现，并且只可能设置在head上。

private void doReleaseShared() { 
        for (;;) { 
            Node h = head;
            if (h != null && h != tail) { 
                int ws = h.waitStatus;
                if (ws == Node.SIGNAL) { 
                    if (!compareAndSetWaitStatus(h, Node.SIGNAL, 0))
                        continue;            
                    unparkSuccessor(h);
                }
                else if (ws == 0 &&
                         !compareAndSetWaitStatus(h, 0, Node.PROPAGATE))//设置在head上
                    continue;                
            }
            if (h == head)                   
                break;
        }
    }

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FubGlhbjUyMw_size_16_color_FFFFFF_t_70 2]  
其实本章场景和上一章类似，当获取锁的下一次循环开始后，会发现再一次获取锁，就能成功了。  
总结原因和上一章一样，这里就不写了。

# 总结 #

*  对于非队尾节点，如果它的状态为0或PROPAGATE，那么它肯定是head。
 *  等待队列中有多个节点时，如果head的状态为0或PROPAGATE，说明head处于一种中间状态，且此时有线程刚才释放锁了。而对于acquire thread来说，如果检测到这种状态，说明再次acquire是极有可能获得到锁的。

[JUC_]: https://blog.csdn.net/anlian523/article/details/106598910
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FubGlhbjUyMw_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/20200531154243604.jpg?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FubGlhbjUyMw==,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FubGlhbjUyMw_size_16_color_FFFFFF_t_70 1]: https://img-blog.csdnimg.cn/20200531145402238.jpg?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FubGlhbjUyMw==,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FubGlhbjUyMw_size_16_color_FFFFFF_t_70 2]: https://img-blog.csdnimg.cn/20200531161226432.jpg?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FubGlhbjUyMw==,size_16,color_FFFFFF,t_70