1、概述

JUC中locks包下常用的類與接口圖如下：

圖中，Lock和ReadWriteLock是頂層鎖的接口，Lock代表實現類是ReentrantLock（可重入鎖），ReadWriteLock（讀寫鎖）的代表實現類是ReentrantReadWriteLock。

ReadWriteLock 接口以類似方式定義了讀鎖而寫鎖。此包只提供了一個實現，即 ReentrantReadWriteLock。

Condition 接口描述了可能會與鎖有關聯的條件變量。這些變量在用法上與使用 Object.wait 訪問的隱式監視器類似，但提供了更強大的功能。需要特別指出的是，單個 Lock 可能與多個 Condition 對象關聯。

2、lock與synchronized比較

synchronized是java中的一個關鍵字，也就是說是Java語言內置的特性。那么為什么會出現Lock呢？

1、Lock不是Java語言內置的，synchronized是Java語言的關鍵字，因此是內置特性。Lock是一個類，通過這個類可以實現同步訪問；

2、Lock和synchronized有一點非常大的不同，采用synchronized不需要用戶去手動釋放鎖，當synchronized方法或者synchronized代碼塊執行完之后，系統會自動讓線程釋放對鎖的占用；而Lock則必須要用戶去手動釋放鎖，如果沒有主動釋放鎖，就有可能導致出現死鎖現象。

synchronized 的局限性與Lock的優點　

如果一個代碼塊被synchronized關鍵字修飾，當一個線程獲取了對應的鎖，并執行該代碼塊時，其他線程便只能一直等待直至占有鎖的線程釋放鎖。事實上，占有鎖的線程釋放鎖一般會是以下三種情況之一：

1：占有鎖的線程執行完了該代碼塊，然后釋放對鎖的占有；

2：占有鎖線程執行發生異常，此時JVM會讓線程自動釋放鎖；

3：占有鎖線程進入WAITING狀態從而釋放鎖，例如在該線程中調用wait()方法等。

下列三種情況：　

1 、在使用synchronized關鍵字的情形下，假如占有鎖的線程由于要等待IO或者其他原因（比如調用sleep方法）被阻塞了，但是又沒有釋放鎖，那么其他線程就只能一直等待，別無他法。這會極大影響程序執行效率。因此，就需要有一種機制可以不讓等待的線程一直無期限地等待下去（比如只等待一定的時間 (解決方案：tryLock(long time, TimeUnit unit))或者能夠響應中斷(解決方案：lockInterruptibly())），這種情況可以通過 Lock 解決。

2、當多個線程讀寫文件時，讀操作和寫操作會發生沖突現象，寫操作和寫操作也會發生沖突現象，但是讀操作和讀操作不會發生沖突現象。但是如果采用synchronized關鍵字實現同步的話，就會導致一個問題，即當多個線程都只是進行讀操作時，也只有一個線程在可以進行讀操作，其他線程只能等待鎖的釋放而無法進行讀操作。因此，需要一種機制來使得當多個線程都只是進行讀操作時，線程之間不會發生沖突。同樣地，Lock也可以解決這種情況 (解決方案：ReentrantReadWriteLock) 。

3、通過Lock得知線程有沒有成功獲取到鎖 (解決方案：ReentrantLock) ，但這個是synchronized無法辦到的。

上面提到的三種情形，我們都可以通過Lock來解決，但 synchronized 關鍵字卻無能為力。事實上，Lock 是 java.util.concurrent.locks包 下的接口，Lock 實現提供了比 synchronized 關鍵字更廣泛的鎖操作，它能以更優雅的方式處理線程同步問題。也就是說，Lock提供了比synchronized更多的功能。

3、Lock接口實現類的使用

// 獲取鎖 void lock() // 如果當前線程未被中斷，則獲取鎖，可以響應中斷 void lockInterruptibly() // 返回綁定到此 Lock 實例的新 Condition 實例 Condition newCondition() // 僅在調用時鎖為空閑狀態才獲取該鎖，可以響應中斷 boolean tryLock() // 如果鎖在給定的等待時間內空閑，并且當前線程未被中斷，則獲取鎖 boolean tryLock(long time, TimeUnit unit) // 釋放鎖 void unlock()

3.1、在Lock中聲明了四個方法來獲取鎖，那么這四個方法有何區別呢？首先，lock()方法是平常使用得最多的一個方法，就是用來獲取鎖。如果鎖已被其他線程獲取，則進行等待。在前面已經講到，如果采用Lock，必須主動去釋放鎖，并且在發生異常時，不會自動釋放鎖。因此，一般來說，使用Lock必須在try…catch…塊中進行，并且將釋放鎖的操作放在finally塊中進行，以保證鎖一定被被釋放，防止死鎖的發生。通常使用Lock來進行同步的話，是以下面這種形式去使用的：

Lock lock = ...;lock.lock();try{ //處理任務}catch(Exception ex){}finally{ lock.unlock(); //釋放鎖}

3.2、tryLock() & tryLock(long time, TimeUnit unit)

tryLock()方法是有返回值的，它表示用來嘗試獲取鎖，如果獲取成功，則返回true；如果獲取失敗（即鎖已被其他線程獲取），則返回false，也就是說，這個方法無論如何都會立即返回（在拿不到鎖時不會一直在那等待）。

tryLock(long time, TimeUnit unit)方法和tryLock()方法是類似的，只不過區別在于這個方法在拿不到鎖時會等待一定的時間，在時間期限之內如果還拿不到鎖，就返回false，同時可以響應中斷。如果一開始拿到鎖或者在等待期間內拿到了鎖，則返回true。

一般情況下，通過tryLock來獲取鎖時是這樣使用的：

Lock lock = ...;if(lock.tryLock()) { try{ //處理任務 }catch(Exception ex){ }finally{ lock.unlock(); //釋放鎖 }}else { //如果不能獲取鎖，則直接做其他事情}

3.3、lockInterruptibly()　lockInterruptibly()方法比較特殊，當通過這個方法去獲取鎖時，如果線程 正在等待獲取鎖，則這個線程能夠響應中斷，即中斷線程的等待狀態。例如，當兩個線程同時通過lock.lockInterruptibly()想獲取某個鎖時，假若此時線程A獲取到了鎖，而線程B只有在等待，那么對線程B調用threadB.interrupt()方法能夠中斷線程B的等待過程。

由于lockInterruptibly()的聲明中拋出了異常，所以lock.lockInterruptibly()必須放在try塊中或者在調用lockInterruptibly()的方法外聲明拋出 InterruptedException，但推薦使用后者，原因稍后闡述。因此，lockInterruptibly()一般的使用形式如下：

public void method() throws InterruptedException { lock.lockInterruptibly(); try { //..... } finally { lock.unlock(); } }

注意，當一個線程獲取了鎖之后，是不會被interrupt()方法中斷的。因為interrupt()方法只能中斷阻塞過程中的線程而不能中斷正在運行過程中的線程。因此，當通過lockInterruptibly()方法獲取某個鎖時，如果不能獲取到，那么只有進行等待的情況下，才可以響應中斷的。與 synchronized 相比，當一個線程處于等待某個鎖的狀態，是無法被中斷的，只有一直等待下去。范例，運行起來后，Thread2能夠被正確中斷。

public class Test { private Lock lock = new ReentrantLock(); public static void main(String[] args) { Test test = new Test(); MyThread thread1 = new MyThread(test); MyThread thread2 = new MyThread(test); thread1.start(); thread2.start(); try { Thread.sleep(2000); } catch (InterruptedException e) { e.printStackTrace(); } thread2.interrupt(); } public void insert(Thread thread) throws InterruptedException{ lock.lockInterruptibly(); //注意，如果需要正確中斷等待鎖的線程，必須將獲取鎖放在外面，然后將InterruptedException拋出 try { System.out.println(thread.getName()+'得到了鎖'); long startTime = System.currentTimeMillis(); for( ; ;) {if(System.currentTimeMillis() - startTime >= Integer.MAX_VALUE) break;//插入數據 } } finally { System.out.println(Thread.currentThread().getName()+'執行finally'); lock.unlock(); System.out.println(thread.getName()+'釋放了鎖'); } }}class MyThread extends Thread { private Test test = null; public MyThread(Test test) { this.test = test; } @Override public void run() { try { test.insert(Thread.currentThread()); } catch (InterruptedException e) { System.out.println(Thread.currentThread().getName()+'被中斷'); } }}

3.4 具體的鎖實現

Lock的實現類

ReentrantLock ：即 可重入鎖。ReentrantLock是唯一實現了Lock接口的類，并且ReentrantLock提供了更多的方法。

ReadWriteLock鎖：接口只有兩個方法：

//返回用于讀取操作的鎖 Lock readLock() //返回用于寫入操作的鎖 Lock writeLock()

ReadWriteLock維護了一對相關的鎖，一個用于只讀操作，另一個用于寫入操作。范例

class ReadWriteLockQueue { //共享數據，只能有一個線程 寫數據，但可以多個線程讀數據 private Object data = null; private ReentrantReadWriteLock rwl = new ReentrantReadWriteLock(); //讀數據 public void get() { try { rwl.readLock().lock();//上讀鎖，其他線程只能讀。 System.out.print(Thread.currentThread().getName() + '讀取 data！'); Thread.sleep((long) (Math.random() * 1000));System.out.println(Thread.currentThread().getName() + '讀取到的數據：'+ data); } catch (Exception e) { e.printStackTrace(); } finally { rwl.readLock().unlock();//釋放讀鎖 } } //寫數據 public void put(Object data) { try { rwl.writeLock().lock();//加上寫鎖，不允許其他線程 讀寫 System.out.print(Thread.currentThread().getName() + '寫入數據,'); Thread.sleep((long) (Math.random() * 1000)); this.data = data; System.out.println(Thread.currentThread().getName() + '已經寫好數據' + data); } catch (Exception e) { e.printStackTrace(); } finally { rwl.writeLock().unlock();//釋放鎖 } }}public class TestReentrantReadWriteLock { public static void main(String[] args) { final ReadWriteLockQueue readWriteLockQueue = new ReadWriteLockQueue(); for (int i = 0; i < 2 ; i++) { new Thread(new Runnable() {@Overridepublic void run() { while (true) { readWriteLockQueue.put(new Random().nextInt(10000)); }} },'寫線程').start(); new Thread(new Runnable() {@Overridepublic void run() { while(true) { readWriteLockQueue.get(); }} },'讀線程').start(); } }}

4、鎖的相關概念

可重入鎖 ： 如果鎖具備可重入性，則稱作為 可重入鎖 。像 synchronized和ReentrantLock都是可重入鎖，可重入性在我看來實際上表明了 鎖的分配機制：基于線程的分配，而不是基于方法調用的分配。舉個簡單的例子，當一個線程執行到某個synchronized方法時，比如說method1，而在method1中會調用另外一個synchronized方法method2，此時線程不必重新去申請鎖，而是可以直接執行方法method2。 可中斷鎖：顧名思義，可中斷鎖就是可以響應中斷的鎖。在Java中，synchronized就不是可中斷鎖，而Lock是可中斷鎖。如果某一線程A正在執行鎖中的代碼，另一線程B正在等待獲取該鎖，可能由于等待時間過長，線程B不想等待了，想先處理其他事情，我們可以讓它中斷自己或者在別的線程中中斷它，這種就是可中斷鎖。在前面演示tryLock(long time, TimeUnit unit)和lockInterruptibly()的用法時已經體現了Lock的可中斷性。 公平鎖：公平鎖即盡量以請求鎖的順序來獲取鎖。比如，同是有多個線程在等待一個鎖，當這個鎖被釋放時，等待時間最久的線程（最先請求的線程）會獲得該所，這種就是公平鎖。而非公平鎖則無法保證鎖的獲取是按照請求鎖的順序進行的，這樣就可能導致某個或者一些線程永遠獲取不到鎖。在Java中，synchronized就是非公平鎖，它無法保證等待的線程獲取鎖的順序。而對于ReentrantLock 和 ReentrantReadWriteLock，它默認情況下是非公平鎖，但是可以設置為公平鎖。 樂觀鎖：總是假設最好的情況，每次去拿數據的時候都認為別人不會修改，所以不會上鎖，但是在更新的時候會判斷一下在此期間別人有沒有去更新這個數據，可以使用版本號機制和CAS算法實現。樂觀鎖適用于多讀的應用類型，這樣可以提高吞吐量，像數據庫提供的類似于write_condition機制，其實都是提供的樂觀鎖。在Java中java.util.concurrent.atomic包下面的原子變量類就是使用了樂觀鎖的一種實現方式CAS實現的。

鎖主要存在四中狀態，依次是：無鎖狀態、偏向鎖狀態、輕量級鎖狀態、重量級鎖狀態，他們會隨著競爭的激烈而逐漸升級。注意鎖可以升級不可降級，這種策略是為了提高獲得鎖和釋放鎖的效率。

4.1、偏向鎖

引入偏向鎖的目的和引入輕量級鎖的目的很像，他們都是為了沒有多線程競爭的前提下，減少傳統的重量級鎖使用操作系統互斥量產生的性能消耗。但是不同是：輕量級鎖在無競爭的情況下使用 CAS （Compare and Swap）操作去代替使用互斥量。而偏向鎖在無競爭的情況下會把整個同步都消除掉。

偏向鎖的“偏”就是偏心的偏，它的意思是會偏向于第一個獲得它的線程，如果在接下來的執行中，該鎖沒有被其他線程獲取，那么持有偏向鎖的線程就不需要進行同步！關于偏向鎖的原理可以查看《深入理解Java虛擬機：JVM高級特性與最佳實踐》第二版的13章第三節鎖優化。

但是對于鎖競爭比較激烈的場合，偏向鎖就失效了，因為這樣場合極有可能每次申請鎖的線程都是不相同的，因此這種場合下不應該使用偏向鎖，否則會得不償失，需要注意的是，偏向鎖失敗后，并不會立即膨脹為重量級鎖，而是先升級為輕量級鎖。

4.2、 輕量級鎖

倘若偏向鎖失敗，虛擬機并不會立即升級為重量級鎖，它還會嘗試使用一種稱為輕量級鎖的優化手段(1.6之后加入的)。輕量級鎖不是為了代替重量級鎖，它的本意是在沒有多線程競爭的前提下，減少傳統的重量級鎖使用操作系統互斥量產生的性能消耗，因為使用輕量級鎖時，不需要申請互斥量。另外，輕量級鎖的加鎖和解鎖都用到了CAS操作。 關于輕量級鎖的加鎖和解鎖的原理可以查看

《深入理解Java虛擬機：JVM高級特性與最佳實踐》第二版的13章第三節鎖優化。輕量級鎖能夠提升程序同步性能的依據是“對于絕大部分鎖，在整個同步周期內都是不存在競爭的”，這是一個經驗數據。如果沒有競爭，輕量級鎖使用 CAS 操作避免了使用互斥操作的開銷。但如果存在鎖競爭，除了互斥量開銷外，還會額外發生CAS操作，因此在有鎖競爭的情況下，輕量級鎖比傳統的重量級鎖更慢！如果鎖競爭激烈，那么輕量級將很快膨脹為重量級鎖！

4.3、自旋鎖和自適應自旋鎖

輕量級鎖失敗后，虛擬機為了避免線程真實地在操作系統層面掛起，還會進行一項稱為自旋鎖的優化手段。互斥同步對性能最大的影響就是阻塞的實現，因為掛起線程/恢復線程的操作都需要轉入內核態中完成（用戶態轉換到內核態會耗費時間）。

一般線程持有鎖的時間都不是太長，所以僅僅為了這一點時間去掛起線程/恢復線程是得不償失的。 所以，虛擬機的開發團隊就這樣去考慮：“我們能不能讓后面來的請求獲取鎖的線程等待一會而不被掛起呢？看看持有鎖的線程是否很快就會釋放鎖”。為了讓一個線程等待，我們只需要讓線程執行一個忙循環（自旋），這項技術就叫做自旋。何謂自旋鎖？它是為實現保護共享資源而提出一種鎖機制。其實，自旋鎖與互斥鎖比較類似，它們都是為了解決對某項資源的互斥使用。無論是互斥鎖，還是自旋鎖，在任何時刻，最多只能有一個保持者，也就說，在任何時刻最多只能有一個執行單元獲得鎖。但是兩者在調度機制上略有不同。對于互斥鎖，如果資源已經被占用，資源申請者只能進入睡眠狀態。但是自旋鎖不會引起調用者睡眠，如果自旋鎖已經被別的執行單元保持，調用者就一直循環在那里看是否該自旋鎖的保持者已經釋放了鎖，'自旋'一詞就是因此而得名。

JDK1.6及1.6之后，自旋鎖就改為默認開啟的了。需要注意的是：自旋等待不能完全替代阻塞，因為它還是要占用處理器時間。如果鎖被占用的時間短，那么效果當然就很好了！反之，相反！自旋等待的時間必須要有限度。如果自旋超過了限定次數任然沒有獲得鎖，就應該掛起線程。自旋次數的默認值是10次，但是用戶可以修改。在 JDK1.6 中引入了自適應的自旋鎖。自適應的自旋鎖帶來的改進就是：自旋的時間不在固定了，而是和前一次同一個鎖上的自旋時間以及鎖的擁有者的狀態來決定，虛擬機變得越來越“聰明”了。

4.4、鎖消除

鎖消除理解起來很簡單，它指的就是虛擬機即使編譯器在運行時，如果檢測到那些共享數據不可能存在競爭，那么就執行鎖消除。鎖消除可以節省毫無意義的請求鎖的時間。

4.5、鎖粗化

原則上在編寫代碼的時候，總是推薦將同步快的作用范圍限制得盡量小——只在共享數據的實際作用域才進行同步，這樣是為了使得需要同步的操作數量盡可能變小，如果存在鎖競爭，那等待線程也能盡快拿到鎖。

以上就是本文的全部內容，希望對大家的學習有所幫助，也希望大家多多支持好吧啦網。