前言：
- 在並發訪問情況下，可能會出現臟讀、不可重復讀和幻讀等讀現象，為了應對這些問題，主流數據庫都提供了鎖機制，並引入了事務隔離級別的概念。數據庫管理系統（DBMS）中的並發控制的任務是確保在多個事務同時存取數據庫中同一數據時不破壞事務的隔離性和統一性以及數據庫的統一性。
- 樂觀並發控制(樂觀鎖)和悲觀並發控制（悲觀鎖）是並發控制主要采用的技術手段。無論是悲觀鎖還是樂觀鎖，都是人們定義出來的概念，可以認為是一種思想。其實不僅僅是關系型數據庫系統中有樂觀鎖和悲觀鎖的概念，像memcache、hibernate、tair等都有類似的概念。
- 本文中也將深入分析一下樂觀鎖的實現機制，介紹什么是CAS、CAS的應用以及CAS存在的問題等。
並發控制
在計算機科學，特別是程序設計、操作系統、多處理機和數據庫等領域，並發控制（
Concurrency control）是確保及時糾正由並發操作導致的錯誤的一種機制。
數據庫管理系統（DBMS）中的並發控制的任務是確保在多個事務同時存取數據庫中同一數據時不破壞事務的隔離性和統一性以及數據庫的統一性。下面舉例說明並發操作帶來的數據不一致性問題：
現有兩處火車票售票點，同時讀取某一趟列車車票數據庫中車票余額為 X。兩處售票點同時賣出一張車票，同時修改余額為 X -1寫回數據庫，這樣就造成了實際賣出兩張火車票而數據庫中的記錄卻只少了一張。 產生這種情況的原因是因為兩個事務讀入同一數據並同時修改，其中一個事務提交的結果破壞了另一個事務提交的結果，導致其數據的修改被丟失，破壞了事務的隔離性。並發控制要解決的就是這類問題。
封鎖、時間戳、樂觀並發控制(樂觀鎖)和悲觀並發控制（悲觀鎖）是並發控制主要采用的技術手段。
一、數據庫的鎖
鎖
當並發事務同時訪問一個資源時，有可能導致數據不一致，因此需要一種機制來將數據訪問順序化，以保證數據庫數據的一致性。鎖就是其中的一種機制。
在計算機科學中，鎖是在執行多線程時用於強行限制資源訪問的同步機制，即用於在並發控制中保證對互斥要求的滿足。
鎖的分類(oracle)
一、按操作划分，可分為
DML鎖、DDL鎖二、按鎖的粒度划分，可分為
表級鎖、行級鎖、頁級鎖（mysql）四、按加鎖方式划分，可分為
自動鎖、顯示鎖
DML鎖（data locks，數據鎖），用於保護數據的完整性，其中包括行級鎖(Row Locks (TX鎖))、表級鎖(table lock(TM鎖))。
DDL鎖（dictionary locks，數據字典鎖），用於保護數據庫對象的結構，如表、索引等的結構定義。其中包排他DDL鎖（Exclusive DDL lock）、共享DDL鎖（Share DDL lock）、可中斷解析鎖（Breakable parse locks）
1.1 鎖機制
常用的鎖機制有兩種：
1、悲觀鎖：假定會發生並發沖突，屏蔽一切可能違反數據完整性的操作。悲觀鎖的實現，往往依靠底層提供的鎖機制；悲觀鎖會導致其它所有需要鎖的線程掛起，等待持有鎖的線程釋放鎖。
2、樂觀鎖：假設不會發生並發沖突，每次不加鎖而是假設沒有沖突而去完成某項操作，只在提交操作時檢查是否違反數據完整性。如果因為沖突失敗就重試，直到成功為止。樂觀鎖大多是基於數據版本記錄機制實現。為數據增加一個版本標識，比如在基於數據庫表的版本解決方案中，一般是通過為數據庫表增加一個 “version” 字段來實現。讀取出數據時，將此版本號一同讀出，之后更新時，對此版本號加一。此時，將提交數據的版本數據與數據庫表對應記錄的當前版本信息進行比對，如果提交的數據版本號大於數據庫表當前版本號，則予以更新，否則認為是過期數據。
樂觀鎖的缺點是不能解決部分臟讀的問題，例如ABA問題（下面會講到）。
在實際生產環境里邊,如果並發量不大且不允許臟讀，可以使用悲觀鎖解決並發問題；但如果系統的並發非常大的話,悲觀鎖定會帶來非常大的性能問題,所以我們就要選擇樂觀鎖定的方法。
二、悲觀鎖與樂觀鎖詳解
2.1 悲觀鎖
在關系數據庫管理系統里，悲觀並發控制（又名“悲觀鎖”，Pessimistic Concurrency Control，縮寫“PCC”）是一種並發控制的方法。它可以阻止一個事務以影響其他用戶的方式來修改數據。如果一個事務執行的操作都某行數據應用了鎖，那只有當這個事務把鎖釋放，其他事務才能夠執行與該鎖沖突的操作。
悲觀並發控制主要用於數據爭用激烈的環境，以及發生並發沖突時使用鎖保護數據的成本要低於回滾事務的成本的環境中。
悲觀鎖，正如其名，它指的是對數據被外界（包括本系統當前的其他事務，以及來自外部系統的事務處理）修改持保守態度(悲觀)，因此，在整個數據處理過程中，將數據處於鎖定狀態。 悲觀鎖的實現，往往依靠數據庫提供的鎖機制 （也只有數據庫層提供的鎖機制才能真正保證數據訪問的排他性，否則，即使在本系統中實現了加鎖機制，也無法保證外部系統不會修改數據）
在數據庫中，悲觀鎖的流程如下：
在對任意記錄進行修改前，先嘗試為該記錄加上排他鎖（exclusive locking）。
如果加鎖失敗，說明該記錄正在被修改，那么當前查詢可能要等待或者拋出異常。 具體響應方式由開發者根據實際需要決定。
如果成功加鎖，那么就可以對記錄做修改，事務完成后就會解鎖了。
其間如果有其他對該記錄做修改或加排他鎖的操作，都會等待我們解鎖或直接拋出異常。
MySQL InnoDB中使用悲觀鎖：
要使用悲觀鎖，我們必須關閉mysql數據庫的自動提交屬性，因為MySQL默認使用autocommit模式，也就是說，當你執行一個更新操作后，MySQL會立刻將結果進行提交。
set autocommit=0;
//0.開始事務 begin;/begin work;/start transaction; (三者選一就可以) //1.查詢出商品信息 select status from t_goods where id=1 for update; //2.根據商品信息生成訂單 insert into t_orders (id,goods_id) values (null,1); //3.修改商品status為2 update t_goods set status=2; //4.提交事務 commit;/commit work;
上面的查詢語句中，我們使用了select…for update的方式，這樣就通過開啟排他鎖的方式實現了悲觀鎖。此時在t_goods表中，id為1的 那條數據就被我們鎖定了，其它的事務必須等本次事務提交之后才能執行。這樣我們可以保證當前的數據不會被其它事務修改。
上面我們提到，使用
select…for update會把數據給鎖住，不過我們需要注意一些鎖的級別，MySQL InnoDB默認行級鎖。行級鎖都是基於索引的，如果一條SQL語句用不到索引是不會使用行級鎖的，會使用表級鎖把整張表鎖住，這點需要注意。
優點與不足
悲觀並發控制實際上是“先取鎖再訪問”的保守策略，為數據處理的安全提供了保證。但是在效率方面，處理加鎖的機制會讓數據庫產生額外的開銷，還有增加產生死鎖的機會；另外，在只讀型事務處理中由於不會產生沖突，也沒必要使用鎖，這樣做只能增加系統負載；還有會降低了並行性，一個事務如果鎖定了某行數據，其他事務就必須等待該事務處理完才可以處理那行數
2.2 樂觀鎖
在關系數據庫管理系統里，樂觀並發控制（又名“樂觀鎖”，Optimistic Concurrency Control，縮寫“OCC”）是一種並發控制的方法。它假設多用戶並發的事務在處理時不會彼此互相影響，各事務能夠在不產生鎖的情況下處理各自影響的那部分數據。在提交數據更新之前，每個事務會先檢查在該事務讀取數據后，有沒有其他事務又修改了該數據。如果其他事務有更新的話，正在提交的事務會進行回滾。樂觀事務控制最早是由孔祥重（H.T.Kung）教授提出。
樂觀鎖（ Optimistic Locking ） 相對悲觀鎖而言，樂觀鎖假設認為數據一般情況下不會造成沖突，所以在數據進行提交更新的時候，才會正式對數據的沖突與否進行檢測，如果發現沖突了，則讓返回用戶錯誤的信息，讓用戶決定如何去做。
相對於悲觀鎖，在對數據庫進行處理的時候，樂觀鎖並不會使用數據庫提供的鎖機制。一般的實現樂觀鎖的方式就是記錄數據版本。
數據版本,為數據增加的一個版本標識。當讀取數據時，將版本標識的值一同讀出，數據每更新一次，同時對版本標識進行更新。當我們提交更新的時候，判斷數據庫表對應記錄的當前版本信息與第一次取出來的版本標識進行比對，如果數據庫表當前版本號與第一次取出來的版本標識值相等，則予以更新，否則認為是過期數據。
實現數據版本有兩種方式，第一種是使用版本號，第二種是使用時間戳。
使用版本號實現樂觀鎖
使用版本號時，可以在數據初始化時指定一個版本號，每次對數據的更新操作都對版本號執行+1操作。並判斷當前版本號是不是該數據的最新的版本號。
1.查詢出商品信息 select (status,status,version) from t_goods where id=#{id} 2.根據商品信息生成訂單 3.修改商品status為2 update t_goods set status=2,version=version+1 where id=#{id} and version=#{version};
優點與不足
樂觀並發控制相信事務之間的數據競爭(data race)的概率是比較小的，因此盡可能直接做下去，直到提交的時候才去鎖定，所以不會產生任何鎖和死鎖。但如果直接簡單這么做，還是有可能會遇到不可預期的結果，例如兩個事務都讀取了數據庫的某一行，經過修改以后寫回數據庫，這時就遇到了問題。
三、CAS詳解
在說CAS之前，我們不得不提一下Java的線程安全問題。
線程安全：
眾所周知，Java是多線程的。但是，Java對多線程的支持其實是一把雙刃劍。一旦涉及到多個線程操作共享資源的情況時，處理不好就可能產生線程安全問題。線程安全性可能是非常復雜的，在沒有充足的同步的情況下，多個線程中的操作執行順序是不可預測的。
Java里面進行多線程通信的主要方式就是共享內存的方式，共享內存主要的關注點有兩個：可見性和有序性。加上復合操作的原子性，我們可以認為Java的線程安全性問題主要關注點有3個：可見性、有序性和原子性。
Java內存模型（JMM）解決了可見性和有序性的問題，而鎖解決了原子性的問題。這里不再詳細介紹JMM及鎖的其他相關知識。但是我們要討論一個問題，那就是鎖到底是不是有利無弊的？
3.1 鎖存在的問題
Java在JDK1.5之前都是靠synchronized關鍵字保證同步的，這種通過使用一致的鎖定協議來協調對共享狀態的訪問，可以確保無論哪個線程持有共享變量的鎖，都采用獨占的方式來訪問這些變量。獨占鎖其實就是一種悲觀鎖，所以可以說synchronized是悲觀鎖。
悲觀鎖機制存在以下問題：
1) 在多線程競爭下，加鎖、釋放鎖會導致比較多的上下文切換和調度延時，引起性能問題。
2) 一個線程持有鎖會導致其它所有需要此鎖的線程掛起。
3) 如果一個優先級高的線程等待一個優先級低的線程釋放鎖會導致優先級倒置，引起性能風險。
而另一個更加有效的鎖就是樂觀鎖。所謂樂觀鎖就是，每次不加鎖而是假設沒有沖突而去完成某項操作，如果因為沖突失敗就重試，直到成功為止。
與鎖相比，volatile變量是一個更輕量級的同步機制，因為在使用這些變量時不會發生上下文切換和線程調度等操作，但是volatile不能解決原子性問題，因此當一個變量依賴舊值時就不能使用volatile變量。因此對於同步最終還是要回到鎖機制上來。
樂觀鎖
樂觀鎖（ Optimistic Locking）其實是一種思想。相對悲觀鎖而言，樂觀鎖假設認為數據一般情況下不會造成沖突，所以在數據進行提交更新的時候，才會正式對數據的沖突與否進行檢測，如果發現沖突了，則讓返回用戶錯誤的信息，讓用戶決定如何去做。
上面提到的樂觀鎖的概念中其實已經闡述了他的具體實現細節：
主要就是兩個步驟：沖突檢測和數據更新。
其實現方式有一種比較典型的就是Compare and Swap(CAS)。
3.2 CAS
CAS是項樂觀鎖技術，當多個線程嘗試使用CAS同時更新同一個變量時，只有其中一個線程能更新變量的值，而其它線程都失敗，失敗的線程並不會被掛起，而是被告知這次競爭中失敗，並可以再次嘗試。
CAS 操作包含三個操作數 —— 內存位置（V）、預期原值（A）和新值(B)。如果內存位置的值與預期原值相匹配，那么處理器會自動將該位置值更新為新值。否則，處理器不做任何操作。無論哪種情況，它都會在 CAS 指令之前返回該位置的值。（在 CAS 的一些特殊情況下將僅返回 CAS 是否成功，而不提取當前值。）CAS 有效地說明了“我認為位置 V 應該包含值 A；如果包含該值，則將 B 放到這個位置；否則，不要更改該位置，只告訴我這個位置現在的值即可。”這其實和樂觀鎖的沖突檢查+數據更新的原理是一樣的。
這里再強調一下，樂觀鎖是一種思想。CAS是這種思想的一種實現方式。
3.3 Java對CAS的支持
JDK 5之前Java語言是靠synchronized關鍵字保證同步的，這是一種獨占鎖，也是是悲觀鎖。j在JDK1.5 中新增java.util.concurrent(J.U.C)就是建立在CAS之上的。相對於對於synchronized這種阻塞算法，CAS是非阻塞算法的一種常見實現。所以J.U.C在性能上有了很大的提升。
現代的CPU提供了特殊的指令，允許算法執行讀-修改-寫操作，而無需害怕其他線程同時修改變量，因為如果其他線程修改變量，那么CAS會檢測它（並失敗），算法可以對該操作重新計算。而 compareAndSet() 就用這些代替了鎖定。
我們以java.util.concurrent中的AtomicInteger為例，看一下在沒有鎖的情況下是如何保證線程安全的。主要理解getAndIncrement方法，該方法的作用相當於 ++i 操作。
public class AtomicInteger extends Number implements java.io.Serializable { private volatile int value; public final int get() { return value; } public final int getAndIncrement() { for (;;) { int current = get(); int next = current + 1; if (compareAndSet(current, next)) return current; } } public final boolean compareAndSet(int expect, int update) { return unsafe.compareAndSwapInt(this, valueOffset, expect, update); }
字段value需要借助volatile原語，保證線程間的數據是可見的（共享的）。這樣在獲取變量的值的時候才能直接讀取。然后來看看++i是怎么做到的。getAndIncrement采用了CAS操作，每次從內存中讀取數據然后將此數據和+1后的結果進行CAS操作，如果成功就返回結果，否則重試直到成功為止。而compareAndSet利用JNI來完成CPU指令的操作。
public final boolean compareAndSet(int expect, int update) {
return unsafe.compareAndSwapInt(this, valueOffset, expect, update);
}
整體的過程就是這樣子的，利用CPU的CAS指令，同時借助JNI來完成Java的非阻塞算法。其它原子操作都是利用類似的特性完成的。
而整個J.U.C都是建立在CAS之上的，因此對於synchronized阻塞算法，J.U.C在性能上有了很大的提升。
3.4 CAS會導致“ABA問題”：
ABA問題：
aba實際上是樂觀鎖無法解決臟數據讀取的一種體現。CAS算法實現一個重要前提需要取出內存中某時刻的數據，而在下時刻比較並替換，那么在這個時間差類會導致數據的變化。
比如說一個線程one從內存位置V中取出A，這時候另一個線程two也從內存中取出A，並且two進行了一些操作變成了B，然后two又將V位置的數據變成A，這時候線程one進行CAS操作發現內存中仍然是A，然后one操作成功。盡管線程one的CAS操作成功，但是不代表這個過程就是沒有問題的。
部分樂觀鎖的實現是通過版本號（
version）的方式來解決ABA問題，樂觀鎖每次在執行數據的修改操作時，都會帶上一個版本號，一旦版本號和數據的版本號一致就可以執行修改操作並對版本號執行+1操作，否則就執行失敗。因為每次操作的版本號都會隨之增加，所以不會出現ABA問題，因為版本號只會增加不會減少。
如果鏈表的頭在變化了兩次后恢復了原值，但是不代表鏈表就沒有變化。因此AtomicStampedReference/AtomicMarkableReference就很有用了。
AtomicMarkableReference 類描述的一個<Object,Boolean>的對，可以原子的修改Object或者Boolean的值，這種數據結構在一些緩存或者狀態描述中比較有用。這種結構在單個或者同時修改Object/Boolean的時候能夠有效的提高吞吐量。
AtomicStampedReference 類維護帶有整數“標志”的對象引用，可以用原子方式對其進行更新。對比AtomicMarkableReference 類的<Object,Boolean>，AtomicStampedReference 維護的是一種類似<Object,int>的數據結構，其實就是對對象（引用）的一個並發計數（標記版本戳stamp）。但是與AtomicInteger 不同的是，此數據結構可以攜帶一個對象引用（Object），並且能夠對此對象和計數同時進行原子操作。
REFERENCE：
整理自以下博客：
1. http://www.hollischuang.com/archives/934
2. http://www.hollischuang.com/archives/1537
3. http://www.cnblogs.com/Mainz/p/3546347.html
4. http://www.digpage.com/lock.html