為什麼java已經通過synchronized關鍵字實現同步訪問了，還需要提供Lock？

synchronized的缺陷

前面部落格有提到過釋放物件的鎖有兩種情況：

• 程式執行完同步程式碼塊會釋放程式碼塊。
• 程式在執行同步程式碼塊是出現異常，JVM會自動釋放鎖去處理異常。

如果獲取鎖的執行緒需要等待I/O或者呼叫了sleep()方法被阻塞了，但仍持有鎖，其他執行緒只能乾巴巴的等著，這樣就會很影響程式效率。
因此就需要一種機制，可以不讓等待的執行緒已知等待下去，比如值等待一段時間或響應中斷，Lock鎖就可以辦到。

再舉個例子：當有多個執行緒讀寫檔案時，讀操作和寫操作會發生衝突現象，寫操作和寫操作會發生衝突現象，但是讀操作和讀操作不會發生衝突現象。但是採用synchronized關鍵字來實現同步的話，就會導致一個問題：如果多個執行緒都只是進行讀操作，所以當一個執行緒在進行讀操作時，其他執行緒只能等待無法進行讀操作。
因此就需要一種機制來使得多個執行緒都只是進行讀操作時，執行緒之間不會發生衝突，通過Lock就可以辦到。
另外，Lock可以知道執行緒有沒有得到鎖，而synchronized不能。

總結區別

總結來說，Lock與synchronized有以下區別：

1. Lock是一個介面，而synchronized是關鍵字。
2. synchronized會自動釋放鎖，而Lock必須手動釋放鎖。
3. Lock可以讓等待鎖的執行緒響應中斷，而synchronized不會，執行緒會一直等待下去。
4. 通過Lock可以知道執行緒有沒有拿到鎖，而synchronized不能。
5. Lock能提高多個執行緒讀操作的效率。
6. synchronized能鎖住類、方法和程式碼塊，而Lock是塊範圍內的