459
Java線程之鎖研究
JDK1.5以後，在鎖機製方麵引入了新的鎖-Lock，在網上的說法都比較籠統，結合網上的信息和我的理解這裏做個總結。
JAVA現有的鎖機製有兩種實現方式。JDK1.4前是通過synchronized實現。JDK1.5後加入java.util.concurrent.locks包下的各種lock。先看一看代碼層的區別。
synchronized
在代碼中synchronized類似“麵向對象”，修飾類、方法、對象。
Lock
不作為修飾，類似“麵向過程”，在方法中需要鎖的時候lock，在結束的時候unlock（一般都在finally裏）。
public void method1() {
// 舊鎖，無需人工釋放
synchronized(this){
System.out.println(1);
}
}
public void method2() {
Lock lock = new ReentrantLock();
//上鎖
lock.lock();
try{
System.out.println(2);
}finally{
// 解鎖
lock.unlock();
}
}
其次說說性能。
相關的性能測試網上已經有很多，直接拿來主義給出結論：
在並發高時lock性能優勢很明顯，在低並發時，synchronized也能取得優勢。具體的臨界範圍比較難定論，下麵會討論。
現在來分析具體的區別。
鎖都是原子性的，也可以理解為鎖是否在使用的標記，並且比較和設置這個標記的操作是原子性的，不同硬件平台上的jdk實現鎖的相關方法都是native的，比如park/unpark，所
以不同平台上鎖的精確度的等級由這些native的方法決定。所以網上經常可以看見的結論是Lock比synchronized有更精確的原子操作，說的也是native方法，不得不感慨C才是硬件王道。
下麵繼續討論怎麼由代碼層到native的過程。
①所有對象都自動含有單一的鎖，JVM負責跟蹤對象被加鎖的次數。如果一個對象被解鎖，其計數變為0。在任務（線程）第一次給對象加鎖的時候，計數變為1。每當這個相同的任務（線程）在此對象上獲得鎖時，計數會遞增。隻有首先獲得鎖的任務（線程）才能繼續獲取該對象上的多個鎖。每當任務離開時，計數遞減，當計數為0的時候，鎖被完全釋放。synchronized就是基於這個原理，同時synchronized靠某個對象的單一鎖技術的次數來判斷是否被鎖，所以無需（也不能）人工幹預鎖的獲取和釋放。如果結合方法調用時的棧和框架(如果對方法的調用過程不熟悉建議看看https://wupuyuan.iteye.com/blog/1157548)，不難推測出synchronized原理是基於棧中的某對象來控製一個框架，所以對於synchronized有常用的優化是鎖對象不鎖方法。實際上synchronized作用於方法時，鎖住的是this，作用於靜態方法/屬性時，鎖住的是存在於永久帶的CLASS，相當於這個CLASS的全局鎖，鎖作用於一般對象時，鎖住的是對應代碼塊。在HotSpot中JVM實現中，鎖有個專門的名字：對象監視器。當多個線程同時請求某個對象監視器時，對象監視器會設置幾種狀態用來區分請求的線程：
Contention List
所有請求鎖的線程將被首先放置到該競爭隊列，是個虛擬隊列，不是實際的Queue的數據結構。
Entry List
EntryList與ContentionList邏輯上同屬等待隊列，ContentionList會被線程並發訪問，為了降低對ContentionList隊尾的爭用，而建立EntryList。，Contention Lis中那些有資格成為候選人的線程被移到Entry List。
Wait Set
那些調用wait方法被阻塞的線程被放置到Wait Set
OnDeck
任何時刻最多隻能有一個線程正在競爭鎖，該線程稱為OnDeck
Owner
獲得鎖的線程稱為Owner
!Owner
釋放鎖的線程
②Lock不同於synchronized麵向對象，它基於棧中的框架而不是某個具體對象，所以Lock隻需要在棧裏設置鎖的開始和結束（lock和unlock）的地方就行了（人工必須標明），不用關心框架大小對象的變化等等。這麼做的好處是Lock能提供無條件的、可輪詢的、定時的、可中斷的鎖獲取操作，相對於synchronized來說，synchronized的鎖的獲取是釋放必須在一個模塊裏，獲取和釋放的順序必須相反，而Lock則可以在不同範圍內獲取釋放，並且順序無關。
java.util.concurrent.locks下的鎖類很類似，依賴於java.util.concurrent.AbstractQueuedSynchronizer，它們把所有的Lock接口操作都轉嫁到Sync類上，這個類繼承了AbstractQueuedSynchronizer，它同時還包含子2個類：NonfairSync 和FairSync 從名字上可以看的出是為了實現公平和非公平性。AbstractQueuedSynchronizer中把所有的的請求線程構成一個隊列（一樣也是虛擬的），具體的實現可以參考https://blog.csdn.net/chen77716/article/details/6641477。
③從jdk的源代碼來看，Lock和synchronized的源碼基本相同，區別主要在維護的同步隊列上。再往下深究就到了native方法了。
④還有個改進其實很重要的。線程分阻塞（wait）和非阻塞狀態，阻塞狀態由操作係統（linux、windows等）完成，當前一個被“鎖”的線程執行完畢後，有可能在後續的線程隊列裏還沒分配出一個獲取鎖而被“喚醒”的非阻塞線程，即所有線程還都是阻塞狀態時，就被係統調度（進入內核的線程是阻塞的），這樣會導致內核在用戶態和內核態之間來回接換，嚴重影響鎖的性能。在jdk1.6以前主要靠自旋鎖來解決，原理是在前一個線程結束後，爭用線程可以做一個空循環，繼續占有CPU，等待取鎖的機會。當然這樣做顯然也是浪費時間，隻是在兩種浪費中選取浪費少的……
jdk1.6後引入了偏向鎖，當線程第一次獲得了監視對象，之後讓監視對象“偏向”這個線程，之後的多次調用則可以避免CAS操作，等於是置了一臨時變量來記錄位置（類似索引比較）。詳細的就涉及到匯編指令了，我也就沒太深究，偏向鎖性能優於自旋鎖，但是還是沒有達到HotSpot認為的最佳時間（一個線程上下文切換的時間）。
綜合來看對於所有的高並發情況，采用Lock加鎖是最優選擇，但是由於曆史遺留等問題，synchronized也還是不能完全被淘汰，同時，在低並發情況下，synchronized的性能還比Lock好的。
原帖地址：https://wupuyuan.iteye.com/blog/1158655
最後更新：2017-04-03 12:56:05