悲觀鎖和樂觀鎖

鎖的由來

1. 開發多用戶、數據庫驅動時，一個比較大的難點是：一方面要最大程度的利用數據庫的併發訪問，另一方面還要確保每個用戶能以一致的方式讀取和修改數據。
2. 鎖機制主要是管理對於共享資源的併發訪問。

鎖存在的問題

經過鎖定機制能夠實現事物的隔離性，使事物能夠併發的工做。鎖提升了併發，可是帶來了三種問題：

1. 髒讀
   髒數據是事務對緩衝池中行記錄的修改，並且沒有被提交。一個事務讀取到另一個事務中未提交的數據，違反了數據庫的隔離性。
   髒讀發生的前提是數據庫事務的隔離級別爲read uncommit.

2. 不可重複讀
   一個事務屢次讀取同一數據集合，在這個事務沒有結束時，另一個事務也訪問該數據集合， 並作了一下dml操做，所以第一個事務中的兩次讀數據之間，因爲第二個事務的修改，第一個事務兩次讀取到的數據是不同的。

3. 丟失更新
   丟失更新是另一個鎖致使的問題，是一個事務的更新操做會被另一個事務的更新操做覆蓋，從而致使數據不一致。要避免丟失更新的發生，事務在這種狀況下的操做編程串行化，而不是並行操做。

併發控制

1. 悲觀鎖
   悲觀鎖：假定會發生併發衝突，屏蔽一切可能違反數據完整性的操做悲觀鎖假定其餘用戶企圖訪問或者改變你正在訪問、更改的對象的機率是很高的，所以在悲觀鎖的環境中，在你開始改變此對象以前就將該對象鎖住，而且直到你提交了所做的更改以後才釋放鎖。悲觀的缺陷是不管是頁鎖仍是行鎖，加鎖的時間可能會很長，這樣可能會長時間的限制其餘用戶的訪問，也就是說悲觀鎖的併發訪問性很差。

2. 樂觀鎖
   假設不會發生併發衝突，只在提交操做時檢查是否違反數據完整性。 樂觀鎖不能解決髒讀的問題。 樂觀鎖則認爲其餘用戶企圖改變你正在更改的對象的機率是很小的，所以樂觀鎖直到你準備提交所做的更改時纔將對象鎖住，當你讀取以及改變該對象時並不加鎖。可見樂觀鎖加鎖的時間要比悲觀鎖短，樂觀鎖能夠用較大的鎖粒度得到較好的併發訪問性能。可是若是第二個用戶剛好在第一個用戶提交更改以前讀取了該對象，那麼當他完成了本身的更改進行提交時，數據庫就會發現該對象已經變化了，這樣，第二個用戶不得不從新讀取該對象並做出更改。這說明在樂觀鎖環境中，會增長併發用戶讀取對象的次數。

參考文檔

1. 樂觀鎖與悲觀鎖的區別 http://www.cnblogs.com/Bob-FD/p/3352216.html