### 用法比較 * Lock使用起來比較靈活，但是必須有釋放鎖的配合動作 * Lock必須手動獲取與釋放鎖，而synchronized不需要手動釋放和開啟鎖 * Lock只適用于代碼塊鎖，而synchronized可用于修飾方法、代碼塊等? ### 特性比較 ReentrantLock的優勢體現在： * 具備嘗試非阻塞地獲取鎖的特性：當前線程嘗試獲取鎖，如果這一時刻鎖沒有被其他線程獲取到，則成功獲取并持有鎖 * 能被中斷地獲取鎖的特性：與synchronized不同，獲取到鎖的線程能夠響應中斷，當獲取到鎖的線程被中斷時，中斷異常將會被拋出，同時鎖會被釋放 * 超時獲取鎖的特性：在指定的時間范圍內獲取鎖；如果截止時間到了仍然無法獲取鎖，則返回 推薦在synchronized與ReentrantLock都可滿足需要時優先使用synchronized： * synchronized是在Java語法層面的同步，足夠清晰，也足夠簡單。每個Java程序員都熟悉 synchronized，但J.U.C中的Lock接口則并非如此。因此在只需要基礎的同步功能時，更推薦synchronized； * Lock應該確保在finally塊中釋放鎖，否則一旦受同步保護的代碼塊中拋出異常，則有可能永遠不會釋放持有的鎖。這一點必須由程序員自己來保證，而使用synchronized的話則可以由Java虛擬機來確保即使出現異常，鎖也能被自動釋放； * 盡管在JDK 5時代ReentrantLock曾經在性能上領先過synchronized，但這已經是十多年之前的勝利 了。從長遠來看，Java虛擬機更容易針對synchronized來進行優化，因為Java虛擬機可以在線程和對象的元數據中記錄synchronized中鎖的相關信息，而使用J.U.C中的Lock的話，Java虛擬機是很難得知具體 哪些鎖對象是由特定線程鎖持有的； * ReentrantLock是Lock的實現類，是一個互斥的同步器，在多線程高競爭條件下，ReentrantLock比synchronized有更加優異的性能表現 ### ReentrantLock vs synchronized