一、前言
校招時無論是筆試還是面試，我都有遇到樂觀鎖與悲觀鎖的題目，當時心急只是背了一下他們兩的概念，並沒有深究，現在工作之余會開始回首過去應聘被難到的知識點進行充電，單純地為了增長知識而研究這種感覺出奇的還不錯哦。
那么回到主題，樂觀鎖與悲觀鎖，我會結合所看到的講解的以及應用場景，摘選出好的應用例子幫助大家節省理解的時間，並給出自己的思考。
二、正文
悲觀鎖：正如其名，它指的是對數據被外界（包括本系統當前的其他事務，以及來自外部系統的事務處理）的修改持保守態度，因此，在整個數據處理過程中，將數據處於（人為的）鎖定狀態。在前面的事務結束操作之前，后來的事務只能進行等待。
P.S. 我們可能很熟悉的sycchronized關鍵字，就是本系統上的悲觀鎖的一種實現，但是我看到有的博主提出 “只有數據庫層提供的鎖機制才能真正保證數據訪問的排他性，否則，即使在本系統中實現了加鎖機制，也無法保證外部系統不會修改數據” ，有待進一步考證。
那么什么是數據庫底層提供的鎖機制呢？以常用的mysql InnoDB存儲引擎為例（以下部分引用博文鏈接https://blog.csdn.net/zxx901221/article/details/83239771）：
加入商品表items表中有一個字段status，status=1表示該商品未被下單，status=2表示該商品已經被下單，那么我們對每個商品下單前必須確保此商品的status=1。假設有一件商品，其id為10000；如果不使用鎖，那么操作方法如下：
//查出商品狀態
select status from items where id=10000;
//根據商品信息生成訂單
insert into orders(id,item_id) values(null,10000);
//修改商品狀態為2
update Items set status=2 where id=10000;
上述場景在高並發環境下可能出現問題：
前面已經提到只有商品的status=1是才能對它進行下單操作，上面第一步操作中，查詢出來的商品status為1。但是當我們執行第三步update操作的時候，有可能出現其他人先一步對商品下單把Item的status修改為2了，但是我們並不知道數據已經被修改了，這樣就可
能造成同一個商品被下單2次，使得數據不一致。所以說這種方式是不安全的。
使用悲觀鎖來實現：在上面的場景中，商品信息從查詢出來到修改，中間有一個處理訂單的過程，使用悲觀鎖的原理就是，當我們在查詢出items信息后就把當前的數據鎖定，直到我們修改完畢后再解鎖。那么在這個過程中，因為items被鎖定了，就不會出現有第三
者來對其進行修改了。
注：要使用悲觀鎖，我們必須關閉mysql數據庫的自動提交屬性，因為MySQL默認使用autocommit模式，也就是說，當你執行一個更新操作后，MySQL會立刻將結果進行提交。我們可以使用命令設置MySQL為非autocommit模式：
set autocommit=0;
設置完autocommit后，我們就可以執行我們的正常業務了。具體如下：
//開始事務
begin;/begin work;/start transaction; (三者選一就可以)
//查詢出商品信息
select status from items where id=10000 for update;
//根據商品信息生成訂單
insert into orders (id,item_id) values (null,10000);
//修改商品status為2
update items set status=2 where id=10000;
//提交事務
commit;/commit work;
上面的begin/commit為事務的開始和結束，因為在前一步我們關閉了mysql的autocommit，所以需要手動控制事務的提交。並且與普通查詢不一樣的是，我們使用了select…for update的方式，這樣就通過數據庫實現了悲觀鎖。
另外需要注意的是，在事務中，只有”SELECT ... FOR UPDATE “同一筆數據時會等待其它事務結束后才執行，一般SELECT ... 則不受此影響。拿上面的實例來說，當我執行select status from items where id=10000 for update;后。我在另外的事務中如果再次執行
select status from items where id=10000 for update;則第二個事務會一直等待第一個事務的提交，此時第二個查詢處於阻塞的狀態，但是如果我是在第二個事務中執行select status from items where id=10000;則能正常查詢出數據，不會受第一個事務的影響。
原文中還提到了LOCK IN SHARE MODE 和 鎖級別，我不是很懂就做了刪減，有興趣的朋友可以看原文。
樂觀鎖：相對悲觀鎖而言，樂觀鎖假設認為數據一般情況下不會造成沖突，所以在數據進行提交更新的時候，才會正式對數據的沖突與否進行檢測，如果發現沖突了，則讓返回用戶錯誤的信息，讓用戶決定如何去做。
實現樂觀鎖一般有以下2種方式：
1.使用數據版本（Version）記錄機制實現，這是樂觀鎖最常用的一種實現方式。何謂數據版本？即為數據增加一個版本標識，一般是通過為數據庫表增加一個數字類型的 “version” 字段來實現。當讀取數據時，將version字段的值一同讀出，數據每更新一次，對此
version值+1。當我們提交更新的時候，判斷數據庫表對應記錄的當前版本信息與第一次取出來的version值進行比對，如果數據庫表當前版本號與第一次取出來的version值相等，則予以更新，否則認為是過期數據。
2.樂觀鎖定的第二種實現方式和第一種差不多，同樣是在需要樂觀鎖控制的table中增加一個字段，名稱無所謂，字段類型使用時間戳（timestamp）, 和上面的version類似，也是在更新提交的時候檢查當前數據庫中數據的時間戳和自己更新前取到的時間戳進行對比，
如果一致則OK，否則就是版本沖突。
還是拿之前的例子商品表items表中有一個字段status，status=1表示該商品未被下單，status=2表示該商品已經被下單，那么我們對每個商品下單前必須確保此商品的status=1。假設有一件商品，其id為10000；
下單操作包括3步驟：
//查詢出商品信息
select (status,version) from items where id=#{id}
//根據商品信息生成訂單
---------------------------------
//修改商品status為2
update items set status=2,version=version+1 where id=#{id} and version=#{version};
比如系統中有一個值”1”, 現在A和B客戶端同時都取到了這個值。之后A和B客戶端都想改動這個值，假設A要改成12，B要改成13，如果不加控制的話，無論A和B誰先更新成功，它的更新都會被后到的更新覆蓋。XXX引入的樂觀鎖機制避免了這樣的問題。剛剛的例子中，假設A和B同時取到數據，當時版本號是10，A先更新，更新成功后，值為12，版本為11。當B更新的時候，由於其基於的版本號是10，此時服務器會拒絕更新，返回version error，從而避免A的更新被覆蓋。
三、兩鎖之思考
1、悲觀鎖問題挺多的，高並發情況下響應速度較慢，而且對查詢語句有限制，寫代碼時要更加小心，但是它的成功率高，重試次數少。所以適用於響應速度要求低，重試代價高的場景。
2、除了1之外的情況，我覺得選擇樂觀鎖還是很方便的。