DRP學習中，我們對可能引起並發操作的情況使用了鎖，這次先理論上看看並發控制與鎖的一些內容吧。
並發控制
在多用戶環境中，在同一時間可能會有多個用戶更新相同的記錄，這會產生沖突。這就是並發性。典型的沖突有：
1、丟失更新（Lost updates）
一個事務的更新覆蓋了其它事務的更新結果，就是所謂的更新丟失。例如：用戶A把值從6改為2，用戶B把值從2改為6，則用戶A丟失了他的更新。
2、臟讀（Dirty reads）
當一個事務讀取其它完成一半事務的記錄時，就會發生臟讀取。例如：用戶A,B看到的值都是6，用戶B把值改為2，用戶A讀到的值仍為6。
3、不可重復讀（Non-repeatable reads）
當一個進程讀取了一筆數據后，另一個進程更新了同一筆數據，然后第一個進程再次讀取同一筆數據，卻得到了 與第一次讀取不同的結果。
在事務A更新記錄之后（update Customers set Name = 'B' where Name = 'A'），事務B讀取相同記錄（select Name form Customers where Name = 'A'），但事務B拿到的是事務A更新之后的數據（Customers.Name的值為'B'），在事務B讀取記錄之后，事務A進行了事務回滾（Customers.Name的值為'A'），導致事務B的數據是不真實的。
4、幻讀（Phantoms）
幻讀與臟讀的相似之處在於：兩者都是兩次讀取的結果不一致。
不同之處在於：幻讀是兩次讀取的記錄數量不一致，而臟讀是兩次讀取的記錄的數據不一致。
事務A讀取記錄之后（select * from Customers where Name like 'A%'），事務B又插入了符合事務A讀取條件的新記錄（insert into Customers(Name) values('AAA')），那么當事務A再用相同條件讀取記錄時，得到的集合卻與上一次讀取不同（多了記錄）。
解決方案：線程同步和加鎖
通常我們解決並發問題使用同步和加鎖兩種方式。
同步中，我們通過Java中的synchronized關鍵字來實現，但這樣通常會帶來性能和效率上的一些問題。
這次，我們主要講解鎖。鎖機制中，我們可以根據不同情況使用悲觀鎖或樂觀鎖。
悲觀鎖(Pessimistic Lock), 顧名思義，就是很悲觀，每次去拿數據的時候都認為別人會修改，所以每次在拿數據的時候都會上鎖，這樣別人想拿這個數據就會block直到它拿到鎖。傳統的關系型數據庫里邊就用到了很多這種鎖機制，比如行鎖，表鎖等，讀鎖，寫鎖等，都是在做操作之前先上鎖。
對於悲觀鎖，我們可以提供一個值作為鎖的參數。比如一個鍵默認會被鎖定15秒。15秒過后，如果你還沒有手動的釋放鎖，那么使程序自動的為你釋放。
悲觀鎖的實現，往往依靠數據庫提供的鎖機制（也只有數據庫層提供的鎖機制才能真正保證數據訪問的排他性，否則，即使在本系統中實現了加鎖機制，也無法保證外部系統不會修改數據）。但隨之而來的就是數據庫性能的大量開銷，特別是對長事務而言，這樣的開銷往往無法承受。
與之對應的--樂觀鎖：
樂觀鎖(Optimistic Lock), 就是很樂觀，每次去拿數據的時候都認為別人不會修改，所以不會上鎖，但是在更新的時候會判斷一下在此期間別人有沒有去更新這個數據。
而樂觀鎖機制在一定程度上解決了數據庫性能開銷這個問題。它大多是基於數據版本（ Version ）記錄機制實現。
可以使用版本號、時間戳等機制。樂觀鎖適用於多讀的應用類型，這樣可以提高吞吐量，像數據庫如果提供類似於write_condition機制的其實都是提供的樂觀鎖。
比較
1、兩種鎖各有優缺點，不可認為一種好於另一種，像樂觀鎖適用於寫比較少的情況下，即沖突真的很少發生的時候，這樣可以省去了鎖的開銷，加大了系統的整個吞吐量。但如果經常產生沖突，上層應用會不斷的進行retry，這樣反倒是降低了性能，所以這種情況下用悲觀鎖就比較合適。
2、悲觀鎖和樂觀鎖最大的區別是是否一直鎖定資源，悲觀鎖在事物的全流程鎖定數據，樂觀鎖不鎖定數據（用讀寫鎖是阻塞事物，而用樂觀鎖則會導致回滾，這個是一種事物沖突后的不同鎖的表象）。
3、悲觀鎖和樂觀鎖都是為了解決丟失更新問題或者是臟讀。悲觀鎖和樂觀鎖的重點就是是否在讀取記錄的時候直接上鎖。悲觀鎖的缺點很明顯，需要一個持續的數據庫連接，這在web應用中已經不適合了。