樂觀并發控制(樂觀鎖)和悲觀并發控制（悲觀鎖）是并發控制主要采用的技術手段

悲觀并發控制?（悲觀鎖）

它可以阻止一個事務以影響其他用戶的方式來修改數據。如果一個事務執行的操作讀某行數據應用了鎖，那只有當這個事務把鎖釋放，其他事務才能夠執行與該鎖沖突的操作

在數據庫中，悲觀鎖的流程

在對任意記錄進行修改前，先嘗試為該記錄加上排他鎖（exclusive locking）。

如果加鎖失敗，說明該記錄正在被修改，那么當前查詢可能要等待或者拋出異常。 具體響應方式由開發者根據實際需要決定。

如果成功加鎖，那么就可以對記錄做修改，事務完成后就會解鎖了。

其間如果有其他對該記錄做修改或加排他鎖的操作，都會等待我們解鎖或直接拋出異常

MySQL InnoDB中使用悲觀鎖

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

使用select…for update 這樣的方式，開啟排他鎖的方式實現了悲觀鎖

注意：

MySQL InnoDB默認行級鎖。行級鎖都是基于索引的，如果一條SQL語句用不到索引是不會使用行級鎖的，會使用表級鎖把整張表鎖住。

悲觀鎖優點與不足

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

但是在效率方面，處理加鎖的機制會讓數據庫產生額外的開銷，還有增加產生死鎖的機會；

另外，在只讀型事務處理中由于不會產生沖突，也沒必要使用鎖，這樣做只能增加系統負載；

還有會降低了并行性，一個事務如果鎖定了某行數據，其他事務就必須等待該事務處理完才可以處理那行數

樂觀并發控制 （樂觀鎖）

它假設多用戶并發的事務在處理時不會彼此互相影響，各事務能夠在不產生鎖的情況下處理各自影響的那部分數據。在提交數據更新之前，每個事務會先檢查在該事務讀取數據后，有沒有其他事務又修改了該數據。如果其他事務有更新的話，正在提交的事務會進行回滾

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

數據版本?為數據增加的一個版本標識。當讀取數據時，將版本標識的值一同讀出，數據每更新一次，同時對版本標識進行更新。當我們提交更新的時候，判斷數據庫表對應記錄的當前版本信息與第一次取出來的版本標識進行比對，如果數據庫表當前版本號與第一次取出來的版本標識值相等，則予以更新，否則認為是過期數據， 實現數據版本有兩種方式，第一種是使用版本號，第二種是使用時間戳

樂觀并發控制的事務包括以下階段：?

1. 讀取：事務將數據讀入緩存，這時系統會給事務分派一個時間戳。?

2. 校驗：事務執行完畢后，進行提交。這時同步校驗所有事務，如果事務所讀取的數據在讀取之后又被其他事務修改，則產生沖突，事務被中斷回滾。?

3. 寫入：通過校驗階段后，將更新的數據寫入數據庫

優點與不足

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

但如果直接簡單這么做，還是有可能會遇到不可預期的結果，例如兩個事務都讀取了數據庫的某一行，經過修改以后寫回數據庫，這時就遇到了問題

應用場景

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

相反，如果經常發生沖突，上層應用會不斷進行 retry，這樣反而降低了性能，這種情況下用悲觀鎖比較合適。