@guyeu
@luckyrayyy
谢谢回复，之前这块确实想错了，看来以后发帖前还是得看仔细，我承认错误。

不过看完还是有疑问。分析如下


- 入参`node`所代表的线程（这个 node 的 Thread 成员）一定是当前执行的线程，
- 看第一个 if 的判断：
- 如果`propagate > 0`成立的话，说明还有剩余共享锁可以获取，那么短路后面条件。
- 如果`propagate = 0`成立的话，说明没有剩余共享锁可以获取了，按理说不需要唤醒后继的。也就是说，很多情况下，调用 doReleaseShared，会造成 acquire thread 不必要的唤醒。
- 继续看，如果`propagate > 0`不成立，而`h.waitStatus < 0`成立。这说明旧 head 的 status<0 。但如果你看 doReleaseShared 的逻辑，会发现在 unparkSuccessor 之前就会 CAS 设置 head 的 status 为 0 的，在 unparkSuccessor 也会进行一次 CAS 尝试，因为 head 的 status 为 0 代表一种中间状态（ head 的后继代表的线程已经唤醒，但它还没有做完工作），或者代表 head 是 tail 。而这里旧 head 的 status<0，只能是由于 doReleaseShared 里的`compareAndSetWaitStatus(h, 0, Node.PROPAGATE)`的操作，而且由于当前执行 setHeadAndPropagate 的线程只会在最后一句才执行 doReleaseShared，所以出现这种情况，一定是因为有另一个线程在调用 doReleaseShared 才能造成，而这很可能是因为在中间状态时，又有人释放了共享锁。
- 继续看，如果`propagate > 0`不成立，且`h.waitStatus < 0`不成立，而第二个`h.waitStatus < 0`成立。注意，第二个`h.waitStatus < 0`里的 h 是新 head （很可能就是入参 node ）。第一个`h.waitStatus < 0`不成立很正常，因为它一般为 0 。第二个`h.waitStatus < 0`成立也很正常，因为只要新 head 不是队尾，那么新 head 的 status 肯定是 SIGNAL 。所以这种情况只会造成不必要的唤醒。


简单的说，我认为，检查第一个`h.waitStatus < 0`，是因为被唤醒的线程处于中间状态，而 doReleaseShared 在这个中间状态，只会设置`compareAndSetWaitStatus(h, 0, Node.PROPAGATE)`,不会调用 unparkSuccessor(h);，因为线程已经被唤醒了。

但检查第二个`h.waitStatus < 0`就有点想不通，感觉他只会造成不必要的唤醒？好奇怪