自旋鎖和使執行緒休眠的非自旋鎖各有什麼適用場景？

1樓：invalid s

多個執行緒需要競爭較長時間使用的獨占性資源（印表機/網路等），此時應當用非自旋鎖。

多個執行緒需要修改同乙個資料結構，且修改動作經過精心優化，可以在很少幾個時鐘週期內完成時（典型如「把事先準備好的節點掛到鍊錶末端」），那麼可以用自旋鎖，甚至可以使用無鎖結構。

PS：無鎖是利用CPU提供的原子操作（典型如比較並交換）保證資料一致性，並不是字面意義的不用鎖。

說的更通俗一點：

如果某個資源在上鎖後，取得鎖的執行緒需要做較為複雜的一系列操作（於是需要耗用更多時鐘週期）、然後才能釋放鎖，那麼其它執行緒就應該用非自旋鎖交出執行權。

相反，如果可以通過演算法優化，使得取得鎖的執行緒只需執行很少幾條指令就可以釋放鎖，那麼其它執行緒就可以使用自旋鎖（但是，如果程式是在單核處理器上執行，應無條件使用非自旋鎖。這是因為壓根沒有其他CPU資源供其他執行緒使用，只能等當前執行緒耗盡自己的時間片）。

事實上，「盡量降低鎖的持有時間」是多執行緒演算法設計上的重點和難點所在。只要你清楚知道執行緒持有鎖的時間（精確到時鐘週期），自然就知道什麼時候該用什麼鎖了。

不過，由於執行環境太過複雜，理論預期被實踐打臉是經常發生的。

所以對稍為複雜的場景，最好是直接實現成兩個版本（c/c++可以用巨集控制切換），然後多做profile。

2樓：

對於hotspot來說，原來有PreBlockSpin，現在好像沒用了，變成了自適應自旋，不等於while(true)，自旋鎖可以減少執行緒切換的開銷

3樓：白河愁

聽起來好高階。。。

自旋鎖聽起來好像是，啟動乙個執行緒，用while(true)一直去訪問資源，有了資源之後再呼叫某些方法。

4樓：曹旭東

AQS中，在加鎖、放鎖的時候會使用自旋鎖，例如CountDownLatch(GC: CountDownLatch)

隨著多執行緒競爭情況的提公升，對自旋鎖的使用是，不用 -> 用 ->不用。

參見oracle_jrockit_the_definitive_guide/4.3.md at master · caoxudong/oracle_jrockit_the_definitive_guide · GitHub-瘦鎖thin-lock

知乎不能識別github位址中的錨點，還非要給我轉換我貼出來的url位址，蛋疼。

大家在位址裡找4.3.2.2.1節吧。