AQS唤醒线程的时候为什么从后向前遍历

先来熟悉一下代码，挂起和唤醒这两部分

1. 尾部遍历源码

   private void unparkSuccessor(Node node) {
       //获取wait状态
       int ws = node.waitStatus;
       if (ws < 0)
           compareAndSetWaitStatus(node, ws, 0);// 将等待状态waitStatus设置为初始值0
       /**
        * 若后继结点为空，或状态为CANCEL（已失效），则从后尾部往前遍历找到最前的一个处于正常阻塞状态的结点
        * 进行唤醒
        */
       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);//唤醒线程
   }
   
   

   注意for循环中的逻辑：从尾部开始向前遍历，找到最前的一个处于正常阻塞状态的结点，直到节点重合（即等于当前节点）

2. 高并发下入队逻辑
   既然采用了从尾部遍历的逻辑，那么肯定是为了解决可能会出现的问题。而这个问题就在enq(…)方法中

   private Node enq(final Node node) {
       for (;;) {
           Node t = tail;
           if (t == null) { // Must initialize
               //队列为空需要初始化，创建空的头节点
               if (compareAndSetHead(new Node()))
                   tail = head;
           } else {
               node.prev = t;
               //set尾部节点
               if (compareAndSetTail(t, node)) {//当前节点置为尾部
                   t.next = node; //前驱节点的next指针指向当前节点
                   return t;
               }
           }
       }
   }
   
   

3. 原子性问题
   在该段方法中，将当前节点置于尾部使用了CAS来保证线程安全，但是请注意：在if语句块中的代码并没有使用任何手段来保证线程安全！

   也就是说，在高并发情况下，可能会出现这种情况：

   线程A通过CAS进入if语句块之后，发生上下文切换，此时线程B同样执行了该方法，并且执行完毕。然后线程C调用了unparkSuccessor方法。

   假如是从头到尾的遍历形式，线程A的next指针此时还是null！也就是说，会出现后续节点被漏掉的情况。

4. 图解流程
   线程A执行CAS将当前节点置为尾部：
   

   原本线程A要执行t.next = node;将node2的next设置为node3，但是，此时发生上下文切换，时间片交由线程B，也就是说，此时node2的next还是null

   线程B执行enq逻辑，最终CLH队列如图所示：
   

   此时发生上下文切换，时间片交由线程C，线程C调用了unparkSuccessor方法，假如是从头到尾的遍历形式，在node2就会发现，next指针为null，似乎没有后续节点了。

   此时发生上下文切换，时间片交由线程A，A将node2的next=node3。奇怪的现象发生了：对于线程C来说，后续没有node3和node4，但是对于其它线程来说，却出现了这两个节点

5. 结尾
   从头部遍历会出现这种问题的原因我们找到了，最后我们再来说说为什么从尾部遍历不会出现这种问题呢？

   其最根本的原因在于：
   node.prev = t;先于CAS执行，也就是说，你在将当前节点置为尾部之前就已经把前驱节点赋值了，自然不会出现prev=null的情况

热评：
阿sea：线程C调用unparkSuccessor的场景应该是不存在的，可以举其它例子，如：当前持有独占资源的线程获得CPU时间片（假设是ReentrantLock）调用unlock()方法