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

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

Mutual Exclusion互斥

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

Optimistic Concurrency Control樂觀并發(fā)鎖

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

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

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

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

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

轉(zhuǎn)載于:https://blog.51cto.com/lth2015/1684203

總結(jié)

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

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