一、內置鎖
使用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，沒有具體詳細的例子，如有不對或不能理解，還請評論交流