本Blog分爲如下部分：
第一部分：synchronized與static synchronized 的區別
第二部分：JVM底層又是如何實現synchronized的
第一部分：synchronized與static synchronized的區別
1、synchronized與static synchronized 的區別
synchronized是對類的當前實例進行加鎖，防止其他線程同時訪問該類的該實例的所有synchronized塊，注意這裏是“類的當前實例”，類的兩個不同實例就沒有這種約束了。那麼static synchronized恰好就是要控制類的所有實例的訪問了，static synchronized是限制線程同時訪問jvm中該類的所有實例同時訪問對應的代碼快。實際上，在類中某方法或某代碼塊中有 synchronized，那麼在生成一個該類實例後，該類也就有一個監視快，放置線程併發訪問該實例synchronized保護快，而static
synchronized則是所有該類的實例公用一個監視快了，也就是兩個的區別了,也就是synchronized相當於this.synchronized，而staticsynchronized相當於Something.synchronized.
pulbic class Something(){
public synchronized void isSyncA(){}
public synchronized voidisSyncB(){}
public static synchronizedvoid cSyncA(){}
public static synchronizedvoid cSyncB(){}
}
註解：該列子來自一個日本作者-結成浩的《java多線程設計模式》
那麼，假如有Something類的兩個實例a與b，那麼下列組方法何以被1個以上線程同時訪問呢
a. x.isSyncA()與x.isSyncB()
b. x.isSyncA()與y.isSyncA()
c. x.cSyncA()與y.cSyncB()
d. x.isSyncA()與Something.cSyncA()
這裏，很清楚的可以判斷：
a，都是對同一個實例的synchronized域訪問，因此不能被同時訪問
b，是針對不同實例的，因此可以同時被訪問
c，因爲是staticsynchronized，所以不同實例之間仍然會被限制,相當於Something.isSyncA()與 Something.isSyncB()了，因此不能被同時訪問。
那麼，第d呢?，書上的 答案是可以被同時訪問的，答案理由是synchronzied的是實例方法與synchronzied的類方法由於鎖定（lock）不同的原因。
個人分析也就是synchronized 與static synchronized 相當於兩幫派，各自管各自，相互之間就無約束了，可以被同時訪問。後面一部分將詳細分析synchronzied是怎麼樣實現的。
結論：
A: synchronized static是某個類的範圍，synchronized static cSync{}防止多個線程同時訪問這個類中的synchronized static 方法。它可以對類的所有對象實例起作用。
B: synchronized 是某實例的範圍，synchronized isSync(){}防止多個線程同時訪問這個實例中的synchronized 方法。
2、synchronized方法與synchronized代碼快的區別
synchronizedmethods(){}
與synchronized（this）{}之間沒有什麼區別，只是 synchronized methods(){} 便於閱讀理解，而synchronized（this）{}可以更精確的控制衝突限制訪問區域，有時候表現更高效率。
3、synchronized關鍵字是不能繼承的
也就是說，基類的方法synchronized f(){} 在繼承類中並不自動是synchronized f(){}，而是變成了f(){}。繼承類需要你顯式的指定它的某個方法爲synchronized方法；
4、從源代碼詳細理解synchronized關鍵字（參考Observable類源碼）
Java中的Observer模式，看了其中的Observable類的源碼，發現裏面幾乎所有的方法都用了synchronized關鍵字（不是全部），其中個別用了synchronized(this){}的區塊
http://www.learndiary.com/archives/diaries/2910.htm
http://www.cnblogs.com/shipengzhi/articles/2223100.html
第二部分：JVM底層又是如何實現synchronized的
目前在Java中存在兩種鎖機制：synchronized和Lock，Lock接口及其實現類是JDK5增加的內容，其作者是大名鼎鼎的併發專家DougLea。本文並不比較synchronized與Lock孰優孰劣，只是介紹二者的實現原理。
數據同步需要依賴鎖，那鎖的同步又依賴誰？synchronized給出的答案是在軟件層面依賴JVM，而Lock給出的方案是在硬件層面依賴特殊的CPU指令，大家可能會進一步追問：JVM底層又是如何實現synchronized的？
本文所指說的JVM是指Hotspot的6u23版本，下面首先介紹synchronized的實現：
synrhronized關鍵字簡潔、清晰、語義明確，因此即使有了Lock接口，使用的還是非常廣泛。其應用層的語義是可以把任何一個非null對象作爲"鎖"，當synchronized作用在方法上時，鎖住的便是對象實例（this）；當作用在靜態方法時鎖住的便是對象對應的Class實例，因爲 Class數據存在於永久帶，因此靜態方法鎖相當於該類的一個全局鎖；當synchronized作用於某一個對象實例時，鎖住的便是對應的代碼塊。在HotSpot JVM實現中，鎖有個專門的名字：對象監視器。
1. 線程狀態及狀態轉換
當多個線程同時請求某個對象監視器時，對象監視器會設置幾種狀態用來區分請求的線程：
ContentionList：所有請求鎖的線程將被首先放置到該競爭隊列
EntryList：ContentionList中那些有資格成爲候選人的線程被移到Entry List
WaitSet：那些調用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偏向鎖
在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的隊列，基本思路是自旋後阻塞，競爭切換後繼續競爭鎖，稍微犧牲了公平性，但獲得了高吞吐量。
參考文獻：http://www.open-open.com/lib/view/open1352431526366.html
第三部分：Java多線程鎖，源代碼剖析
多線程的同步依靠的是鎖機制，java中可通過synchronized關鍵字鎖鎖住共享資源以實現異步多線程的達到同步。總結起來，要達到同步，我們要做的就是構造各線程間的共享資源，其中的共享資源可以對象，也可以是方法。
package algorithms.com.guan.zoo.stackTest;
public class LockDemo {
public static void main(String[] args) {
MyRunnerVarLock runnerVarLock = new MyRunnerVarLock(new Integer(0));
MyRunnerFuncLock runnerFuncLock = new MyRunnerFuncLock();
MyRunnerNoLock runnerNoLock = new MyRunnerNoLock();
// 對共享對象進行加鎖，線程會依次打印0-99的數，每一次運行的結果都一樣
for(int i = 0; i < 10; i++) {
Thread thread = new Thread(runnerVarLock);
thread.start();
}
// 對共享函數進行加鎖，線程會依次打印0-99的數，每一次運行的結果都一樣
for(int i = 0; i < 10; i++) {
Thread thread = new Thread(runnerFuncLock);
thread.start();
}
// 未加鎖，會因爲線程調用的時序不同而發生變化，每一次運行的結果不一定相同
for(int i = 0; i < 10; i++) {
Thread thread = new Thread(runnerNoLock);
thread.start();
}
}
}
// 對共享對象進行加鎖
class MyRunnerVarLock implements Runnable {
private Object lock;
public MyRunnerVarLock(Object lock) {
this.lock = lock;
}
public void run() {
synchronized (lock) {
for (int i = 0; i < 100; i++) {
System.out.println("Lock: " + i);
}
}
}
}
// 對共享函數進行加鎖
class MyRunnerFuncLock implements Runnable {
public synchronized void run() {
for (int i = 0; i < 100; i++) {
System.out.println("Func lock: " + i);
}
}
}
// 沒有加鎖
class MyRunnerNoLock implements Runnable {
public void run() {
for (int i = 0; i < 100; i++) {
System.out.println("No lock: " + i);
}
}
}運行結果如下所示（盡供參考分析）：
Lock: 0
Lock: 1
Lock: 2
Lock: 3
Lock: 4
Lock: 5
Lock: 6
Lock: 7
Lock: 8
Lock: 9
Lock: 10
Lock: 11
Lock: 0
Lock: 1
Lock: 2
Lock: 3
Lock: 4
Lock: 5
Lock: 6
Lock: 7
Lock: 8
Lock: 9
Lock: 10
Lock: 11
Lock: 0
Lock: 1
Lock: 2
Lock: 3
Lock: 4
Lock: 5
Lock: 6
Lock: 7
Lock: 8
Lock: 9
Lock: 10
Lock: 11
Lock: 0
Lock: 1
Lock: 2
Lock: 3
Lock: 4
Lock: 5
Lock: 6
Lock: 7
Lock: 8
Lock: 9
Lock: 10
Lock: 11
Func lock: 0
Func lock: 1
Func lock: 2
Func lock: 3
Func lock: 4
Func lock: 5
Func lock: 6
Lock: 0
Lock: 1
Lock: 2
Lock: 3
Lock: 4
Lock: 5
Func lock: 7
Func lock: 8
Func lock: 9
Func lock: 10
Func lock: 11
Func lock: 0
Func lock: 1
Func lock: 2
Func lock: 3
Func lock: 4
Func lock: 5
Lock: 6
Lock: 7
Func lock: 6
Func lock: 7
Lock: 8
Lock: 9
Lock: 10
Lock: 11
Func lock: 8
Func lock: 9
Lock: 0
Lock: 1
Lock: 2
Lock: 3
Lock: 4
Lock: 5
Lock: 6
Lock: 7
Lock: 8
Lock: 9
Lock: 10
Lock: 11
Lock: 0
Lock: 1
Lock: 2
No lock: 0
No lock: 0
No lock: 1
No lock: 2
Func lock: 10
Func lock: 11
No lock: 3
No lock: 4
No lock: 5
No lock: 6
No lock: 0
No lock: 1
No lock: 0
No lock: 1
No lock: 2
No lock: 3
Lock: 3
No lock: 0
No lock: 1
No lock: 0
No lock: 0
No lock: 1
No lock: 2
No lock: 0
Lock: 4
No lock: 4
No lock: 0
No lock: 2
No lock: 1
No lock: 7
No lock: 0
Func lock: 0
No lock: 1
No lock: 8
No lock: 2
No lock: 3
No lock: 1
No lock: 5
Lock: 5
No lock: 1
No lock: 2
No lock: 3
No lock: 2
No lock: 1
No lock: 3
No lock: 4
No lock: 3
Lock: 6
No lock: 6
No lock: 2
No lock: 4
No lock: 5
No lock: 3
No lock: 9
No lock: 2
Func lock: 1
No lock: 3
No lock: 10
No lock: 4
No lock: 6
No lock: 3
No lock: 7
Lock: 7
Lock: 8
Lock: 9
Lock: 10
No lock: 4
No lock: 5
No lock: 5
No lock: 4
No lock: 2
No lock: 5
No lock: 6
No lock: 6
No lock: 7
Lock: 11
No lock: 8
No lock: 9
No lock: 4
No lock: 7
No lock: 5
No lock: 11
No lock: 4
Func lock: 2
No lock: 5
No lock: 6
No lock: 8
No lock: 5
No lock: 10
Lock: 0
No lock: 8
No lock: 7
No lock: 6
No lock: 3
No lock: 7
No lock: 8
No lock: 9
No lock: 10
Lock: 1
No lock: 11
No lock: 6
No lock: 9
No lock: 7
No lock: 7
No lock: 6
Func lock: 3
No lock: 7
No lock: 8
No lock: 8
No lock: 10
Lock: 2
No lock: 11
No lock: 9
No lock: 8
No lock: 9
No lock: 4
No lock: 10
No lock: 10
Lock: 3
No lock: 11
No lock: 9
No lock: 9
No lock: 8
Func lock: 4
No lock: 9
No lock: 10
No lock: 10
Lock: 4
No lock: 11
No lock: 11
No lock: 5
No lock: 6
No lock: 7
Lock: 5
No lock: 11
No lock: 11
No lock: 10
No lock: 11
Func lock: 5
Lock: 6
No lock: 8
Lock: 7
Func lock: 6
Lock: 8
No lock: 9
Lock: 9
Func lock: 7
Lock: 10
No lock: 10
No lock: 11
Lock: 11
Func lock: 8
Lock: 0
Func lock: 9
Lock: 1
Func lock: 10
Lock: 2
Func lock: 11
Lock: 3
Func lock: 0
Lock: 4
Func lock: 1
Lock: 5
Func lock: 2
Lock: 6
Func lock: 3
Func lock: 4
Lock: 7
Func lock: 5
Lock: 8
Func lock: 6
Func lock: 7
Lock: 9
Func lock: 8
Lock: 10
Func lock: 9
Lock: 11
Func lock: 10
Lock: 0
Func lock: 11
Lock: 1
Lock: 2
Lock: 3
Lock: 4
Func lock: 0
Func lock: 1
Func lock: 2
Lock: 5
Func lock: 3
Lock: 6
Func lock: 4
Lock: 7
Func lock: 5
Lock: 8
Func lock: 6
Lock: 9
Func lock: 7
Lock: 10
Func lock: 8
Lock: 11
Func lock: 9
Func lock: 10
Func lock: 11
Func lock: 0
Func lock: 1
Func lock: 2
Func lock: 3
Func lock: 4
Func lock: 5
Func lock: 6
Func lock: 7
Func lock: 8
Func lock: 9
Func lock: 10
Func lock: 11
Func lock: 0
Func lock: 1
Func lock: 2
Func lock: 3
Func lock: 4
Func lock: 5
Func lock: 6
Func lock: 7
Func lock: 8
Func lock: 9
Func lock: 10
Func lock: 11
Func lock: 0
Func lock: 1
Func lock: 2
Func lock: 3
Func lock: 4
Func lock: 5
Func lock: 6
Func lock: 7
Func lock: 8
Func lock: 9
Func lock: 10
Func lock: 11
Func lock: 0
Func lock: 1
Func lock: 2
Func lock: 3
Func lock: 4
Func lock: 5
Func lock: 6
Func lock: 7
Func lock: 8
Func lock: 9
Func lock: 10
Func lock: 11
Func lock: 0
Func lock: 1
Func lock: 2
Func lock: 3
Func lock: 4
Func lock: 5
Func lock: 6
Func lock: 7
Func lock: 8
Func lock: 9
Func lock: 10
Func lock: 11
參考網址：http://www.kankanews.com/ICkengine/archives/19105.shtml