分類：目前在Java中存在兩種鎖機制：synchronized和Lock，Lock接口及其實現類是JDK5增加的內容，其作者是大名鼎鼎的併發專家Doug Lea。本文並不比較synchronized與Lock孰優孰劣，只是介紹二者的實現原理。
數據同步需要依賴鎖，那鎖的同步又依賴誰？synchronized給出的答案是在軟件層面依賴JVM，而Lock給出的方案是在硬件層面依賴特殊的CPU指令，大家可能會進一步追問：JVM底層又是如何實現synchronized的？
本文所指說的JVM是指Hotspot的6u23版本，下面首先介紹synchronized的實現：
synrhronized關鍵字簡潔、清晰、語義明確，因此即使有了Lock接口，使用的還是非常廣泛。其應用層的語義是可以把任何一個非null對象作爲"鎖"，當synchronized作用在方法上時，鎖住的便是對象實例（this）；當作用在靜態方法時鎖住的便是對象對應的Class實例，因爲Class數據存在於永久帶，因此靜態方法鎖相當於該類的一個全局鎖；當synchronized作用於某一個對象實例時，鎖住的便是對應的代碼塊。在HotSpot JVM實現中，鎖有個專門的名字：對象監視器。
1. 線程狀態及狀態轉換
當多個線程同時請求某個對象監視器時，對象監視器會設置幾種狀態用來區分請求的線程：
◆ Contention List：所有請求鎖的線程將被首先放置到該競爭隊列。
◆ Entry List：Contention List中那些有資格成爲候選人的線程被移到Entry List。
◆ Wait Set：那些調用wait方法被阻塞的線程被放置到Wait Set。
◆ OnDeck：任何時刻最多只能有一個線程正在競爭鎖，該線程稱爲OnDeck。
◆ Owner：獲得鎖的線程稱爲Owner。
◆ !Owner：釋放鎖的線程。
下圖反映了個狀態轉換關係：
新請求鎖的線程將首先被加入到ConetentionList中，當某個擁有鎖的線程（Owner狀態）調用unlock之後，如果發現EntryList爲空則從ContentionList中移動線程到EntryList，下面說明下ContentionList和EntryList的實現方式：
1.1 ContentionList虛擬隊列
ContentionList並不是一個真正的Queue，而只是一個虛擬隊列，原因在於ContentionList是由Node及其next指針邏輯構成，並不存在一個Queue的數據結構。ContentionList是一個後進先出（LIFO）的隊列，每次新加Node時都會在隊頭進行，通過CAS改變第一個節點的的指針爲新增節點，同時設置新增節點的next指向後續節點，而取得操作則發生在隊尾。顯然，該結構其實是個Lock-Free的隊列。
因爲只有Owner線程才能從隊尾取元素，也即線程出列操作無爭用，當然也就避免了CAS的ABA問題。
1.2 EntryList
EntryList與ContentionList邏輯上同屬等待隊列，ContentionList會被線程併發訪問，爲了降低對ContentionList隊尾的爭用，而建立EntryList。Owner線程在unlock時會從ContentionList中遷移線程到EntryList，並會指定EntryList中的某個線程（一般爲Head）爲Ready（OnDeck）線程。Owner線程並不是把鎖傳遞給OnDeck線程，只是把競爭鎖的權利交給OnDeck，OnDeck線程需要重新競爭鎖。這樣做雖然犧牲了一定的公平性，但極大的提高了整體吞吐量，在Hotspot中把OnDeck的選擇行爲稱之爲“競爭切換”。
OnDeck線程獲得鎖後即變爲owner線程，無法獲得鎖則會依然留在EntryList中，考慮到公平性，在EntryList中的位置不發生變化（依然在隊頭）。如果Owner線程被wait方法阻塞，則轉移到WaitSet隊列；如果在某個時刻被notify/notifyAll喚醒，則再次轉移到EntryList。
2. 自旋鎖
那些處於ContetionList、EntryList、WaitSet中的線程均處於阻塞狀態，阻塞操作由操作系統完成（在Linxu下通過pthread_mutex_lock函數）。線程被阻塞後便進入內核（Linux）調度狀態，這個會導致系統在用戶態與內核態之間來回切換，嚴重影響鎖的性能。
緩解上述問題的辦法便是自旋，其原理是：當發生爭用時，若Owner線程能在很短的時間內釋放鎖，則那些正在爭用線程可以稍微等一等（自旋），在Owner線程釋放鎖後，爭用線程可能會立即得到鎖，從而避免了系統阻塞。但Owner運行的時間可能會超出了臨界值，爭用線程自旋一段時間後還是無法獲得鎖，這時爭用線程則會停止自旋進入阻塞狀態（後退）。基本思路就是自旋，不成功再阻塞，儘量降低阻塞的可能性，這對那些執行時間很短的代碼塊來說有非常重要的性能提高。自旋鎖有個更貼切的名字：自旋-指數後退鎖，也即複合鎖。很顯然，自旋在多處理器上纔有意義。
還有個問題是，線程自旋時做些啥？其實啥都不做，可以執行幾次for循環，可以執行幾條空的彙編指令，目的是佔着CPU不放，等待獲取鎖的機會。所以說，自旋是把雙刃劍，如果旋的時間過長會影響整體性能，時間過短又達不到延遲阻塞的目的。顯然，自旋的週期選擇顯得非常重要，但這與操作系統、硬件體系、系統的負載等諸多場景相關，很難選擇，如果選擇不當，不但性能得不到提高，可能還會下降，因此大家普遍認爲自旋鎖不具有擴展性。
對自旋鎖週期的選擇上，HotSpot認爲最佳時間應是一個線程上下文切換的時間，但目前並沒有做到。經過調查，目前只是通過彙編暫停了幾個CPU週期，除了自旋週期選擇，HotSpot還進行許多其他的自旋優化策略，具體如下：
◆ 如果平均負載小於CPUs則一直自旋。
◆ 如果有超過(CPUs/2)個線程正在自旋，則後來線程直接阻塞。
◆ 如果正在自旋的線程發現Owner發生了變化則延遲自旋時間（自旋計數）或進入阻塞。
◆ 如果CPU處於節電模式則停止自旋。
◆ 自旋時間的最壞情況是CPU的存儲延遲（CPU A存儲了一個數據，到CPU B得知這個數據直接的時間差）。
◆ 自旋時會適當放棄線程優先級之間的差異。
那synchronized實現何時使用了自旋鎖？答案是在線程進入ContentionList時，也即第一步操作前。線程在進入等待隊列時首先進行自旋嘗試獲得鎖，如果不成功再進入等待隊列。這對那些已經在等待隊列中的線程來說，稍微顯得不公平。還有一個不公平的地方是自旋線程可能會搶佔了Ready線程的鎖。自旋鎖由每個監視對象維護，每個監視對象一個。
3. 偏向鎖
在JVM1.6中引入了偏向鎖，偏向鎖主要解決無競爭下的鎖性能問題，首先我們看下無競爭下鎖存在什麼問題：
現在幾乎所有的鎖都是可重入的，也即已經獲得鎖的線程可以多次鎖住/解鎖監視對象，按照之前的HotSpot設計，每次加鎖/解鎖都會涉及到一些CAS操作（比如對等待隊列的CAS操作），CAS操作會延遲本地調用，因此偏向鎖的想法是一旦線程第一次獲得了監視對象，之後讓監視對象“偏向”這個線程，之後的多次調用則可以避免CAS操作，說白了就是置個變量，如果發現爲true則無需再走各種加鎖/解鎖流程。但還有很多概念需要解釋、很多引入的問題需要解決。
3.1 CAS及SMP架構
CAS爲什麼會引入本地延遲？這要從SMP（對稱多處理器）架構說起，下圖大概表明了SMP的結構：
其意思是所有的CPU會共享一條系統總線（BUS），靠此總線連接主存。每個核都有自己的一級緩存，各核相對於BUS對稱分佈，因此這種結構稱爲“對稱多處理器”。
而CAS的全稱爲Compare-And-Swap，是一條CPU的原子指令，其作用是讓CPU比較後原子地更新某個位置的值，經過調查發現，其實現方式是基於硬件平臺的彙編指令，就是說CAS是靠硬件實現的，JVM只是封裝了彙編調用，那些AtomicInteger類便是使用了這些封裝後的接口。
Core1和Core2可能會同時把主存中某個位置的值Load到自己的L1 Cache中，當Core1在自己的L1 Cache中修改這個位置的值時，會通過總線，使Core2中L1 Cache對應的值“失效”，而Core2一旦發現自己L1 Cache中的值失效（稱爲Cache命中缺失）則會通過總線從內存中加載該地址最新的值，大家通過總線的來回通信稱爲“Cache一致性流量”，因爲總線被設計爲固定的“通信能力”，如果Cache一致性流量過大，總線將成爲瓶頸。而當Core1和Core2中的值再次一致時，稱爲“Cache一致性”，從這個層面來說，鎖設計的終極目標便是減少Cache一致性流量。
而CAS恰好會導致Cache一致性流量，如果有很多線程都共享同一個對象，當某個Core CAS成功時必然會引起總線風暴，這就是所謂的本地延遲，本質上偏向鎖就是爲了消除CAS，降低Cache一致性流量。
Cache一致性：
上面提到Cache一致性，其實是有協議支持的，現在通用的協議是MESI（最早由Intel開始支持），具體參考：http://en.wikipedia.org/wiki/MESI_protocol，以後會仔細講解這部分。
Cache一致性流量的例外情況：
其實也不是所有的CAS都會導致總線風暴，這跟Cache一致性協議有關，具體參考：http://blogs.oracle.com/dave/entry/biased_locking_in_hotspot
NUMA(Non Uniform Memory Access Achitecture）架構：
與SMP對應還有非對稱多處理器架構，現在主要應用在一些高端處理器上，主要特點是沒有總線，沒有公用主存，每個Core有自己的內存，針對這種結構此處不做討論。
3.2 偏向解除
偏向鎖引入的一個重要問題是，在多爭用的場景下，如果另外一個線程爭用偏向對象，擁有者需要釋放偏向鎖，而釋放的過程會帶來一些性能開銷，但總體說來偏向鎖帶來的好處還是大於CAS代價的。
4. 總結
關於鎖，JVM中還引入了一些其他技術比如鎖膨脹等，這些與自旋鎖、偏向鎖相比影響不是很大，這裏就不做介紹。
通過上面的介紹可以看出，synchronized的底層實現主要依靠Lock-Free的隊列，基本思路是自旋後阻塞，競爭切換後繼續競爭鎖，稍微犧牲了公平性，但獲得了高吞吐量。下面會繼續介紹JVM鎖中的Lock（深入JVM鎖2-Lock）。
原文鏈接：http://blog.csdn.net/chen77716/article/details/6618779
前文（深入JVM鎖機制-synchronized）分析了JVM中的synchronized實現，本文繼續分析JVM中的另一種鎖Lock的實現。與synchronized不同的是，Lock完全用Java寫成，在java這個層面是無關JVM實現的。
在java.util.concurrent.locks包中有很多Lock的實現類，常用的有ReentrantLock、ReadWriteLock（實現類ReentrantReadWriteLock），其實現都依賴java.util.concurrent.AbstractQueuedSynchronizer類，實現思路都大同小異，因此我們以ReentrantLock作爲講解切入點。
1. ReentrantLock的調用過程
經過觀察ReentrantLock把所有Lock接口的操作都委派到一個Sync類上，該類繼承了AbstractQueuedSynchronizer：
- static abstract class Sync extends AbstractQueuedSynchronizer
Sync又有兩個子類：
- final static class NonfairSync extends Sync
- final static class FairSync extends Sync
顯然是爲了支持公平鎖和非公平鎖而定義，默認情況下爲非公平鎖。
先理一下Reentrant.lock()方法的調用過程（默認非公平鎖）：
這些討厭的Template模式導致很難直觀的看到整個調用過程，其實通過上面調用過程及AbstractQueuedSynchronizer的註釋可以發現，AbstractQueuedSynchronizer中抽象了絕大多數Lock的功能，而只把tryAcquire方法延遲到子類中實現。tryAcquire方法的語義在於用具體子類判斷請求線程是否可以獲得鎖，無論成功與否AbstractQueuedSynchronizer都將處理後面的流程。
2. 鎖實現（加鎖）
簡單說來，AbstractQueuedSynchronizer會把所有的請求線程構成一個CLH隊列，當一個線程執行完畢（lock.unlock()）時會激活自己的後繼節點，但正在執行的線程並不在隊列中，而那些等待執行的線程全部處於阻塞狀態，經過調查線程的顯式阻塞是通過調用LockSupport.park()完成，而LockSupport.park()則調用sun.misc.Unsafe.park()本地方法，再進一步，HotSpot在Linux中中通過調用pthread_mutex_lock函數把線程交給系統內核進行阻塞。
該隊列如圖：
與synchronized相同的是，這也是一個虛擬隊列，不存在隊列實例，僅存在節點之間的前後關係。令人疑惑的是爲什麼採用CLH隊列呢？原生的CLH隊列是用於自旋鎖，但Doug Lea把其改造爲阻塞鎖。
當有線程競爭鎖時，該線程會首先嚐試獲得鎖，這對於那些已經在隊列中排隊的線程來說顯得不公平，這也是非公平鎖的由來，與synchronized實現類似，這樣會極大提高吞吐量。
如果已經存在Running線程，則新的競爭線程會被追加到隊尾，具體是採用基於CAS的Lock-Free算法，因爲線程併發對Tail調用CAS可能會導致其他線程CAS失敗，解決辦法是循環CAS直至成功。AbstractQueuedSynchronizer的實現非常精巧，令人歎爲觀止，不入細節難以完全領會其精髓，下面詳細說明實現過程：
2.1 Sync.nonfairTryAcquire
nonfairTryAcquire方法將是lock方法間接調用的第一個方法，每次請求鎖時都會首先調用該方法。
- final boolean nonfairTryAcquire(int acquires) {
- final Thread current = Thread.currentThread();
- int c = getState();
- if (c == 0) {
- if (compareAndSetState(0, acquires)) {
- setExclusiveOwnerThread(current);
- return true;
- }
- }
- else if (current == getExclusiveOwnerThread()) {
- int nextc = c + acquires;
- if (nextc < 0) // overflow
- throw new Error("Maximum lock count exceeded");
- setState(nextc);
- return true;
- }
- return false;
- }
該方法會首先判斷當前狀態，如果c==0說明沒有線程正在競爭該鎖，如果不c !=0 說明有線程正擁有了該鎖。
如果發現c==0，則通過CAS設置該狀態值爲acquires,acquires的初始調用值爲1，每次線程重入該鎖都會+1，每次unlock都會-1，但爲0時釋放鎖。如果CAS設置成功，則可以預計其他任何線程調用CAS都不會再成功，也就認爲當前線程得到了該鎖，也作爲Running線程，很顯然這個Running線程並未進入等待隊列。
如果c !=0 但發現自己已經擁有鎖，只是簡單地++acquires，並修改status值，但因爲沒有競爭，所以通過setStatus修改，而非CAS，也就是說這段代碼實現了偏向鎖的功能，並且實現的非常漂亮。
2.2 AbstractQueuedSynchronizer.addWaiter
addWaiter方法負責把當前無法獲得鎖的線程包裝爲一個Node添加到隊尾：
- private Node addWaiter(Node mode) {
- Node node = new Node(Thread.currentThread(), mode);
- // Try the fast path of enq; backup to full enq on failure
- Node pred = tail;
- if (pred != null) {
- node.prev = pred;
- if (compareAndSetTail(pred, node)) {
- pred.next = node;
- return node;
- }
- }
- enq(node);
- return node;
- }
- 如果當前隊尾已經存在(tail!=null)，則使用CAS把當前線程更新爲Tail。
- 如果當前Tail爲null或則線程調用CAS設置隊尾失敗，則通過enq方法繼續設置Tail。
- private Node enq(final Node node) {
- for (;;) {
- Node t = tail;
- if (t == null) { // Must initialize
- Node h = new Node(); // Dummy header
- h.next = node;
- node.prev = h;
- if (compareAndSetHead(h)) {
- tail = node;
- return h;
- }
- }
- else {
- node.prev = t;
- if (compareAndSetTail(t, node)) {
- t.next = node;
- return t;
- }
- }
- }
- }
該方法就是循環調用CAS，即使有高併發的場景，無限循環將會最終成功把當前線程追加到隊尾（或設置隊頭）。總而言之，addWaiter的目的就是通過CAS把當前現在追加到隊尾，並返回包裝後的Node實例。
把線程要包裝爲Node對象的主要原因，除了用Node構造供虛擬隊列外，還用Node包裝了各種線程狀態，這些狀態被精心設計爲一些數字值：
◆ SIGNAL(-1) ：線程的後繼線程正/已被阻塞，當該線程release或cancel時要重新這個後繼線程(unpark)。
◆ CANCELLED(1)：因爲超時或中斷，該線程已經被取消。
◆ CONDITION(-2)：表明該線程被處於條件隊列，就是因爲調用了Condition.await而被阻塞。
◆ PROPAGATE(-3)：傳播共享鎖。
◆ 0：0代表無狀態。
2.3 AbstractQueuedSynchronizer.acquireQueued
acquireQueued的主要作用是把已經追加到隊列的線程節點（addWaiter方法返回值）進行阻塞，但阻塞前又通過tryAccquire重試是否能獲得鎖，如果重試成功能則無需阻塞，直接返回
- final boolean acquireQueued(final Node node, int arg) {
- try {
- boolean interrupted = false;
- for (;;) {
- final Node p = node.predecessor();
- if (p == head && tryAcquire(arg)) {
- setHead(node);
- p.next = null; // help GC
- return interrupted;
- }
- if (shouldParkAfterFailedAcquire(p, node) &&
- parkAndCheckInterrupt())
- interrupted = true;
- }
- } catch (RuntimeException ex) {
- cancelAcquire(node);
- throw ex;
- }
- }
仔細看看這個方法是個無限循環，感覺如果p == head && tryAcquire(arg)條件不滿足循環將永遠無法結束，當然不會出現死循環，奧祕在於第12行的parkAndCheckInterrupt會把當前線程掛起，從而阻塞住線程的調用棧。
- private final boolean parkAndCheckInterrupt() {
- LockSupport.park(this);
- return Thread.interrupted();
- }
如前面所述，LockSupport.park最終把線程交給系統（Linux）內核進行阻塞。當然也不是馬上把請求不到鎖的線程進行阻塞，還要檢查該線程的狀態，比如如果該線程處於Cancel狀態則沒有必要，具體的檢查在shouldParkAfterFailedAcquire中：
- private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) {
- int ws = pred.waitStatus;
- if (ws == Node.SIGNAL)
- /*
- * This node has already set status asking a release
- * to signal it, so it can safely park
- */
- return true;
- if (ws > 0) {
- /*
- * Predecessor was cancelled. Skip over predecessors and
- * indicate retry.
- */
- do {
- node.prev = pred = pred.prev;
- } while (pred.waitStatus > 0);
- pred.next = node;
- } else {
- /*
- * waitStatus must be 0 or PROPAGATE. Indicate that we
- * need a signal, but don't park yet. Caller will need to
- * retry to make sure it cannot acquire before parking.
- */
- compareAndSetWaitStatus(pred, ws, Node.SIGNAL);
- }
- return false;
- }
檢查原則在於：
◆ 規則1：如果前繼的節點狀態爲SIGNAL，表明當前節點需要unpark，則返回成功，此時acquireQueued方法的第12行（parkAndCheckInterrupt）將導致線程阻塞。
◆ 規則2：如果前繼節點狀態爲CANCELLED(ws>0)，說明前置節點已經被放棄，則回溯到一個非取消的前繼節點，返回false，acquireQueued方法的無限循環將遞歸調用該方法，直至規則1返回true，導致線程阻塞。
◆ 規則3：如果前繼節點狀態爲非SIGNAL、非CANCELLED，則設置前繼的狀態爲SIGNAL，返回false後進入acquireQueued的無限循環，與規則2同。
總體看來，shouldParkAfterFailedAcquire就是靠前繼節點判斷當前線程是否應該被阻塞，如果前繼節點處於CANCELLED狀態，則順便刪除這些節點重新構造隊列。
至此，鎖住線程的邏輯已經完成，下面討論解鎖的過程。
3. 解 鎖
請求鎖不成功的線程會被掛起在acquireQueued方法的第12行，12行以後的代碼必須等線程被解鎖鎖才能執行，假如被阻塞的線程得到解鎖，則執行第13行，即設置interrupted = true，之後又進入無限循環。
從無限循環的代碼可以看出，並不是得到解鎖的線程一定能獲得鎖，必須在第6行中調用tryAccquire重新競爭，因爲鎖是非公平的，有可能被新加入的線程獲得，從而導致剛被喚醒的線程再次被阻塞，這個細節充分體現了“非公平”的精髓。通過之後將要介紹的解鎖機制會看到，第一個被解鎖的線程就是Head，因此p == head的判斷基本都會成功。
至此可以看到，把tryAcquire方法延遲到子類中實現的做法非常精妙並具有極強的可擴展性，令人歎爲觀止！當然精妙的不是這個Templae設計模式，而是Doug Lea對鎖結構的精心佈局。
解鎖代碼相對簡單，主要體現在AbstractQueuedSynchronizer.release和Sync.tryRelease方法中：
class AbstractQueuedSynchronizer
- public final boolean release(int arg) {
- if (tryRelease(arg)) {
- Node h = head;
- if (h != null && h.waitStatus != 0)
- unparkSuccessor(h);
- return true;
- }
- return false;
- }
class Sync
- protected final boolean tryRelease(int releases) {
- int c = getState() - releases;
- if (Thread.currentThread() != getExclusiveOwnerThread())
- throw new IllegalMonitorStateException();
- boolean free = false;
- if (c == 0) {
- free = true;
- setExclusiveOwnerThread(null);
- }
- setState(c);
- return free;
- }
tryRelease與tryAcquire語義相同，把如何釋放的邏輯延遲到子類中。tryRelease語義很明確：如果線程多次鎖定，則進行多次釋放，直至status==0則真正釋放鎖，所謂釋放鎖即設置status爲0，因爲無競爭所以沒有使用CAS。
release的語義在於：如果可以釋放鎖，則喚醒隊列第一個線程（Head），具體喚醒代碼如下：
- private void unparkSuccessor(Node node) {
- /*
- * If status is negative (i.e., possibly needing signal) try
- * to clear in anticipation of signalling. It is OK if this
- * fails or if status is changed by waiting thread.
- */
- int ws = node.waitStatus;
- if (ws < 0)
- compareAndSetWaitStatus(node, ws, 0);
- /*
- * Thread to unpark is held in successor, which is normally
- * just the next node. But if cancelled or apparently null,
- * traverse backwards from tail to find the actual
- * non-cancelled successor.
- */
- Node s = node.next;
- if (s == null || s.waitStatus > 0) {
- s = null;
- for (Node t = tail; t != null && t != node; t = t.prev)
- if (t.waitStatus <= 0)
- s = t;
- }
- if (s != null)
- LockSupport.unpark(s.thread);
- }
這段代碼的意思在於找出第一個可以unpark的線程，一般說來head.next == head，Head就是第一個線程，但Head.next可能被取消或被置爲null，因此比較穩妥的辦法是從後往前找第一個可用線程。貌似回溯會導致性能降低，其實這個發生的機率很小，所以不會有性能影響。之後便是通知系統內核繼續該線程，在Linux下是通過pthread_mutex_unlock完成。之後，被解鎖的線程進入上面所說的重新競爭狀態。
4. Lock VS Synchronized
AbstractQueuedSynchronizer通過構造一個基於阻塞的CLH隊列容納所有的阻塞線程，而對該隊列的操作均通過Lock-Free（CAS）操作，但對已經獲得鎖的線程而言，ReentrantLock實現了偏向鎖的功能。
synchronized的底層也是一個基於CAS操作的等待隊列，但JVM實現的更精細，把等待隊列分爲ContentionList和EntryList，目的是爲了降低線程的出列速度；當然也實現了偏向鎖，從數據結構來說二者設計沒有本質區別。但synchronized還實現了自旋鎖，並針對不同的系統和硬件體系進行了優化，而Lock則完全依靠系統阻塞掛起等待線程。
當然Lock比synchronized更適合在應用層擴展，可以繼承AbstractQueuedSynchronizer定義各種實現，比如實現讀寫鎖（ReadWriteLock），公平或不公平鎖；同時，Lock對應的Condition也比wait/notify要方便的多、靈活的多。
原文鏈接：http://blog.csdn.net/chen77716/article/details/6641477
