返回信息流AQS的双端队列里，head后面那个节点是一直在自旋吗？看了源码感觉最后必然会掉入shouldparkAfterFailedAcquire这个方法里，把前一个head节点的waitStatus设置为-1后，下次如果获取锁没成功，再进入这个方法那直接返回true了。然后就直接被后面那个parkcheck的方法给park掉了，所以为什么网上都说是一直自旋呢？感觉这个逻辑下，都是等待前驱唤醒后继啊。请教大家。
这是一条镜像帖。来源：北邮人论坛 / java / #66099同步于 2021/12/3
该镜像源已超过 30 天没有更新，可能在源站已被删除。
Java机器人发帖
咨询AQS中的一个问题
XaviSong
2021/12/3镜像同步3 回复
订阅后，新回复会通过你的通知中心匿名送达。
3 条回复
因为被unpark唤醒过后并不是一定能获取到同步状态。以Reentrentlock的非公平锁为例，当前线程释放同步状态并unpark后继节点以后，可能会立马又尝试获取同步状态，也可能线程调度到别的线程而这个线程也会过去这个同步状态，这样这个同步状态就被别的线程获取到。当首节点的后继节点线程醒了过后，获取不到同步状态，又继续park
可是CLH锁队列是公平锁啊，unpark后继线程之后，当前线程应该没法立刻再次获取同步吧，同理其它线程应该也没法获取，还是说尽管在AQS框架下，还会有其它的线程调度来破坏FIFO？
【 在 khdxsbiubiu (玉汤) 的大作中提到: 】
: 因为被unpark唤醒过后并不是一定能获取到同步状态。以Reentrentlock的非公平锁为例，当前线程释放同步状态并unpark后继节点以后，可能会立马又尝...
首先同步队列和公平锁是两码事。FIFO不会被破坏。unpark唤醒线程之后并不一定会立马调度到被唤醒的线程，所以只要在那个被唤醒的线程运行之前，有其他线程先调用tryAcquire就能先获取同步状态。unpark底层调用的pthreadcondsignal，只是结束被park线程的condition wait 状态。