ReentrantLock鎖與內建鎖synchronized
一、內建鎖
使用Syschronized 關鍵字 同步程式碼塊（同步方法）都是使用到物件的內建鎖
1、物件內建鎖
- 使用物件自身的內建鎖(監視器鎖-monitor lock)
- 例項方法-使用例項物件鎖，static 方法 使用Class物件鎖
- 物件內建鎖為互斥鎖，一個同步塊，只有一個執行緒進入
- 同步程式碼塊中的程式碼具有原子性
- 進入程式碼塊內獲取到鎖，無論正常退出or異常都會釋放鎖
2、可重入
- 可重入，表示內建鎖獲取鎖的粒度是執行緒，而不是呼叫
- 同一個執行緒可以重複獲取同一個內建鎖
3、保護狀態
- 內建鎖可以保證原子性操作
- 物件的內建鎖和物件本身的狀態沒有內在關聯關係
- 很多類使用物件內建鎖，單物件的域不一定使用內建鎖保護
- 一個執行緒獲取到物件的內建鎖，其他物件同樣還是可以訪問該物件，只是獲取不了這個物件的鎖
java在設計上每個物件都有一個內建鎖，只是為了免去需要時顯示的建立鎖物件
對於包含多個變數的不變形條件，所有變數使用同一個鎖來保護，可以保證一致性
4、使用
- 儘量縮小同步塊的大小，耗時操作如果不是需要同步的，應該在同步塊外
- 同步程式碼塊如果是耗時的，會帶來活躍性或效能問題
- 無相關性的同步，可以使用多個、或者拆開到多個同步塊中
二、 ReentrantLock 與 synchronized對比
1、相同點
- 具有相同的互斥性和記憶體可見性
- 進入同步塊與獲取ReentrantLock，退出同步塊與釋放ReentrantLock具有相同記憶體語義
- 同樣是可重入
2、區別
- 處理鎖的不可用性問題更加靈活
- 同步塊無法中斷等待的執行緒，無法無限等待
- 必須（自動）程式碼塊後釋放鎖，包括異常，無法實現非阻塞結構的加鎖規則
- ReentrantLocak必須主動釋放鎖，異常不會自動釋放鎖，更加危險（忘記了釋放）
3、鎖的輪詢與定時
內建鎖中，會出現死鎖問題:出現不一致的鎖順序（相互等待），解決的方法只能重啟應用
Lock介面中定義的 tryLock()、tryLock(long timeout,TimeUnit unit)方法，可以實現可輪詢、可定時的獲取鎖操作，
在獲取不到鎖，或超時，可以輪詢重試，或者超時退出獲取請求，這樣可以有效的避免死鎖
4、可中斷鎖
Lock 介面定義的方法 lockInterruptibly()阻塞獲取鎖，能響應執行緒中斷請求，同步程式碼塊則不能響應中斷，只能一直阻塞或者成功獲取到鎖
5、非塊結構加鎖
同步程式碼塊的加鎖、釋放鎖都是基於synchronized同步關鍵字的程式碼塊，自動獲取鎖、釋放鎖，使用簡單，可以避免忘記釋放鎖的程式設計錯誤；
但這樣的加鎖規則不靈活，不能自己控制獲取和釋放
6、鎖的公平性
公平鎖：
執行緒按照獲取鎖的請求順序獲取到鎖，一個執行緒發出獲取鎖時，如果鎖已經由另一執行緒持有或者有其他執行緒在佇列等待獲取鎖，那麼這個新請求的執行緒將放入到佇列中
非公平鎖：
執行緒獲取到鎖的順序與請求鎖的順序不能保證，存線上程直接“插隊”獲取鎖的情況：一個執行緒發出獲取鎖時，如果當前鎖的狀態變為可獲取，那麼這個新請求鎖的執行緒將直接跳過等待佇列並獲取到鎖
非公平鎖比公平鎖提供更好的效能:
公平鎖在掛起執行緒和恢復執行緒時存在的開銷降低了效能，在鎖競爭激烈的情況下，恢復一個被掛起的執行緒與該執行緒真正開始執行存在嚴重的延遲，舉個公平鎖例子：A執行緒持有一個鎖，此時B執行緒請求這個鎖，則B被掛起、放入等待佇列，當A釋放鎖時，B將被喚醒，恢復執行再次嘗試獲取鎖；喚醒B並等待恢復執行是有時間消耗的；
假設A釋放鎖時，執行緒C也請求這個鎖，非公平鎖情況下，C可能會在B喚醒前直接獲得並使用這個鎖，更加充分的使用到了鎖的時間，因此吞吐量會更高
預設ReentrantLock與synchronized內建鎖都是非公平鎖，ReentrantLock也提供了非公平鎖的實現，一般情況下，非公平鎖時可以符合使用要求，java語言規範沒有要求內建鎖要實現公平，ReentrantLock也沒有降低公平性；
三、synchronized與ReentrantLock選擇
ReentrantLock擁有內建鎖沒有的特性：鎖等待（超時，輪詢）、可中斷的鎖等待阻塞、公平性鎖、更加靈活可以實現非塊結構加鎖；
而內建鎖的使用更加簡單明瞭，自動獲取鎖和釋放鎖，比ReentrantLock更加安全，不會因為忘記釋放鎖導致不可知問題；
在效能方法，java6後兩者實際相差不大。當內建鎖不能滿足使用需求是，可以考慮使用ReentrantLock,即還是優先使用內建鎖
以上只是基於對比說明了內建鎖和ReentranLock，沒有具體詳細的例子，如有不對或不能理解，還請評論交流