對于一個高并發的實時系統，低延遲-高吞吐是設計首要考慮的問題，對稱多處理器為程序并發提供了硬件平臺，當在多線程處理環境中，對一些公共資源的讀寫難免要互斥，誰獲得鎖，是隨機的，其他的CPU core只能在spinlock下不停的嘗試，耗費資源，我們應該將資源用于我們業務系統， 不能把性能浪費在不停的等待，嘗試，或者等待操作系統“翻牌子”的無用操作上。

當我們試圖建立一個高度可擴展的系統，最大的一個限制是：對同一個資源會有多個競爭寫操作。 計算機科學歸結為2個基本的方法：一是提供資源的互斥鎖，另一種是采取樂觀的策略。

Mutual Exclusion互斥

　　相互排斥是某個時間對同一個受保護資源保證只有一個寫操作，這是通過鎖策略實施的。鎖策略需要一名仲裁員，通常這個仲裁員是來自操作系統內核，當發生爭奪時它決定誰能獲得鎖，以及以什么順序獲得。這是一個非常昂貴的過程，通常我們需要更多的CPU循環實現我們的業務邏輯，而不是做這些“家務事”。對于那些等待進入臨界區，提前進行Mutual的還必須排隊，排隊效果（Little’s Law）導致延遲變得難以預測，最終制約了吞吐量。這是一種堵塞Blocking做法。

Optimistic Concurrency Control樂觀并發鎖

　　比如Hibernate或JPA都有樂觀鎖策略，見：JPA/Hibernate:基于版本的樂觀鎖并發控制，包括MongoDB的樂觀鎖。

　　樂觀的策略是：保留有數據的一個副本，當修改數據時，如果在此期間原本尚未發生變化，那么復制數據的變化覆蓋原本。如果在此期間原本發生的變化，你重復這個過程，直到成功為止。

　　這種重復過程中增加爭奪可能性，會造成排隊的效果，就如同相互排斥鎖一樣。現實中源代碼控制系統如Subversion或CVS都在使用這種算法。樂觀的策略能夠在爭奪數據情況下使用，但在爭奪一些硬件資源下卻工作得不怎么好，因為你不能獲得一個硬件資源的副本！ 也許只有通過CAS指導硬件完成執行原子數據的變化。

?筆記注：它假設多用戶并發的事務在處理時不會彼此互相影響，各事務能夠在不產生鎖的情況下處理各自影響的那部分數據。在提交數據更新之前，每個事務會先檢查在該事務讀取數據后，有沒有其他事務又修改了該數據。如果其他事務有更新的話，正在提交的事務會進行回滾。樂觀事務控制最早是由孔祥重（H.T.Kung）教授提出^[1]。

樂觀并發控制多數用于數據爭用不大、沖突較少的環境中，這種環境中，偶爾回滾事務的成本會低于讀取數據時鎖定數據的成本，因此可以獲得比其他并發控制方法更高的吞吐量。

轉載于:https://blog.51cto.com/lth2015/1684203

總結

以上是生活随笔為你收集整理的单独写原则Single Writer Principle的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。