阻塞、無饑餓、無障礙、無鎖、無等待幾種。

阻塞

一個線程是阻塞的，那么在其他線程釋放資源之前，當前線程無法繼續執行。當我們使用synchronized關鍵字或者重入鎖時，我們得到的就是阻塞的線程。

synchronize關鍵字和重入鎖都試圖在執行后續代碼前，得到臨界區的鎖，如果得不到，線程就會被掛起等待，直到占有了所需資源為止。

無饑餓(Starvation-Free)

如果線程之間是有優先級的，那么線程調度的時候總是會傾向于先滿足高優先級的線程。也就是說，對于同一個資源的分配，是不公平的！圖1.7中顯示了非公平鎖與公平鎖兩種情況(五角星表示高優先級線程)。對于非公平鎖來說，系統允許高優先級的線程插隊。這樣有可能導致低優先級線程產生饑餓。但如果鎖是公平的，按照先來后到的規則，那么饑餓就不會產生，不管新來的線程優先級多高，要想獲得資源，就必須乖乖排隊，這樣所有的線程都有機會執行。

無障礙(Obstruction-Free)

無障礙是一種最弱的非阻塞調度。兩個線程如果無障礙地執行，那么不會因為臨界區的問題導致一方被掛起。換言之，大家都可以大搖大擺地進入臨界區了。那么大家一起修改共享數據，把數據改壞了怎么辦呢？對于無障礙的線程來說，一旦檢測到這種情況，它就會立即對自己所做的修改進行回滾，確保數據安全。但如果沒有數據競爭發生，那么線程就可以順利完成自己的工作，走出臨界區。

如果說阻塞的控制方式是悲觀策略，也就是說，系統認為兩個線程之間很有可能發生不幸的沖突，因此以保護共享數據為第一優先級，相對來說，非阻塞的調度就是一種樂觀的策略。它認為多個線程之間很有可能不會發生沖突，或者說這種概率不大。因此大家都應該無障礙地執行，但是一旦檢測到沖突，就應該進行回滾。

從這個策略中也可以看到，無障礙的多線程程序并不一定能順暢運行。因為當臨界區中存在嚴重的沖突時，所有的線程可能都會不斷地回滾自己的操作，而沒有一個線程可以走出臨界區。這種情況會影響系統的正常執行。所以，我們可能會非常希望在這一堆線程中，至少可以有一個線程能夠在有限的時間內完成自己的操作，而退出臨界區。至少這樣可以保證系統不會在臨界區中進行無限的等待。

一種可行的無障礙實現可以依賴一個"一致性標記"來實現。線程在操作之前，先讀取并保存這個標記，在操作完成后，再次讀取，檢查這個標記是否被更改過，如果兩者是一致的，則說明資源訪問沒有沖突。如果不一致，則說明資源可能在操作過程中與其他線程沖突，需要重試操作。而任何對資源有修改操作的線程，在修改數據前，都需要更新這個一致性標記，表示數據不再安全。

數據庫中樂觀鎖，應該比較熟悉，表中需要一個字段version(版本號)，每次更新數據version+1，更新的時候將版本號作為條件進行更新，根據更新影響的行數判斷更新是否成功，偽代碼如下：

多個線程更新同一條數據的時候，數據庫會對當前數據加鎖，同一時刻只有一個線程可以執行更新語句。

無鎖(Lock-Free)

無鎖的并行都是無障礙的。在無鎖的情況下，所有的線程都能嘗試對臨界區進行訪問，但不同的是，無鎖的并發保證必然有一個線程能夠在有限步內完成操作離開臨界區。

在無鎖的調用中，一個典型的特點是可能會包含一個無窮循環。在這個循環中，線程會不斷嘗試修改共享變量。如果沒有沖突，修改成功，那么程序退出，否則繼續嘗試修改。但無論如何，無鎖的并行總能保證有一個線程是可以勝出的，不至于全軍覆沒。至于臨界區中競爭失敗的線程，他們必須不斷重試，直到自己獲勝。如果運氣很不好，總是嘗試不成功，則會出現類似饑餓的先寫，線程會停止。

下面就是一段無鎖的示意代碼，如果修改不成功，那么循環永遠不會停止。

等待

無鎖只要求有一個線程可以在有限步內完成操作，而無等待則在無鎖的基礎上更進一步擴展。它要求所有線程都必須在有限步內完成，這樣不會引起饑餓問題。如果限制這個步驟的上限，還可以進一步分解為有界無等待和線程數無關的無等待等幾種，他們之間的區別只是對循環次數的限制不同。

一種典型的無等待結果就是RCU(Read Copy Update)。它的基本思想是，對數據的讀可以不加控制。因此，所有的讀線程都是無等待的，它們既不會被鎖定等待也不會引起任何沖突。但在寫數據的時候，先獲取原始數據的副本，接著只修改副本數據(這就是為什么讀可以不加控制)，修改完成后，在合適的時機回寫數據。

總結

本篇文章就到這里了，希望能夠給你帶來幫助，也希望您能夠多多關注服務器之家的更多內容！

原文鏈接：https://itsoku.blog.csdn.net/article/details/100036268