最近因為在工作中需要，學習了樂觀鎖與悲觀鎖的相關知識，這裡我通過這篇文章，把我自己對這兩個“鎖家”兄弟理解記錄下來;
       - 悲觀鎖：正如其名，它指的是對資料被外界（包括本系統當前的其他事務，以及來自外部系統的事務處理）的修改持保守態度，因此，在整個資料處理過程中，將資料處於鎖定狀態。悲觀鎖的實現，往往依靠資料庫提供的鎖機制（也只有資料庫層提供的鎖機制才能真正保證資料訪問的排他性，否則，即使在本系統中實現了加鎖機制，也無法保證外部系統不會修改資料）。
       以常用的mysql InnoDB儲存引擎為例：加入商品表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 status from items where id=10000 for update;與普通查詢不一樣的是，我們使用了select…for update的方式，這樣就通過資料庫實現了悲觀鎖。此時在items表中，id為10000的 那條資料就被我們鎖定了，其它的事務必須等本次事務提交之後才能執行。這樣我們可以保證當前的資料不會被其它事務修改。
       注：需要注意的是，在事務中，只有SELECT ... FOR UPDATE 或LOCK IN SHARE MODE 同一筆資料時會等待其它事務結束後才執行，一般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;則能正常查詢出資料，不會受第一個事務的影響。
       上面我們提到，使用select…for update會把資料給鎖住，不過我們需要注意一些鎖的級別，MySQL InnoDB預設Row-Level Lock，所以只有明確地指定主鍵，MySQL 才會執行Row lock (只鎖住被選取的資料) ，否則MySQL 將會執行Table Lock (將整個資料表單給鎖住)。除了主鍵外，使用索引也會影響資料庫的鎖定級別。
       悲觀鎖並不是適用於任何場景，它也有它存在的一些不足，因為悲觀鎖大多數情況下依靠資料庫的鎖機制實現，以保證操作最大程度的獨佔性。如果加鎖的時間過長，其他使用者長時間無法訪問，影響了程式的併發訪問性，同時這樣對資料庫效能開銷影響也很大，特別是對長事務而言，這樣的開銷往往無法承受。所以與悲觀鎖相對的，我們有了樂觀鎖，樂觀鎖的概念如下：
       - 樂觀鎖（ Optimistic Locking ） 相對悲觀鎖而言，樂觀鎖假設認為資料一般情況下不會造成衝突，所以在資料進行提交更新的時候，才會正式對資料的衝突與否進行檢測，如果發現衝突了，則讓返回使用者錯誤的資訊，讓使用者決定如何去做。那麼我們如何實現樂觀鎖呢，一般來說有以下2種方式：
       1.使用資料版本（Version）記錄機制實現，這是樂觀鎖最常用的一種實現方式。何謂資料版本？即為資料增加一個版本標識，一般是通過為資料庫表增加一個數字型別的 “version” 欄位來實現。當讀取資料時，將version欄位的值一同讀出，資料每更新一次，對此version值+1。當我們提交更新的時候，判斷資料庫表對應記錄的當前版本資訊與第一次取出來的version值進行比對，如果資料庫表當前版本號與第一次取出來的version值相等，則予以更新，否則認為是過期資料。用下面的一張圖來說明：

       如上圖所示，如果更新操作順序執行，則資料的版本（version）依次遞增，不會產生衝突。但是如果發生有不同的業務操作對同一版本的資料進行修改，那麼，先提交的操作（圖中B）會把資料version更新為2，當A在B之後提交更新時發現數據的version已經被修改了，那麼A的更新操作會失敗。
       2.樂觀鎖定的第二種實現方式和第一種差不多，同樣是在需要樂觀鎖控制的table中增加一個欄位，名稱無所謂，欄位型別使用時間戳（timestamp）, 和上面的version類似，也是在更新提交的時候檢查當前資料庫中資料的時間戳和自己更新前取到的時間戳進行對比，如果一致則OK，否則就是版本衝突。
       以mysql InnoDB儲存引擎為例，還是拿之前的例子商品表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};
       為了使用樂觀鎖，我們需要首先修改items表，增加一個version欄位，資料預設version可設為1；
       其實我們周圍的很多產品都有樂觀鎖的使用，比如我們經常使用的分散式儲存引擎XXX，XXX中儲存的每個資料都有版本號，版本號在每次更新後都會遞增，相應的，在XXX put介面中也有此version引數，這個引數是為了解決併發更新同一個資料而設定的，這其實就是樂觀鎖；
       很多情況下，更新資料是先get，修改get回來的資料，然後put回系統。如果有多個客戶端get到同一份資料，都對其修改並儲存，那麼先儲存的修改就會被後到達的修改覆蓋，從而導致資料一致性問題,在大部分情況下應用能夠接受，但在少量特殊情況下，這個是我們不希望發生的。
       比如系統中有一個值”1”, 現在A和B客戶端同時都取到了這個值。之後A和B客戶端都想改動這個值，假設A要改成12，B要改成13，如果不加控制的話，無論A和B誰先更新成功，它的更新都會被後到的更新覆蓋。XXX引入的樂觀鎖機制避免了這樣的問題。剛剛的例子中，假設A和B同時取到資料，當時版本號是10，A先更新，更新成功後，值為12，版本為11。當B更新的時候，由於其基於的版本號是10，此時伺服器會拒絕更新，返回version error，從而避免A的更新被覆蓋。B可以選擇get新版本的value，然後在其基礎上修改，也可以選擇強行更新。