第三部分：java多線程鎖，源碼剖析
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、synchronizedkeyword是不能繼承的
也就是說。基類的方法synchronized f(){} 在繼承類中并不自己主動是synchronized f(){}，而是變成了f(){}。
繼承類須要你顯式的指定它的某個方法為synchronized方法；
4、從源代碼具體了解synchronizedkeyword（參考observable類源代碼）
java中的observer模式，看了當中的observable類的源代碼。發現裡面差點兒所有的方法都用了synchronizedkeyword（不是所有）。當中個别用了synchronized(this){}的區塊
參考網址：
http://www.learndiary.com/archives/diaries/2910.htm
javascript:void(0)
眼下在java中存在兩種鎖機制：synchronized和lock。lock接口及事實上現類是jdk5添加的内容，其作者是大名鼎鼎的并發專家douglea。本文并不比較synchronized與lock孰優孰劣，僅僅是介紹二者的實作原理。
資料同步須要依賴鎖，那鎖的同步又依賴誰？synchronized給出的答案是在軟體層面依賴jvm，而lock給出的方案是在硬體層面依賴特殊的cpu指令。大家可能會進一步追問：jvm底層又是怎樣實作synchronized的？
本文所指說的jvm是指hotspot的6u23版本号。以下首先介紹synchronized的實作：
synrhronizedkeyword簡潔、清晰、語義明白，是以即使有了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中可通過synchronizedkeyword鎖鎖住共享資源以實作異步多線程的達到同步。
總結起來。要達到同步。我們要做的就是構造各線程間的共享資源。當中的共享資源能夠對象，也能夠是方法。
執行結果例如以下所看到的（盡供參考分析）：
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
func lock: 7
func lock: 8
func lock: 9
func lock: 10
func lock: 11
no lock: 0
no lock: 1
no lock: 2
no lock: 3
no lock: 4
no lock: 5
no lock: 6
no lock: 7
no lock: 8
no lock: 9
no lock: 10
no lock: 11