JDK1.5中，synchronized是性能低效的。因為這是一個重量級操作，它對性能最大的影響是阻塞的是實現，掛起線程和恢復線程的操作都需要轉入內核態中完成，這些操作給系統的並發性帶來了很大的壓力。相比之下使用Java提供的Lock對象，性能更高一些。多線程環境下，synchronized的吞吐量下降的非常嚴重，而ReentrankLock則能基本保持在同一個比較穩定的水平上。到了JDK1.6，發生了變化，對synchronize加入了很多優化措施，有自適應自旋，鎖消除，鎖粗化，輕量級鎖，偏向鎖等等。導致在JDK1.6上synchronize的性能並不比Lock差。官方也表示，他們也更支持synchronize，在未來的版本中還有優化余地，所以還是提倡在synchronized能實現需求的情況下，優先考慮使用synchronized來進行同步。
內置鎖
// synchronized關鍵字用法示例
public synchronized void add(int t){// 同步方法
this.v += t;
}
public static synchronized void sub(int t){// 同步靜態方法
value -= t;
}
public int decrementAndGet(){
synchronized(obj){// 同步代碼塊
return --v;
}
}
這就是內置鎖的全部用法，你已經學會了。內置鎖使用起來非常方便，不需要顯式的獲取和釋放，任何一個對象都能作為一把內置鎖。使用內置鎖能夠解決大部分的同步場景。“任何一個對象都能作為一把內置鎖”也意味着出現synchronized關鍵字的地方，都有一個對象與之關聯，具體說來：
1）當synchronized作用於普通方法是，鎖對象是this；
2）當synchronized作用於靜態方法是，鎖對象是當前類的Class對象；
3）當synchronized作用於代碼塊時，鎖對象是synchronized(obj)中的這個obj。
顯式鎖
內置鎖這么好用，為什么還需多出一個顯式鎖呢？因為有些事情內置鎖是做不了的，
比如：我們想給鎖加個等待時間超時時間，超時還未獲得鎖就放棄，不至於無限等下去；
我們想以可中斷的方式獲取鎖，這樣外部線程給我們發一個中斷信號就能喚起等待鎖的線程；
我們想為鎖維持多個等待隊列，比如一個生產者隊列，一個消費者隊列，一邊提高鎖的效率。
顯式鎖(ReentrantLock)正式為了解決這些靈活需求而生。ReentrantLock的字面意思是可重入鎖，可重入的意思是線程可以同時多次請求同一把鎖，而不會自己導致自己死鎖。
內置鎖和顯式鎖的區別
可定時：RenentrantLock.tryLock(long timeout, TimeUnit unit)提供了一種以定時結束等待的方式，如果線程在指定的時間內沒有獲得鎖，該方法就會返回false並結束線程等待。
可中斷：你一定見過InterruptedException，很多跟多線程相關的方法會拋出該異常，這個異常並不是一個缺陷導致的負擔，而是一種必須，或者說是一件好事。可中斷性給我們提供了一種讓線程提前結束的方式（而不是非得等到線程執行結束），這對於要取消耗時的任務非常有用。對於內置鎖，線程拿不到內置鎖就會一直等待，除了獲取鎖沒有其他辦法能夠讓其結束等待。RenentrantLock.lockInterruptibly()給我們提供了一種以中斷結束等待的方式。
條件隊列(condition queue)：線程在獲取鎖之后，可能會由於等待某個條件發生而進入等待狀態（內置鎖通過Object.wait()方法，顯式鎖通過Condition.await()方法），進入等待狀態的線程會掛起並自動釋放鎖，這些線程會被放入到條件隊列當中。synchronized對應的只有一個條件隊列，而ReentrantLock可以有多個條件隊列，多個隊列有什么好處呢？請往下看。
條件謂詞：線程在獲取鎖之后，有時候還需要等待某個條件滿足才能做事情，比如生產者需要等到“緩存不滿”才能往隊列里放入消息，而消費者需要等到“緩存非空”才能從隊列里取出消息。這些條件被稱作條件謂詞，線程需要先獲取鎖，然后判斷條件謂詞是否滿足，如果不滿足就不往下執行，相應的線程就會放棄執行權並自動釋放鎖。使用同一把鎖的不同的線程可能有不同的條件謂詞，如果只有一個條件隊列，當某個條件謂詞滿足時就無法判斷該喚醒條件隊列里的哪一個線程；但是如果每個條件謂詞都有一個單獨的條件隊列，當某個條件滿足時我們就知道應該喚醒對應隊列上的線程（內置鎖通過Object.notify()或者Object.notifyAll()方法喚醒，顯式鎖通過Condition.signal()或者Condition.signalAll()方法喚醒）。這就是多個條件隊列的好處。
使用內置鎖時，對象本身既是一把鎖又是一個條件隊列；使用顯式鎖時，RenentrantLock的對象是鎖，條件隊列通過RenentrantLock.newCondition()方法獲取，多次調用該方法可以得到多個條件隊列。
一個使用顯式鎖的典型示例如下：
// 顯式鎖的使用示例
ReentrantLock lock = new ReentrantLock();
// 獲取鎖，這是跟synchronized關鍵字對應的用法。
lock.lock();
try{
// your code
}finally{
lock.unlock();
}
// 可定時，超過指定時間為得到鎖就放棄
try {
lock.tryLock(10, TimeUnit.SECONDS);
try {
// your code
}finally {
lock.unlock();
}
} catch (InterruptedException e1) {
// exception handling
}
// 可中斷，等待獲取鎖的過程中線程線程可被中斷
try {
lock.lockInterruptibly();
try {
// your code
}finally {
lock.unlock();
}
} catch (InterruptedException e) {
// exception handling
}
// 多個等待隊列，具體參考[ArrayBlockingQueue](https://github.com/CarpenterLee/JCRecipes/blob/master/markdown/ArrayBlockingQueue.md)
/** Condition for waiting takes */
private final Condition notEmpty = lock.newCondition();
/** Condition for waiting puts */
private final Condition notFull = lock.newCondition();
注意，上述代碼將unlock()放在finally塊里，這么做是必需的。顯式鎖不像內置鎖那樣會自動釋放，使用顯式鎖一定要在finally塊中手動釋放，如果獲取鎖后由於異常的原因沒有釋放鎖，那么這把鎖將永遠得不到釋放！將unlock()放在finally塊中，保證無論發生什么都能夠正常釋放。
結論
內置鎖能夠解決大部分需要同步的場景，只有在需要額外靈活性是才需要考慮顯式鎖，比如可定時、可中斷、多等待隊列等特性。
顯式鎖雖然靈活，但是需要顯式的申請和釋放，並且釋放一定要放到finally塊中，否則可能會因為異常導致鎖永遠無法釋放！這是顯式鎖最明顯的缺點。
綜上，當需要同步時請優先考慮更安全的更易用的隱式鎖。
底層實現
1.互斥同步最主要的問題就是進行線程阻塞和喚醒所帶來的性能問題，因而這種同步又稱為阻塞同步，它屬於一種悲觀的並發策略，即線程獲得的是獨占鎖。獨占鎖意味着其他線程只能依靠阻塞來等待線程釋放鎖。而在CPU轉換線程阻塞時會引起線程上下文切換，當有很多線程競爭鎖的時候，會引起CPU頻繁的上下文切換導致效率很低。synchronized采用的便是這種並發策略。
2.隨着指令集的發展，我們有了另一種選擇：基於沖突檢測的樂觀並發策略，通俗地講就是先進性操作，如果沒有其他線程爭用共享數據，那操作就成功了，如果共享數據被爭用，產生了沖突，那就再進行其他的補償措施（最常見的補償措施就是不斷地重試，直到試成功為止），這種樂觀的並發策略的許多實現都不需要把線程掛起，因此這種同步被稱為非阻塞同步。ReetrantLock采用的便是這種並發策略。
3.在樂觀的並發策略中，需要操作和沖突檢測這兩個步驟具備原子性，它靠硬件指令來保證，這里用的是CAS操作（Compare and Swap）。JDK1.5之后，Java程序才可以使用CAS操作。我們可以進一步研究ReentrantLock的源代碼，會發現其中比較重要的獲得鎖的一個方法是compareAndSetState，這里其實就是調用的CPU提供的特殊指令。現代的CPU提供了指令，可以自動更新共享數據，而且能夠檢測到其他線程的干擾，而compareAndSet() 就用這些代替了鎖定。這個算法稱作非阻塞算法，意思是一個線程的失敗或者掛起不應該影響其他線程的失敗或掛起。
Java 5中引入了注入AtomicInteger、AtomicLong、AtomicReference等特殊的原子性變量類，它們提供的如：compareAndSet（）、incrementAndSet（）和getAndIncrement（）等方法都使用了CAS操作。因此，它們都是由硬件指令來保證的原子方法。
用途比較
基本語法上，ReentrantLock與synchronized很相似，它們都具備一樣的線程重入特性，只是代碼寫法上有點區別而已，一個表現為API層面的互斥鎖（Lock），一個表現為原生語法（JVM）層面的互斥鎖（synchronized）。ReentrantLock相對synchronized而言還是增加了一些高級功能，主要有以下三項：
1、等待可中斷：當持有鎖的線程長期不釋放鎖時，正在等待的線程可以選擇放棄等待，改為處理其他事情，它對處理執行時間非常上的同步塊很有幫助。而在等待由synchronized產生的互斥鎖時，會一直阻塞，是不能被中斷的。
2、可實現公平鎖：多個線程在等待同一個鎖時，必須按照申請鎖的時間順序排隊等待，而非公平鎖則不保證這點，在鎖釋放時，任何一個等待鎖的線程都有機會獲得鎖。synchronized中的鎖是非公平鎖，ReentrantLock默認情況下也是非公平鎖，但可以通過構造方法ReentrantLock（ture）來要求使用公平鎖。
3、鎖可以綁定多個條件：ReentrantLock對象可以同時綁定多個Condition對象（名曰：條件變量或條件隊列），而在synchronized中，鎖對象的wait() 和notify() 或notifyAll()方法可以實現一個隱含條件，但如果要和多於一個的條件關聯的時候，就不得不額外地添加一個鎖，而ReentrantLock則無需這么做，只需要多次調用newCondition() 方法即可。而且我們還可以通過綁定Condition對象來判斷當前線程通知的是哪些線程（即與Condition對象綁定在一起的其他線程）。