一、效率低
1，鎖的釋放情況少
當(dāng)一個(gè)線程獲取到對(duì)應(yīng)的Synchronized這把鎖并且正在執(zhí)行的時(shí)候，其他線程如果也想得到這把鎖只能等待，等待當(dāng)前線程去釋放。但是只有兩種情況下鎖會(huì)得到釋放，一個(gè)是該段同步代碼執(zhí)行完畢了，還有一個(gè)是未執(zhí)行完畢但是執(zhí)行的過(guò)程中拋出了異常。如果我們這把鎖由于要等待IO的操作或者其他操作費(fèi)了很長(zhǎng)時(shí)間，但是有沒(méi)有主動(dòng)地區(qū)釋放鎖，其他線程只能等待，這是非常影響程序執(zhí)行效率的。這個(gè)時(shí)候就需要一種機(jī)制，讓這種一直在等待又影響其他線程的情況得到遏制，對(duì)于Lock，它就可以辦到。

2，試圖獲取鎖時(shí)不能設(shè)定超時(shí)
只能干巴巴地等待，無(wú)法設(shè)定超時(shí)后就不做等待。相比之下，Lock可以設(shè)置超時(shí)時(shí)間。

3，不能中斷一個(gè)正在試圖獲取鎖的線程
Lock是有中斷能力的。

二、不夠靈活（讀寫(xiě)鎖更靈活）
1，加鎖和釋放的時(shí)機(jī)單一，不能自己控制加鎖和解鎖的時(shí)機(jī)
加鎖：鎖住某個(gè)對(duì)象，那么這個(gè)對(duì)象就是這把鎖
釋放：釋放這個(gè)對(duì)象，意味著解了這把鎖

2，每一個(gè)鎖僅有單一的條件（某個(gè)對(duì)象），可能是不夠的。
比如我們有一種讀寫(xiě)鎖，它的加鎖釋放鎖的時(shí)機(jī)，非常靈活。它在做讀操作的時(shí)候是不會(huì)加鎖的，而在做寫(xiě)操作的時(shí)候才會(huì)加鎖。這樣就可以大大提高我們的效率又不會(huì)造成線程安全問(wèn)題，因?yàn)樽x的時(shí)候不會(huì)帶來(lái)風(fēng)險(xiǎn)。

所以我們是希望一個(gè)鎖能夠更加靈活的，讓我們能夠去掌控它的加鎖時(shí)機(jī)和釋放時(shí)機(jī)。

三、無(wú)法知道是否成功獲取到鎖
我們用Synchronized對(duì)代碼加鎖，我們沒(méi)有辦法提前知道它是成功了還是失敗了，相比之下，Lock可以去嘗試，如果成功了dosth1，如果沒(méi)有成功dosth2。
Lock interface相關(guān)方法

  public static void main(String[] args) throws InterruptedException {
    Lock lock = new ReentrantLock();
    //可以配置自己的鎖，靈活地控制
    lock.lock();//控制加鎖的時(shí)機(jī)
    lock.unlock();//控制釋放的時(shí)機(jī)

    lock.tryLock();//嘗試獲取這把鎖
    lock.tryLock(10,TimeUnit.SECONDS);//嘗試10s內(nèi)獲取這把鎖，如果過(guò)了時(shí)間還沒(méi)獲取到就放棄

  }