Node p = enq(node); ··· if (ws > 0 || !compareAndSetWaitStatus(p, ws, Node.SIGNAL))LockSupport.unpark(node.thread);// 喚醒節(jié)點(diǎn)上的線程return true; ···

通過enq放入同步隊(duì)列了，他自己會慢慢的爭搶鎖，就像synchronize中的wait，為什么這里要進(jìn)行一次unpark？

先看下判斷條件。

ws>0，說明是1，是CANCELLED狀態(tài)，!compareAndSetWaitStatus(p, ws, Node.SIGNAL)) 什么時(shí)候把前一個(gè)節(jié)點(diǎn)（enq(node);返回當(dāng)前節(jié)點(diǎn)的前一個(gè)節(jié)點(diǎn)，也就是原來的tail）賦值為SIGNAL狀態(tài)失敗？就是前一個(gè)節(jié)點(diǎn)是CANCELLED的時(shí)候，好吧這兩個(gè)好像是一個(gè)命題。

接著看為什么這里要進(jìn)行一次unpakr？

10-12行的迷惑性就來源于此。實(shí)際上，就算去掉10-12行也是滿足正確性要求的。因?yàn)榫€程T2釋放鎖后，依然會將從隊(duì)頭開始的第一個(gè)非取消節(jié)點(diǎn)喚醒，該節(jié)點(diǎn)會繼續(xù)ConditionObject#await()中的工作（稍后回去分析）。10-12行是為了進(jìn)一步提升性能，針對兩種情況：

• 如果插入node前，AQS內(nèi)部等待隊(duì)列的隊(duì)尾節(jié)點(diǎn)就已經(jīng)被取消，則滿足wc > 0
• 如果插入node后，AQS內(nèi)部等待隊(duì)列的隊(duì)尾節(jié)點(diǎn)已經(jīng)穩(wěn)定，滿足tail.waitStatus == 0，但在執(zhí)行ws >
  0之后!compareAndSetWaitStatus(p, ws,
  Node.SIGNAL)之前被取消，則CAS也會失敗，滿足compareAndSetWaitStatus(p, ws,
  Node.SIGNAL) == false

這兩種情況下，提前喚醒node能夠在等待鎖的同時(shí)，預(yù)先完成一部分ConditionObject#await()中無需同步的工作。這部分成本不能被輕易忽視，因?yàn)闂l件隊(duì)列被應(yīng)用最多的場景是高并發(fā)，大量線程累加起來的成本是很可觀的。
鏈接：https://www.jianshu.com/p/a932c184db52

在從condition隊(duì)列到同步隊(duì)列之前，tail節(jié)點(diǎn)被取消了

在從condition隊(duì)列到同步隊(duì)列之后，tail節(jié)點(diǎn)沒被取消，執(zhí)行完ws > 0
之后，這段時(shí)間，被取消了？就通過!compareAndSetWaitStatus(p, ws, Node.SIGNAL)再判斷一下

這個(gè)時(shí)候偷偷的提前執(zhí)行一波，就算不提前執(zhí)行，AQS隊(duì)列會不斷的把取消節(jié)點(diǎn)取消掉，最終還是被unpark的。
總的意思就是為了提升性能，沒有這里也是合理的。

總結(jié)

以上是生活随笔為你收集整理的Condition中的transferForSignal()方法的不解的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。