Java常用鎖機制簡介

　　在開發Java多線程應用程序中，各個線程之間由於要共享資源，必須用到鎖機制。Java提供了多種多線程鎖機制的實現方式，常見的有synchronized、ReentrantLock、Semaphore、AtomicInteger等。每種機制都有優缺點與各自的適用場景，必須熟練掌握他們的特點才能在Java多線程應用開發時得心應手。

　　更多Java鎖機制的詳細介紹參見文檔《Java鎖機制詳解》。

一、synchronized

　　幾乎每一個Java開發人員都認識synchronized，使用它來實現多線程的同步操作是非常簡單的，只要在需要同步的對方的方法、類或代碼塊中加入該關鍵字，它能夠保證在同一個時刻最多只有一個線程執行同一個對象的同步代碼，可保證修飾的代碼在執行過程中不會被其他線程干擾。使用synchronized修飾的代碼具有原子性和可見性，在需要進程同步的程序中使用的頻率非常高，可以滿足一般的進程同步要求（詳見《Java多線程基礎》）。

　　synchronized實現的機理依賴於軟件層面上的JVM，因此其性能會隨着Java版本的不斷升級而提高。事實上，在Java1.5中，synchronized是一個重量級操作，需要調用操作系統相關接口，性能是低效的，有可能給線程加鎖消耗的時間比有用操作消耗的時間更多。到了Java1.6，synchronized進行了很多的優化，有適應自旋、鎖消除、鎖粗化、輕量級鎖及偏向鎖等，效率有了本質上的提高。在之后推出的Java1.7與1.8中，均對該關鍵字的實現機理做了優化。

　　需要說明的是，當線程通過synchronized等待鎖時是不能被Thread.interrupt()中斷的，因此程序設計時必須檢查確保合理，否則可能會造成線程死鎖的尷尬境地。

　　最后，盡管Java實現的鎖機制有很多種，並且有些鎖機制性能也比synchronized高，但還是強烈推薦在多線程應用程序中使用該關鍵字，因為實現方便，后續工作由JVM來完成，可靠性高。只有在確定鎖機制是當前多線程程序的性能瓶頸時，才考慮使用其他機制，如ReentrantLock等。

二、ReentrantLock

　　可重入鎖，顧名思義，這個鎖可以被線程多次重復進入進行獲取操作。ReentantLock繼承接口Lock並實現了接口中定義的方法，除了能完成synchronized所能完成的所有工作外，還提供了諸如可響應中斷鎖、可輪詢鎖請求、定時鎖等避免多線程死鎖的方法。

　　Lock實現的機理依賴於特殊的CPU指定，可以認為不受JVM的約束，並可以通過其他語言平台來完成底層的實現。在並發量較小的多線程應用程序中，ReentrantLock與synchronized性能相差無幾，但在高並發量的條件下，synchronized性能會迅速下降幾十倍，而ReentrantLock的性能卻能依然維持一個水准，因此我們建議在高並發量情況下使用ReentrantLock。

　　ReentrantLock引入兩個概念：公平鎖與非公平鎖。公平鎖指的是鎖的分配機制是公平的，通常先對鎖提出獲取請求的線程會先被分配到鎖。反之，JVM按隨機、就近原則分配鎖的機制則稱為不公平鎖。ReentrantLock在構造函數中提供了是否公平鎖的初始化方式，默認為非公平鎖。這是因為，非公平鎖實際執行的效率要遠遠超出公平鎖，除非程序有特殊需要，否則最常用非公平鎖的分配機制。

　　ReentrantLock通過方法lock()與unlock()來進行加鎖與解鎖操作，與synchronized會被JVM自動解鎖機制不同，ReentrantLock加鎖后需要手動進行解鎖。為了避免程序出現異常而無法正常解鎖的情況，使用ReentrantLock必須在finally控制塊中進行解鎖操作。通常使用方式如下所示：

Lock lock = new ReentrantLock();
try {
    lock.lock();
    //...進行任務操作
} finally {
    lock.unlock();
}

　　下面我們詳細介紹有關ReentrantLock提供的可響應中斷鎖、可輪詢鎖請求、定時鎖等機制與操作方式。

　　1、線程在等待資源過程中需要中斷

　　ReentrantLock的在獲取鎖的過程中有2種鎖機制，忽略中斷鎖和響應中斷鎖。當等待線程A或其他線程嘗試中斷線程A時，忽略中斷鎖機制則不會接收中斷，而是繼續處於等待狀態；響應中斷鎖則會處理這個中斷請求，並將線程A由阻塞狀態喚醒為就緒狀態，不再請求和等待資源。

　　lock.lock()可設置鎖機制為忽略中斷鎖，lock.lockInterruptibly()可設置鎖機制為響應中斷鎖。下述例子描述了，一個寫線程和一個讀線程分別操作同一個同一個對象的寫方法和讀方法，寫方法需要執行10秒時間，主線程中在啟動寫線程writer和讀線程reader后，啟動了第三個線程，這個線程判斷當程序執行5秒后，如果讀線程依然處於等待狀態，就將他中斷，不再繼續等待資源。

import java.util.concurrent.locks.ReentrantLock;

public class ReentrantLockInterrupt {
    public static void main(String[] args) {
        MyBuffer buffer = new MyBuffer();
        
        //開啟寫線程
        final WriteThread write = new WriteThread(buffer);
        write.start();
        
        //開啟讀線程
        final ReadThread read = new ReadThread(buffer);
        read.start();
        
        //開啟第三個線程，用於監聽並中斷讀線程
        new Thread(new Runnable() {
            @Override
            public void run() {
                long readThreadMaxWaitTime = 5000;  //讀線程最大等待時間，單位：毫秒
                long startTime = System.currentTimeMillis();
                while(System.currentTimeMillis()-startTime<readThreadMaxWaitTime){}
                System.out.println("讀線程等待時間已超過"+readThreadMaxWaitTime/1000+"秒，請求中斷....");
                read.interrupt();
            }
        }).start();
    }
}

class WriteThread extends Thread{
    private MyBuffer buffer;
    public WriteThread(MyBuffer buffer){
        this.buffer = buffer;
    }
    @Override
    public void run() {
        buffer.write();
    }
}

class ReadThread extends Thread{
    private MyBuffer buffer;
    public ReadThread(MyBuffer buffer) {
        this.buffer = buffer;
    }
    @Override
    public void run() {
        try {
            buffer.read();
        } catch (InterruptedException e) {
            System.out.println("讀線程已經被中斷.....");
        }
    }
}

class MyBuffer {
    //使用ReentrantLock鎖
    private ReentrantLock lock = new ReentrantLock();
    
    //寫操作
    public void write(){
        //lock操作必須放在此處，放於try內就會報錯，為什么？？？
        lock.lock();
        try {
            long writeNeedTime = 10000;  //寫操作需要時間，單位：毫秒
            long writeStartTime = System.currentTimeMillis();
            System.out.println("寫操作開始，預計執行時間："+writeNeedTime/1000+"秒....");
            while(System.currentTimeMillis()-writeStartTime<writeNeedTime){}
            System.out.println("寫操作完成....");
        } finally {
            lock.unlock();
        }
    }
    
    //讀操作
    public void read() throws InterruptedException {
        //lock()方法設置鎖機制為“忽略中斷鎖”，當調用此方法的線程自身或被其他線程請求中斷(interrupt)時，操作線程不響應請求，繼續處於等待狀態
        //lockInterruptibly()方法可設置鎖機制為“相應式中斷鎖”，當調用此方法的線程自身或被其他線程請求中斷(interrupt)時，線程會相應請求，並在調用當前方法的操作時中斷線程，中斷后不操作線程后續任務
        //以上的響應指的是線程正在獲取鎖的過程中被請求中斷，若線程在其他非阻塞與阻塞狀態時被請求中斷，lockInterruptibly()是無法響應中斷的，
        //非阻塞狀態可根據中斷標記位Thread.currentThread().isInterrupted()，阻塞狀態可通過拋出異常InterruptedException來中斷線程
        //詳細可以參考http://www.cnblogs.com/hanganglin/articles/3517178.html中的Thread.interrupt資料
        lock.lockInterruptibly();
        try {
            System.out.println("讀操作完成....");
        } finally {
            lock.unlock();
        }
    }
}

　　由例子可知，ReentrantLock.lockInterruptibly()方法可設置線程在獲取鎖的時候響應其他線程對當前線程發出的中斷請求。但必須注意，此處響應中斷鎖是指正在獲取鎖的過程中，如果線程此時並非處於獲取鎖的狀態，通過此方法設置是無法中斷線程的，非阻塞狀態可根據中斷標記位Thread.currentThread().isInterrupted()在程序中手動設置中斷，阻塞狀態可通過拋出異常InterruptedException來中斷線程，詳細可參考博文《Java多線程基礎》。

　　2、實現可輪詢的鎖請求

　　在synchronized中，一旦發生死鎖，唯一能夠恢復的辦法只能重新啟動程序，唯一的預防方法是在設計程序時考慮完善不要出錯。而有了Lock以后，死鎖問題就有了新的預防辦法，它提供了tryLock()輪詢方法來獲得鎖，如果鎖可用則獲取鎖，如果鎖不可用，則此方法返回false，並不會為了等待鎖而阻塞線程，這極大地降低了死鎖情況的發生。典型使用語句如下：

Lock lock = ...;
if(lock.tryLock()){
    //鎖可用，則成功獲取鎖
    try {
        //獲取鎖后進行處理
    } finally {
        lock.unlock();
    }
} else {
    //鎖不可用，其他處理方法
}

　　3、定時鎖請求

　　在synchronized中，一旦發起鎖請求，該請求就不能停止了，如果不能獲得鎖，則當前線程會阻塞並等待獲得鎖。在某些情況下，你可能需要讓線程在一定時間內去獲得鎖，如果在指定時間內無法獲取鎖，則讓線程放棄鎖請求，轉而執行其他的操作。Lock就提供了定時鎖的機制，使用Lock.tryLock(long timeout, TimeUnit unit)來指定讓線程在timeout單位時間內去爭取鎖資源，如果超過這個時間仍然不能獲得鎖，則放棄鎖請求，定時鎖可以避免線程陷入死鎖的境地。

　　在上面的實例一中，其他線程在5秒后向正在等候鎖的讀線程發起中斷請求，讀線程響應請求並成功中斷。也可以在讀線程中設置定時鎖，設定在5秒內爭奪鎖，超時則放棄鎖，並結束當前的讀線程，使用定時鎖實現讀方法代碼如下：

public void read() throws InterruptedException{
        //使用定時鎖，如果在5秒內仍然不能獲得鎖，則放棄鎖請求
        if(lock.tryLock(5,TimeUnit.SECONDS)){
            try {
                System.out.println("讀操作順利完成，釋放鎖....");
            } finally {
                lock.unlock();
            }
        } else {
            System.out.println("讀線程在5秒內無法獲取鎖，放棄請求，結束讀線程工作....");
        }
}

三、Semaphore

　　上述兩種鎖機制類型都是“互斥鎖”，學過操作系統的都知道，互斥是進程同步關系的一種特殊情況，相當於只存在一個臨界資源，因此同時最多只能給一個線程提供服務。但是，在實際復雜的多線程應用程序中，可能存在多個臨界資源，這時候我們可以借助Semaphore信號量來完成多個臨界資源的訪問。

　　Semaphore基本能完成ReentrantLock的所有工作，使用方法也與之類似，通過acquire()與release()方法來獲得和釋放臨界資源。經實測，Semaphone.acquire()方法默認為可響應中斷鎖，與ReentrantLock.lockInterruptibly()作用效果一致，也就是說在等待臨界資源的過程中可以被Thread.interrupt()方法中斷。

　　此外，Semaphore也實現了可輪詢的鎖請求與定時鎖的功能，除了方法名tryAcquire與tryLock不同，其使用方法與ReentrantLock幾乎一致。Semaphore也提供了公平與非公平鎖的機制，也可在構造函數中進行設定。

　　Semaphore的鎖釋放操作也由手動進行，因此與ReentrantLock一樣，為避免線程因拋出異常而無法正常釋放鎖的情況發生，釋放鎖的操作也必須在finally代碼塊中完成。

　　Semaphore支持多個臨界資源，而ReentrantLock只支持一個臨界資源，筆者認為ReentrantLock是Semaphore的一種特殊情況。Semaphore的使用方法與ReentrantLock實在太過相似，在此不再舉例說明。

四、AtomicInteger

　　首先說明，此處AtomicInteger是一系列相同類的代表之一，常見的還有AtomicLong、AtomicLong等，他們的實現原理相同，區別在與運算對象類型的不同。令人興奮地，還可以通過AtomicReference<V>將一個對象的所有操作轉化成原子操作。

　　我們知道，在多線程程序中，諸如++i 或 i++等運算不具有原子性，是不安全的線程操作之一。通常我們會使用synchronized將該操作變成一個原子操作，但JVM為此類操作特意提供了一些同步類，使得使用更方便，且使程序運行效率變得更高。通過相關資料顯示，通常AtomicInteger的性能是ReentantLock的好幾倍。