并發控制
當程式中可能出現并發的情況時，我們就需要通過一定的手段來保證在并發情況下資料的準确性，通過這種手段保證了目前使用者和其他使用者一起操作時，所得到的結果和他單獨操作時的結果是一樣的。這種手段就叫做并發控制。并發控制的目的是保證一個使用者的工作不會對另一個使用者的工作産生不合理的影響。
沒有做好并發控制，就可能導緻髒讀、幻讀和不可重複讀等問題。
我們常說的并發控制，一般都和資料庫管理系統（DBMS）有關。在DBMS中的并發控制的任務，是確定在多個事務同時存取資料庫中同一資料時，不破壞事務的隔離性和統一性以及資料庫的統一性。
實作并發控制的手段
實作并發控制的主要手段大緻可以分為樂觀并發控制和悲觀并發控制兩種。
在開始介紹之前要明确一下：無論是悲觀鎖還是樂觀鎖，都是人們定義出來的概念，可以認為是一種思想。其實不僅僅是關系型資料庫系統中有樂觀鎖和悲觀鎖的概念，像hibernate、tair、memcache等都有類似的概念。是以，不應該拿樂觀鎖、悲觀鎖和其他的資料庫鎖等進行對比。
悲觀鎖（Pessimistic Lock）
當我們要對一個資料庫中的一條資料進行修改的時候，為了避免同時被其他人修改，最好的辦法就是直接對該資料進行加鎖以防止并發。這種借助資料庫鎖機制，在修改資料之前先鎖定，再修改的方式被稱之為悲觀并發控制（又名“悲觀鎖”，Pessimistic Concurrency Control，縮寫“PCC”）。
百度百科
悲觀鎖，正如其名，具有強烈的獨占和排他特性。它指的是對資料被外界（包括本系統目前的其他事務，以及來自外部系統的事務處理）修改持保守态度。是以，在整個資料處理過程中，将資料處于鎖定狀态。悲觀鎖的實作，往往依靠資料庫提供的鎖機制（也隻有資料庫層提供的鎖機制才能真正保證資料通路的排他性，否則，即使在本系統中實作了加鎖機制，也無法保證外部系統不會修改資料）。
之是以叫做悲觀鎖，是因為這是一種對資料的修改抱有悲觀态度的并發控制方式。我們一般認為資料被并發修改的機率比較大，是以需要在修改之前先加鎖。
悲觀鎖主要是共享鎖或排他鎖
- 共享鎖又稱為讀鎖，簡稱S鎖。顧名思義，共享鎖就是多個事務對于同一資料可以共享一把鎖，都能通路到資料，但是隻能讀不能修改。
- 排他鎖又稱為寫鎖，簡稱X鎖。顧名思義，排他鎖就是不能與其他鎖并存，如果一個事務擷取了一個資料行的排他鎖，其他事務就不能再擷取該行的其他鎖，包括共享鎖和排他鎖，但是擷取排他鎖的事務是可以對資料行讀取和修改。
悲觀并發控制實際上是“先取鎖再通路”的保守政策，為資料處理的安全提供了保證。
但是在效率方面，處理加鎖的機制會讓資料庫産生額外的開銷，還有增加産生死鎖的機會。另外還會降低并行性，一個事務如果鎖定了某行資料，其他事務就必須等待該事務處理完才可以處理那行資料。
樂觀鎖（ Optimistic Locking ）
樂觀鎖是相對悲觀鎖而言的，樂觀鎖假設資料一般情況下不會造成沖突，是以在資料進行送出更新的時候，才會正式對資料的沖突與否進行檢測，如果發現沖突了，則傳回給使用者錯誤的資訊，讓使用者決定如何去做。
百度百科
樂觀鎖機制采取了更加寬松的加鎖機制。樂觀鎖是相對悲觀鎖而言，也是為了避免資料庫幻讀、業務處理時間過長等原因引起資料處理錯誤的一種機制，但樂觀鎖不會刻意使用資料庫本身的鎖機制，而是依據資料本身來保證資料的正确性。
相對于悲觀鎖，在對資料庫進行處理的時候，樂觀鎖并不會使用資料庫提供的鎖機制。一般的實作樂觀鎖的方式就是記錄資料版本。
樂觀并發控制相信事務之間的資料競争(data race)的機率是比較小的，是以盡可能直接做下去，直到送出的時候才去鎖定，是以不會産生任何鎖和死鎖。
實作方式
悲觀鎖實作方式
悲觀鎖的實作，往往依靠資料庫提供的鎖機制。在資料庫中，悲觀鎖的流程如下：
- 在對記錄進行修改前，先嘗試為該記錄加上排他鎖（exclusive locking）。
- 如果加鎖失敗，說明該記錄正在被修改，那麼目前查詢可能要等待或者抛出異常。具體響應方式由開發者根據實際需要決定。
- 如果成功加鎖，那麼就可以對記錄做修改，事務完成後就會解鎖了。
- 期間如果有其他對該記錄做修改或加排他鎖的操作，都會等待我們解鎖或直接抛出異常。
拿比較常用的MySql Innodb引擎舉例，來說明一下在SQL中如何使用悲觀鎖。
要使用悲觀鎖，我們必須關閉MySQL資料庫的自動送出屬性。因為MySQL預設使用autocommit模式，也就是說，當我們執行一個更新操作後，MySQL會立刻将結果進行送出。（sql語句：set autocommit=0）
以淘寶下單過程中扣減庫存的需求說明一下悲觀鎖的使用：
以上，在對id = 1的記錄修改前，先通過for update的方式進行加鎖，然後再進行修改。這就是比較典型的悲觀鎖政策。
如果以上修改庫存的代碼發生并發，同一時間隻有一個線程可以開啟事務并獲得id=1的鎖，其它的事務必須等本次事務送出之後才能執行。這樣我們可以保證目前的資料不會被其它事務修改。
上面我們提到，使用select…for update會把資料給鎖住，不過我們需要注意一些鎖的級别，MySQL InnoDB預設行級鎖。行級鎖都是基于索引的，如果一條SQL語句用不到索引是不會使用行級鎖的，會使用表級鎖把整張表鎖住，這點需要注意。
樂觀鎖實作方式
使用樂觀鎖就不需要借助資料庫的鎖機制了。
樂觀鎖的概念中其實已經闡述了它的具體實作細節。主要就是兩個步驟：沖突檢測和資料更新。其實作方式有一種比較典型的就是CAS(Compare and Swap)。
CAS是項樂觀鎖技術，當多個線程嘗試使用CAS同時更新同一個變量時，隻有其中一個線程能更新變量的值，而其它線程都失敗，失敗的線程并不會被挂起，而是被告知這次競争中失敗，并可以再次嘗試。
比如前面的扣減庫存問題，通過樂觀鎖可以實作如下：
以上，我們在更新之前，先查詢一下庫存表中目前庫存數（quantity），然後在做update的時候，以庫存數作為一個修改條件。當我們送出更新的時候，判斷資料庫表對應記錄的目前庫存數與第一次取出來的庫存數進行比對，如果資料庫表目前庫存數與第一次取出來的庫存數相等，則予以更新，否則認為是過期資料。
以上更新語句存在一個比較重要的問題，即傳說中的ABA問題。
比如說一個線程one從資料庫中取出庫存數3，這時候另一個線程two也從資料庫中取出庫存數3，并且two進行了一些操作變成了2，然後two又将庫存數變成3，這時候線程one進行CAS操作發現資料庫中仍然是3，然後one操作成功。盡管線程one的CAS操作成功，但是不代表這個過程就是沒有問題的。
有一個比較好的辦法可以解決ABA問題，那就是通過一個單獨的可以順序遞增的version字段。改為以下方式即可：
樂觀鎖每次在執行資料的修改操作時，都會帶上一個版本号，一旦版本号和資料的版本号一緻就可以執行修改操作并對版本号執行+1操作，否則就執行失敗。因為每次操作的版本号都會随之增加，是以不會出現ABA問題，因為版本号隻會增加不會減少。
除了version以外，還可以使用時間戳，因為時間戳天然具有順序遞增性。
以上SQL其實還是有一定的問題的，就是一旦遇上高并發的時候，就隻有一個線程可以修改成功，那麼就會存在大量的失敗。
對于像淘寶這樣的電商網站，高并發是常有的事，總讓使用者感覺到失敗顯然是不合理的。是以，還是要想辦法減少樂觀鎖的粒度的。
有一條比較好的建議，可以減小樂觀鎖力度，最大程度的提升吞吐率，提高并發能力！如下：
以上SQL語句中，如果使用者下單數為1，則通過quantity - 1 > 0的方式進行樂觀鎖控制。
以上update語句，在執行過程中，會在一次原子操作中自己查詢一遍quantity的值，并将其扣減掉1。
高并發環境下鎖粒度把控是一門重要的學問，選擇一個好的鎖，在保證資料安全的情況下，可以大大提升吞吐率，進而提升性能。
如何選擇
- 樂觀鎖并未真正加鎖，效率高。一旦鎖的粒度掌握不好，更新失敗的機率就會比較高，容易發生業務失敗。
- 悲觀鎖依賴資料庫鎖，效率低。更新失敗的機率比較低。