AQS中存在设置waitState状态的方法 shouldParkAfterFailedAcquire ， 根据问题反推其设计的原因
shouldParkAfterFailedAcquire源码如下
以ReentrantLock为例子
问题
ReentrantLock进行unlock时，源码如下
AQS根据waitStatus进行队列中线程的唤醒，waitStatus初始值为0，
在ReentrantLock中，若waitStatus为-1，则标识后续的一个线程是需要被唤醒的线程
假设一种场景，两个线程并发执行，第一个线程T1先执行，获取到了锁，第二个线程T2后执行，T2执行到了shouldParkAfterFailedAcquire时，cpu调度时间用完，停止运行；T1进行unLock
根据unLock源码，T1直接执行完，不会进行unparkSuccessor(h)，也就没有对T2进行unpark。
此时若T2再次获得执行机会，进行shouldParkAfterFailedAcquire ，则设置前一个节点waitStatus为-1，及运行compareAndSetWaitStatus ，最终返回false
再看 shouldParkAfterFailedAcquire被调用的地方
此时返回false，循环继续，发现T2的前一个节点是头节点，进行tryAcquire。
若是公平锁，必然会获取锁成功。
若是非公平锁，存在获取锁失败的情况，再次调用shouldParkAfterFailedAcquire，返回true，进行调用 parkAndCheckInterrupt，及进行park操作
综述，shouldParkAfterFailedAcquire在compareAndSetWaitStatus为什么返回false，就比较明朗了，要是获取到锁的线程，没有对head后面的线程进行unpark操作，则该线程通过自旋，自己再次尝试获取锁
标签：shouldParkAfterFailedAcquire,系列,AQS,waitStatus,T2,线程,进行,waitState From： https://www.cnblogs.com/sxrtb/p/16585159.html