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