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應用中已經不適合了。