1、reentrantlock 擁有synchronized相同的併發性和記憶體語義，此外還多了 鎖投票，定時鎖等候和中斷鎖等候
執行緒a和b都要獲取物件o的鎖定，假設a獲取了物件o鎖，b將等待a釋放對o的鎖定，
如果使用 synchronized ，如果a不釋放，b將一直等下去，不能被中斷
如果 使用reentrantlock，如果a不釋放，可以使b在等待了足夠長的時間以後，中斷等待，而幹別的事情
reentrantlock獲取鎖定與三種方式：
a) lock(), 如果獲取了鎖立即返回，如果別的執行緒持有鎖，當前執行緒則一直處於休眠狀態，直到獲取鎖
b) trylock(), 如果獲取了鎖立即返回true，如果別的執行緒正持有鎖，立即返回false；
c)trylock(long timeout,timeunit unit)， 如果獲取了鎖定立即返回true，如果別的執行緒正持有鎖，會等待引數給定的時間，在等待的過程中，如果獲取了鎖定，就返回true，如果等待超時，返回false；
d) lockinterruptibly:如果獲取了鎖定立即返回，如果沒有獲取鎖定，當前執行緒處於休眠狀態，直到或者鎖定，或者當前執行緒被別的執行緒中斷
2、synchronized是在jvm層面上實現的，不但可以通過一些監控工具監控synchronized的鎖定，而且在**執行時出現異常，jvm會自動釋放鎖定，但是使用lock則不行，lock是通過**實現的，要保證鎖定一定會被釋放，就必須將unlock()放到finally{}中
3、在資源競爭不是很激烈的情況下，synchronized的效能要優於reetrantlock，但是在資源競爭很激烈的情況下，synchronized的效能會下降幾十倍，但是reetrantlock的效能能維持常態；
5.0的多執行緒任務包對於同步的效能方面有了很大的改進，在原有synchronized關鍵字的基礎上，又增加了reentrantlock，以及各種atomic類。了解其效能的優劣程度，有助與我們在特定的情形下做出正確的選擇。
總體的結論先擺出來：
synchronized：
在資源競爭不是很激烈的情況下，偶爾會有同步的情形下，synchronized是很合適的。原因在於，編譯程式通常會盡可能的進行優化synchronize，另外可讀性非常好，不管用沒用過5.0多執行緒包的程式設計師都能理解。
reentrantlock:
reentrantlock提供了多樣化的同步，比如有時間限制的同步，可以被interrupt的同步（synchronized的同步是不能interrupt的）等。在資源競爭不激烈的情形下，效能稍微比synchronized差點點。但是當同步非常激烈的時候，synchronized的效能一下子能下降好幾十倍。而reentrantlock確還能維持常態。
Java執行緒同步問題synchronized
android usb 讀寫以前都是一讀一寫，但有些機器會出問題。就採用讀寫非同步的方法。使用物件鎖，object自帶的，然後使用object的方法wait和notify notifyall 使用方法簡單，記錄下 public synchronized int lra setregister int...
Java學習之執行緒鎖 synchronized
同步 併發 多個執行緒訪問同乙份資源 確保資源安全 執行緒安全 synchronized 同步 1 同步塊 synchronized 引用型別 this 類.class 2 同步方法 public synchronized void test public class testsyn class t...
Lock（遞迴函式與死鎖）
看看以下會不會產生死鎖 public class a else class program 你的答案是會產生死鎖嗎？可以理解，因為也許你以前一直以為外層遞迴被鎖住後，不允許在訪問裡邊的 快，而由於遞迴，有需要等待外層遞迴解鎖，所以由此造成死鎖，現在才知道這種理解是錯誤的 結果是永遠不會出現死鎖，因為...