漫話：如何給女朋友解釋什麼是樂觀鎖與悲觀鎖

最近，五一小長假的放假時間調整了，決定趁著假期出去玩一玩。我和女朋友商量好，我負責制定行程，她負責購買出行用品。相安無事，我正在各家比價中，不知道發生了什麼，女朋友買買買竟然不高興了。

在《如何給女朋友解釋什麼是併發和並行》一文中我們介紹過併發和並行。當程式中可能出現併發的情況時，我們就需要透過一定的手段來保證在併發情況下資料的準確性，透過這種手段保證了當使用者和其他使用者一起操作時，所得到的結果和他單獨操作時的禱告的結果是一樣的。

這種手段就叫做併發控制。併發控制的目的是保證一個使用者的工作不會對另一個使用者的工作產生不合理的影響。

沒有做好併發控制，就可能導致臟讀、幻讀和不可重覆讀等問題。



實現併發控制的主要手段大致可以分為樂觀併發控制和悲觀併發控制兩種。

在開始介紹之前要明確一下：無論是悲觀鎖還是樂觀鎖，都是人們定義出來的概念，可以認為是一種思想。其實不僅僅是關係型資料庫系統中有樂觀鎖和悲觀鎖的概念，像memcache、hibernate、tair等都有類似的概念。所以，不應該拿樂觀鎖、悲觀鎖和其他的資料庫鎖等進行對比。

當我們要對一個資料庫中的一條資料進行修改的時候，為了避免同時被其他人修改，最好的辦法就是直接對該資料進行加鎖以防止併發。

這種藉助資料庫鎖機制在修改資料之前先鎖定，再修改的方式被稱之為悲觀併發控制（又名“悲觀鎖”，Pessimistic Concurrency Control，縮寫“PCC”）。

之所以叫做悲觀鎖，是因為這是一種對資料的修改抱有悲觀態度的併發控制方式。我們一般認為資料被併發修改的機率比較大，所以需要在修改之前先加鎖。

悲觀併發控制實際上是“先取鎖再訪問”的保守策略，為資料處理的安全提供了保證。

但是在效率方面，處理加鎖的機制會讓資料庫產生額外的開銷，還有增加產生死鎖的機會；另外，還會降低並行性，一個事務如果鎖定了某行資料，其他事務就必須等待該事務處理完才可以處理那行資料。

樂觀鎖（ Optimistic Locking ） 是相對悲觀鎖而言的，樂觀鎖假設資料一般情況下不會造成衝突，所以在資料進行提交更新的時候，才會正式對資料的衝突與否進行檢測，如果發現衝突了，則讓傳回用戶錯誤的資訊，讓使用者決定如何去做。

相對於悲觀鎖，在對資料庫進行處理的時候，樂觀鎖並不會使用資料庫提供的鎖機制。一般的實現樂觀鎖的方式就是記錄資料版本。

樂觀併發控制相信事務之間的資料競爭(data race)的機率是比較小的，因此盡可能直接做下去，直到提交的時候才去鎖定，所以不會產生任何鎖和死鎖。

悲觀鎖的實現，往往依靠資料庫提供的鎖機制。在資料庫中，悲觀鎖的流程如下：

• 在對記錄進行修改前，先嘗試為該記錄加上排他鎖（exclusive locking）。
• 如果加鎖失敗，說明該記錄正在被修改，那麼當前查詢可能要等待或者丟擲異常。具體響應方式由開發者根據實際需要決定。
• 如果成功加鎖，那麼就可以對記錄做修改，事務完成後就會解鎖了。
• 其間如果有其他對該記錄做修改或加排他鎖的操作，都會等待我們解鎖或直接丟擲異常。

我們拿比較常用的MySql Innodb引擎舉例，來說明一下在SQL中如何使用悲觀鎖。

要使用悲觀鎖，我們必須關閉mysql資料庫的自動提交屬性，因為MySQL預設使用autocommit樣式，也就是說，當你執行一個更新操作後，MySQL會立刻將結果進行提交。set autocommit=0;

我們舉一個簡單的例子，如淘寶下單過程中扣減庫存的需求說明一下如何使用悲觀鎖：

//0.開始事務
begin; 
//1.查詢出商品庫存資訊
select quantity from items where id=1 for update;
//2.修改商品庫存為2
update items set quantity=2 where id = 1;
//3.提交事務
commit;

以上，在對id = 1的記錄修改前，先透過for update的方式進行加鎖，然後再進行修改。這就是比較典型的悲觀鎖策略。

如果以上修改庫存的程式碼發生併發，同一時間只有一個執行緒可以開啟事務並獲得id=1的鎖，其它的事務必須等本次事務提交之後才能執行。這樣我們可以保證當前的資料不會被其它事務修改。

上面我們提到，使用select…for update會把資料給鎖住，不過我們需要註意一些鎖的級別，MySQL InnoDB預設行級鎖。行級鎖都是基於索引的，如果一條SQL陳述句用不到索引是不會使用行級鎖的，會使用表級鎖把整張表鎖住，這點需要註意。

樂觀鎖實現方式

使用樂觀鎖就不需要藉助資料庫的鎖機制了。

樂觀鎖的概念中其實已經闡述了他的具體實現細節：主要就是兩個步驟：衝突檢測和資料更新。其實現方式有一種比較典型的就是Compare and Swap(CAS)。

CAS是項樂觀鎖技術，當多個執行緒嘗試使用CAS同時更新同一個變數時，只有其中一個執行緒能更新變數的值，而其它執行緒都失敗，失敗的執行緒並不會被掛起，而是被告知這次競爭中失敗，並可以再次嘗試。

比如前面的扣減庫存問題，透過樂觀鎖可以實現如下：

//查詢出商品庫存資訊，quantity = 3
select quantity from items where id=1
//修改商品庫存為2
update items set quantity=2 where id=1 and quantity = 3;

以上，我們在更新之前，先查詢一下庫存表中當前庫存數（quantity），然後在做update的時候，以庫存數作為一個修改條件。當我們提交更新的時候，判斷資料庫表對應記錄的當前庫存數與第一次取出來的庫存數進行比對，如果資料庫表當前庫存數與第一次取出來的庫存數相等，則予以更新，否則認為是過期資料。

以上更新陳述句存在一個比較重要的問題，即傳說中的ABA問題。

比如說一個執行緒one從資料庫中取出庫存數3，這時候另一個執行緒two也從資料庫中庫存數3，並且two進行了一些操作變成了2，然後two又將庫存數變成3，這時候執行緒one進行CAS操作發現資料庫中仍然是3，然後one操作成功。儘管執行緒one的CAS操作成功，但是不代表這個過程就是沒有問題的。

有一個比較好的辦法可以解決ABA問題，那就是透過一個單獨的可以順序遞增的version欄位。改為以下方式即可：

//查詢出商品資訊，version = 1
select version from items where id=1
//修改商品庫存為2
update items set quantity=2,version = 3 where id=1 and version = 2;

樂觀鎖每次在執行資料的修改操作時，都會帶上一個版本號，一旦版本號和資料的版本號一致就可以執行修改操作並對版本號執行+1操作，否則就執行失敗。因為每次操作的版本號都會隨之增加，所以不會出現ABA問題，因為版本號只會增加不會減少。

除了version以外，還可以使用時間戳，因為時間戳天然具有順序遞增性。

以上SQL其實還是有一定的問題的，就是一旦發上高併發的時候，就只有一個執行緒可以修改成功，那麼就會存在大量的失敗。

對於像淘寶這樣的電商網站，高併發是常有的事，總讓使用者感知到失敗顯然是不合理的。所以，還是要想辦法減少樂觀鎖的粒度的。

有一條比較好的建議，可以減小樂觀鎖力度，最大程度的提升吞吐率，提高併發能力！如下：

//修改商品庫存
update item 
set quantity=quantity - 1 
where id = 1 and quantity - 1 > 0

以上SQL陳述句中，如果使用者下單數為1，則透過quantity - 1 > 0的方式進行樂觀鎖控制。

以上update陳述句，在執行過程中，會在一次原子操作中自己查詢一遍quantity的值，並將其扣減掉1。

高併發環境下鎖粒度把控是一門重要的學問，選擇一個好的鎖，在保證資料安全的情況下，可以大大提升吞吐率，進而提升效能。

在樂觀鎖與悲觀鎖的選擇上面，主要看下兩者的區別以及適用場景就可以了。

1、樂觀鎖並未真正加鎖，效率高。一旦鎖的粒度掌握不好，更新失敗的機率就會比較高，容易發生業務失敗。 

2、悲觀鎖依賴資料庫鎖，效率低。更新失敗的機率比較低。

隨著網際網路三高架構（高併發、高效能、高可用）的提出，悲觀鎖已經越來越少的被使用到生產環境中了，尤其是併發量比較大的業務場景。