悲觀鎖與樂觀鎖是兩種常見的資源併發鎖設計思路，也是併發程式設計中一個非常基礎的概念。本文將對這兩種常見的鎖機制在資料庫資料上的實現進行比較系統的介紹。

悲觀鎖（Pessimistic Lock）

悲觀鎖的特點是先獲取鎖，再進行業務操作，即“悲觀”的認為獲取鎖是非常有可能失敗的，因此要先確保獲取鎖成功再進行業務操作。通常所說的“一鎖二查三更新”即指的是使用悲觀鎖。通常來講在資料庫上的悲觀鎖需要資料庫本身提供支援，即通過常用的select … for update操作來實現悲觀鎖。當資料庫執行select for update時會獲取被select中的資料行的行鎖，因此其他併發執行的select for update如果試圖選中同一行則會發生排斥（需要等待行鎖被釋放），因此達到鎖的效果。select for update獲取的行鎖會在當前事務結束時自動釋放，因此必須在事務中使用。

這裡需要注意的一點是不同的資料庫對select for update的實現和支援都是有所區別的，例如oracle支援select for update no wait，表示如果拿不到鎖立刻報錯，而不是等待，mysql就沒有no wait這個選項。另外mysql還有個問題是select for update語句執行中所有掃描過的行都會被鎖上，這一點很容易造成問題。因此如果在mysql中用悲觀鎖務必要確定走了索引，而不是全表掃描。

樂觀鎖（Optimistic Lock）

樂觀鎖的特點先進行業務操作，不到萬不得已不去拿鎖。即“樂觀”的認為拿鎖多半是會成功的，因此在進行完業務操作需要實際更新資料的最後一步再去拿一下鎖就好。

樂觀鎖在資料庫上的實現完全是邏輯的，不需要資料庫提供特殊的支援。一般的做法是在需要鎖的資料上增加一個版本號，或者時間戳，然後按照如下方式實現：

1. SELECT data AS old_data, version AS old_version FROM …;
2. 根據獲取的資料進行業務操作，得到new_data和new_version
3. UPDATE SET data = new_data, version = new_version WHERE version = old_version
if (updated row > 0) {
    // 樂觀鎖獲取成功，操作完成
} else
 
 {
    // 樂觀鎖獲取失敗，回滾並重試
}

樂觀鎖是否在事務中其實都是無所謂的，其底層機制是這樣：在資料庫內部update同一行的時候是不允許併發的，即資料庫每次執行一條update語句時會獲取被update行的寫鎖，直到這一行被成功更新後才釋放。因此在業務操作進行前獲取需要鎖的資料的當前版本號，然後實際更新資料時再次對比版本號確認與之前獲取的相同，並更新版本號，即可確認這之間沒有發生併發的修改。如果更新失敗即可認為老版本的資料已經被併發修改掉而不存在了，此時認為獲取鎖失敗，需要回滾整個業務操作並可根據需要重試整個過程。

總結

• 樂觀鎖在不發生取鎖失敗的情況下開銷比悲觀鎖小，但是一旦發生失敗回滾開銷則比較大，因此適合用在取鎖失敗概率比較小的場景，可以提升系統併發效能

• 樂觀鎖還適用於一些比較特殊的場景，例如在業務操作過程中無法和資料庫保持連線等悲觀鎖無法適用的地方

樂觀鎖  優缺點：

樂觀鎖：

樂觀鎖（ Optimistic Locking ） 相對悲觀鎖而言，樂觀鎖機制採取了更加寬鬆的加鎖機制。悲觀鎖大多數情況下依靠資料庫的鎖機制實現，以保證操作最大程度的獨佔性。但隨之而來的就是資料庫效能的大量開銷，特別是對長事務而言，這樣的開銷往往無法承受。而樂觀鎖機制在一定程度上解決了這個問題。樂觀鎖，大多是基於資料版本（ Version ）記錄機制實現。何謂資料版本？即為資料增加一個版本標識，在基於資料庫表的版本解決方案中，一般是通過為資料庫表增加一個 “version” 欄位來實現。讀取出資料時，將此版本號一同讀出，之後更新時，對此版本號加一。更新資料時將讀出的版本號作為一個條件，如果資料庫表中版本號與此版本號相同則能更新成功，否則更新失敗。

例如一個金融系統，當某個操作員讀取使用者的資料，並在讀出的使用者資料的基礎上進行修改時（如更改使用者帳戶餘額），如果採用悲觀鎖機制，也就意味著整個操作過 程中（從操作員讀出資料、開始修改直至提交修改結果的全過程，甚至還包括操作 員中途去煮咖啡的時間），資料庫記錄始終處於加鎖狀態，可以想見，如果面對幾百上千個併發，這樣的情況將導致怎樣的後果。

樂觀鎖機制在一定程度上解決了這個問題。樂觀鎖，大多是基於資料版本 （ Version ）記錄機制實現。何謂資料版本？即為資料增加一個版本標識，在基於資料庫表的版本解決方案中，一般是通過為資料庫表增加一個 “version” 欄位來實現（也可以採用另一種方式，同樣是在需要樂觀鎖控制的table中增加一個欄位，名稱無所謂，欄位型別使用時間戳timestamp, 和上面的version類似，也是在更新的時候檢查當前資料庫中資料的時間戳和自己更新前取到的時間戳進行對比，如果一致則OK，否則就是版本衝突）。

優點：

從上面的例子可以看出，樂觀鎖機制避免了長事務中的資料庫加鎖開銷，大大提升了大併發量下的系統整體效能表現。

缺點：

樂觀鎖機制往往基於系統中的資料儲存邏輯，因此也具備一定的侷限性，如在上例中，由於樂觀鎖機制是在我們的系統中實現，來自外部系統的更新操作不受我們系統的控制，因此可能會造成髒資料被更新到資料庫中。在系統設計階段，應該充分考慮到這些情況出現的可能性，並進行相應調整（如將樂觀鎖策略在資料庫儲存過程中實現，對外只開放基於此儲存過程的資料更新途徑，而不是將資料庫表直接對外公開）。

使用例項：

MySQL中的隔離級別和悲觀鎖及樂觀鎖示例

1，MySQL的事務支援 
MySQL的事務支援不是繫結在MySQL伺服器本身，而是與儲存引擎相關：

1. MyISAM：不支援事務，用於只讀程式提高效能   
2. InnoDB：支援ACID事務、行級鎖、併發   
3. Berkeley DB：支援事務  

2，隔離級別
隔離級別決定了一個session中的事務可能對另一個session的影響、併發session對資料庫的操作、一個session中所見資料的一致性 
ANSI標準定義了4個隔離級別，MySQL的InnoDB都支援：

Java程式碼

1. READ UNCOMMITTED：最低級別的隔離，通常又稱為dirty read，它允許一個事務讀取還沒commit的資料，這樣可能會提高效能，但是dirty read可能不是我們想要的   
2. READ COMMITTED：在一個事務中只允許已經commit的記錄可見，如果session中select還在查詢中，另一session此時insert一條記錄，則新新增的資料不可見   
3. REPEATABLE READ：在一個事務開始後，其他session對資料庫的修改在本事務中不可見，直到本事務commit或rollback。在一個事務中重複select的結果一樣，除非本事務中update資料庫。   
4. SERIALIZABLE：最高級別的隔離，只允許事務序列執行。為了達到此目的，資料庫會鎖住每行已經讀取的記錄，其他session不能修改資料直到前一事務結束，事務commit或取消時才釋放鎖。  

可以使用如下語句設定MySQL的session隔離級別：

1. 1.  SET TRANSACTION ISOLATION LEVEL {READ UNCOMMITTED | READ COMMITTED | REPEATABLE READ | SERIALIZABLE}   

MySQL預設的隔離級別是REPEATABLE READ，在設定隔離級別為READ UNCOMMITTED或SERIALIZABLE時要小心，READ UNCOMMITTED會導致資料完整性的嚴重問題，而SERIALIZABLE會導致效能問題並增加死鎖的機率

3，隔離級別
樂觀所和悲觀鎖策略： 
悲觀鎖：在讀取資料時鎖住那幾行，其他對這幾行的更新需要等到悲觀鎖結束時才能繼續 
樂觀所：讀取資料時不鎖，更新時檢查是否資料已經被更新過，如果是則取消當前更新 
一般在悲觀鎖的等待時間過長而不能接受時我們才會選擇樂觀鎖 
悲觀鎖的例子：

1. CREATE PROCEDURE tfer_funds     
2.        (from_account INT, to_account INT,tfer_amount NUMERIC(10,2),     
3.         OUT status INT, OUT message VARCHAR(30))     
4. BEGIN     
5.     DECLARE from_account_balance NUMERIC(10,2);     
6.     START TRANSACTION;     
7.     SELECT balance     
8.       INTO from_account_balance     
9.       FROM account_balance     
10.      WHERE account_id=from_account     
11.        FOR UPDATE;     
12.     IF from_account_balance>=tfer_amount THEN     
13.          UPDATE account_balance     
14.             SET balance=balance-tfer_amount     
15.           WHERE account_id=from_account;     
16.          UPDATE account_balance     
17.             SET balance=balance+tfer_amount     
18.           WHERE account_id=to_account;     
19.          COMMIT;     
20.          SET status=0;     
21.          SET message='OK';     
22.     ELSE     
23.          ROLLBACK;     
24.          SET status=-1;     
25.          SET message='Insufficient funds';     
26.     END IF;     
27. END;    

樂觀鎖的例子：

1. CREATE PROCEDURE tfer_funds     
2.     (from_account INT, to_account INT, tfer_amount NUMERIC(10,2),     
3.         OUT status INT, OUT message VARCHAR(30) )     
4. BEGIN     
5.     DECLARE from_account_balance    NUMERIC(8,2);     
6.     DECLARE from_account_balance2   NUMERIC(8,2);     
7.     DECLARE from_account_timestamp1 TIMESTAMP;     
8.     DECLARE from_account_timestamp2 TIMESTAMP;     
9.     SELECT account_timestamp,balance     
10.         INTO from_account_timestamp1,from_account_balance     
11.             FROM account_balance     
12.             WHERE account_id=from_account;     
13.     IF (from_account_balance>=tfer_amount) THEN     
14.         -- Here we perform some long running validation that     
15.         -- might take a few minutes */     
16.         CALL long_running_validation(from_account);     
17.         START TRANSACTION;     
18.         -- Make sure the account row has not been updated since     
19.         -- our initial check     
20.         SELECT account_timestamp, balance     
21.             INTO from_account_timestamp2,from_account_balance2     
22.             FROM account_balance     
23.             WHERE account_id=from_account     
24.             FOR UPDATE;     
25.         IF (from_account_timestamp1 <> from_account_timestamp2 OR     
26.             from_account_balance    <> from_account_balance2)  THEN     
27.             ROLLBACK;     
28.             SET status=-1;     
29.             SET message=CONCAT("Transaction cancelled due to concurrent update",     
30.                 " of account"  ,from_account);     
31.         ELSE     
32.             UPDATE account_balance     
33.                 SET balance=balance-tfer_amount     
34.                 WHERE account_id=from_account;     
35.             UPDATE account_balance     
36.                 SET balance=balance+tfer_amount     
37.                 WHERE account_id=to_account;     
38.             COMMIT;     
39.             SET status=0;     
40.             SET message="OK";     
41.         END IF;     
42.     ELSE     
43.         ROLLBACK;     
44.         SET status=-1;     
45.         SET message="Insufficient funds";     
46.     END IF;     
47. END$$