併發程式設計之：Lock

小黑說Java發表於2021-09-02
程式設計

大家好，我是小黑，一個在網際網路苟且偷生的農民工。

在之前的文章中，為了保證在併發情況下多執行緒共享資料的執行緒安全，我們會使用synchronized關鍵字來修飾方法或者程式碼塊，以及在生產者消費者模式中同樣使用synchronized來保證生產者和消費者對於緩衝區的原子操作。

synchronized的缺點

那麼synchronized這麼厲害，到底有沒有什麼缺點呢？主要有以下幾個方面：

  1. 使用synchronized加鎖的程式碼塊或者方法，線上程獲取鎖時，會一直試圖獲取直到獲取成功，不能中斷。
  2. 加鎖的條件只能在一個鎖物件上，不支援其他條件
  3. 無法知道鎖物件的狀態，是否被鎖
  4. synchronized鎖只支援非公平鎖，無法做到公平
  5. 對於讀操作和寫操作都是使用獨佔鎖，無法支援共享鎖（在讀操作時共享，寫操作時獨佔）
  6. synchronized鎖在升級之後不支援降級，如在業務流量高峰階段升級為重量級鎖，流量降低時還是重量級，效率較低（有些JVM實現支援降級，但是降級條件極為苛刻，對於Java執行緒來說可基本認為是不支援降級）
  7. 執行緒間通訊無法按條件進行執行緒的喚醒，如生產者消費者場景中生產者完成資料生產後無法做到只喚醒消費者，其他等待的生產者也會被同時喚醒

以上是我能想到的synchronized鎖的一些缺點，如果你有不同的看法，歡迎私信交流。（沒有留言板的痛/(ㄒoㄒ)/~~）

那麼synchronized的這些問題該如何解決呢？或者有沒有替代方案？答案是有的，就是使用我們今天要講的Lock鎖。

Lock的優點

Lock鎖是Java.util.concurrent.locks（JUC）包中的一個介面，並且有很多不同的實現類。這些實現類基本可以完全解決上面我們說到的所有問題。

Lock鎖具備以下優點：

  1. 支援超時獲取，中斷獲取
  2. 可以按條件加鎖，靈活性更高
  3. 支援公平和非公平鎖
  4. 有獨佔鎖和共享鎖的實現，如讀寫鎖
  5. 可以做到等待執行緒的精準喚醒

接下來具體看看對應的實現。

基礎鋪墊

在開始之前，先和大家對於一些概念做一下回顧和普及。

可重入鎖

可重入鎖是指鎖具備可重入的特性，可重入的意思是一個執行緒在獲取鎖之後，如果再次獲取鎖時，可以成功獲取，不會因為鎖正在被佔有而死鎖。

synchronized鎖就是可重入鎖，在一個synchronized方法中遞迴呼叫本方法，可以成功獲取到鎖，不會死鎖。

Lock鎖的實現中基本也都支援可重入。

公平鎖和非公平鎖

公平鎖指在有執行緒獲取鎖失敗阻塞時，一定會讓先開始阻塞的執行緒先執行，就好比是排隊買票，排在前面的先買；

非公平鎖則不保證這種公平性，就算有其他執行緒在阻塞等待，新來的執行緒也可以直接獲取鎖，就好比插隊。

獨佔鎖和共享鎖

獨佔鎖是指一把鎖同一時間只能被一個執行緒持有，舉個生活中的例子，我們使用叫車軟體打專車，那麼一輛車同一時間只能讓一個使用者打到，這輛專車就好比是一把獨佔鎖，被一個使用者獨自佔有了嘛。

共享鎖則不一樣，一把鎖可以被多個執行緒持有，這個就想我們打拼車，一輛拼車同一時間可以讓多個使用者打到，這輛拼車就是一把共享鎖。

說完這些以後我們來看一下Lock介面的一些具體實現。

ReentrantLock

ReentrantLock從名稱理解，就是一把可重入鎖，並且它是一把獨佔鎖，而且具有公平和非公平實現。

我們通過程式碼來看一下如何通過ReentrantLock來做加解鎖操作。

public static void main(String[] args) {
        ReentrantLock lock = new ReentrantLock(false);
        lock.lock();
        try {
            // do something...
        }finally {
            lock.unlock();
        }
    }

首先建立一個ReentrantLock物件，在建立時構造方法傳入的boolean值控制是公平鎖還是非公平鎖，如果不傳引數則預設是非公平鎖。

呼叫lock()方法來進行加鎖，可以看到使用try-finally程式碼塊，在finally中進行unlock()解鎖操作，這一點一定要注意，因為lock不會自己進行解鎖，必須手動進行釋放，為了保證鎖一定可以被釋放，防止發生死鎖，所以要在finally中進行。這一點和synchronized有區別，使用synchronized不用關注鎖的釋放時機，這也是為了靈活性必須要付出的一點代價。

ReentrantLock除了通過lock()方法加鎖之外，還有以下方式加鎖：

  • tryLock()：只有在呼叫時它不被另一個執行緒佔用才能獲取鎖
  • tryLock(long timeout, TimeUnit unit) 如果在給定的等待時間內沒有被另一個執行緒佔用，並且當前執行緒尚未被中斷，則獲取該鎖
  • lockInterruptibly() 獲取鎖定，除非當前執行緒是interrupted

除了獲取鎖的方法之外，還有一些其他的方法可以獲得一些鎖相關的狀態資訊：

  • isLocked() 查詢此鎖是否由任何執行緒持有
  • isHeldByCurrentThread() 查詢此鎖是否由當前執行緒持有
  • getOwner() 返回當前擁有此鎖的執行緒，如果不擁有，則返回null

ReentrantLock本身是獨佔鎖，不支援共享，那麼如何做到執行緒的精準喚醒，我們接著說。

Condition

Condition也是JUC包下的locks包中的一個介面，提供了類似於Object的wait()，notify()，notifyAll()這樣的物件監聽器方法，可以與Lock的實現類配合做到執行緒的等待/喚醒機制，並且能夠做到精準喚醒。接下來我們看下面的例子：

public class ProdConsDemo {

    public static void main(String[] args) {
        KFC kfc = new KFC();
        new Thread(() -> {
            for (int i = 0; i < 100; i++) {
                kfc.product();
            }
        }, "店員1").start();
        new Thread(() -> {
            for (int i = 0; i < 100; i++) {
                kfc.product();
            }
        }, "店員2").start();
        new Thread(() -> {
            for (int i = 0; i < 100; i++) {
                kfc.consume();
            }
        }, "顧客1").start();
        new Thread(() -> {
            for (int i = 0; i < 100; i++) {
                kfc.consume();
            }
        }, "顧客2").start();
    }
}

class KFC {
    int hamburgerNum = 0;

    public synchronized void product() {
        while (hamburgerNum == 10) {
            try {
                // 數量到達最大，生產者等待
                this.wait();
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }
        System.out.println("生產一個漢堡" + (++hamburgerNum));
        // 喚醒其他執行緒
        this.notifyAll();
    }

    public synchronized void consume() {
        while (hamburgerNum == 0) {
            try {
				//數量到達最小，消費者等待
                this.wait();
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }
        System.out.println("賣出一個漢堡" + (hamburgerNum--));
        // 喚醒其他執行緒
        this.notifyAll();
    }
}

看過小黑之前文章的朋友應該還記得這個例子，KFC裡的店員生產漢堡，顧客來消費，典型的生產者消費者模式，我們可以看到在上面的程式碼中，是使用的鎖物件this的wait()和notifyAll()方法來做執行緒等待和喚醒。那麼這裡會有一個問題，就是在notifyAll()時，無法做到只喚醒消費者或者只喚醒生產者。而線上程被喚醒之後就會面臨更多的執行緒切換，而執行緒切換是很消耗CPU資源的。

那麼我們使用Condition和ReentrantLock來修改一下我們的程式碼。

class KFC {
    int hamburgerNum = 0;
    ReentrantLock lock = new ReentrantLock();
    Condition isEmpty = lock.newCondition();
    Condition isFull = lock.newCondition();
    public void product() {
        lock.lock();
        try {
            while (hamburgerNum == 10) {
                // 數量到達最大，生產者等待
                isFull.await();
            }
            System.out.println("生產一個漢堡" + (++hamburgerNum));
            // 喚醒消費者執行緒
            isEmpty.signalAll();
        } catch (InterruptedException e) {
            e.printStackTrace();
        } finally {
            lock.unlock();
        }
    }

    public void consume() {
        lock.lock();
        try {
            while (hamburgerNum == 0) {
                //數量到達最小，消費者等待
                isEmpty.await();
            }
            System.out.println("賣出一個漢堡" + (hamburgerNum--));
            // 喚醒生產者執行緒
            isFull.signalAll();
        } catch (InterruptedException e) {
            e.printStackTrace();
        } finally {
            lock.unlock();
        }
    }
}

可以看到，我們使用ReentrantLock來進行執行緒安全控制，進行加解鎖，然後建立兩個Condition物件，分別代表生產者和消費者的標記，當生產者生產完一個之後，就會準確的喚醒消費者執行緒，反之同理。

ReadWriteLock

ReadWriteLock是讀寫鎖介面，通過ReadWriteLock可以實現多個執行緒對於讀操作共享，對於寫操作獨佔。

在ReadWriteLock中有兩個Lock變數，通過兩個Lock分別控制讀和寫。

class Data {
    private int num = 0;
    private final ReentrantReadWriteLock lock = new ReentrantReadWriteLock();
    private final ReentrantReadWriteLock.ReadLock readLock = lock.readLock();
    private final ReentrantReadWriteLock.WriteLock writeLock = lock.writeLock();
    public void read() {
        readLock.lock();
        try {
            System.out.println(Thread.currentThread().getName() + "讀取=>" + num);
            TimeUnit.SECONDS.sleep(5);
            System.out.println(Thread.currentThread().getName() + "讀取結束");
        } catch (Exception e) {
            e.printStackTrace();
        } finally {
            readLock.unlock();
        }
    }

    public void write() {
        writeLock.lock();
        try {
            System.out.println(Thread.currentThread().getName() + "寫入=>" + num++);
            TimeUnit.SECONDS.sleep(1);
            System.out.println(Thread.currentThread().getName() + "寫入結束");
        } catch (Exception e) {
            e.printStackTrace();
        } finally {
            writeLock.unlock();
        }
    }
}

對於讀寫鎖，執行緒對於鎖的競爭情況如下：

  1. 讀-讀操作共享；
  2. 讀-寫操作獨佔；
  3. 寫-讀操作獨佔；
  4. 寫-寫操作獨佔；

也就是說，當有一個執行緒持有讀鎖時，其他執行緒也可以獲取讀到讀鎖，但是不能獲取寫鎖，必須等讀鎖釋放；當有一個執行緒持有寫鎖時，其他執行緒都不能獲取到鎖。

StampedLock

StampedLock是JDK1.8新引入的，主要是為了優化ReadWriteLock的讀寫鎖效能，相比於普通的ReadWriteLock主要多了樂觀獲取讀鎖的功能。

那麼ReadWriteLock有什麼效能問題呢？主要出現在讀-寫操作上，當有一個執行緒在讀取時，寫執行緒只能等讀取完之後才能獲取，讀的過程中不允許寫，是一個悲觀讀鎖。

StampedLock允許在讀的過程中寫，但是這樣會導致我們讀執行緒獲取的資料不一致，所以需要增加一點程式碼來判斷在讀的過程中是否有些操作，這是一種樂觀讀的鎖；我們來看一下程式碼。

class Data {
    private int num = 0;

    private final StampedLock lock = new StampedLock();

    public void read() {
//        long stamp = lock.readLock();
        // 獲取樂觀讀，拿到一個版本戳
        long stamp = lock.tryOptimisticRead(); 
        try {
            System.out.println(Thread.currentThread().getName() + "讀取=>" + num);
            TimeUnit.SECONDS.sleep(5);
            System.out.println(Thread.currentThread().getName() + "讀取結束");
			// 讀取完之後對剛開始拿到的版本戳進行驗證
            if (!lock.validate(stamp)) {
                // 驗證不通過，說明發生了寫操作，這是需要重新獲取悲觀讀鎖進行處理
                System.out.println("validatefalse");
                stamp = lock.readLock();
                // do something...
            }
        } catch (Exception e) {
            e.printStackTrace();
        } finally {
            lock.unlockRead(stamp);
        }
    }

    public void write() {
        long stamp = lock.writeLock();
        try {
            System.out.println(Thread.currentThread().getName() + "寫入=>" + num++);
            TimeUnit.SECONDS.sleep(1);
            System.out.println(Thread.currentThread().getName() + "寫入結束");
        } catch (Exception e) {
            e.printStackTrace();
        } finally {
            lock.unlockWrite(stamp);
        }
    }
}

所以StampedLock就是先樂觀的認為在讀的過程中不會有寫操作，所以是樂觀鎖，而悲觀鎖就是悲觀的認為在讀的過程中會有些操作，所以拒絕寫入。

顯然在併發高的情況下樂觀鎖的併發效率要更高，但是會有一小部分的寫入導致資料不準確，所以需要通過validate(stamp)檢測出來，重新讀取。

總結

簡單總結一下，首先我們講了synchronized的7個缺點：不能超時中斷；只能在一個物件上加鎖；獲取不到鎖的狀態；不支援公平鎖；不支援共享鎖；鎖升級後不能降級；無法做到精準喚醒阻塞執行緒等。

然後我們通過Lock的具體實現看到，Lock都解決了這些問題，ReentrantLock支援超時中斷獲取鎖，並且可以按條件判斷進行加鎖，有方法可以看到鎖的狀態資訊，支援公平和非公平實現等，通過Condition的await()和signal()/signalAll()可以做到精準喚醒等待執行緒；ReadWriteLock可以支援共享鎖，讀鎖共享，寫鎖獨佔；然後StampedLock在效能上對讀寫鎖進行優化，主要是通過樂觀讀鎖和vaidate(stamp)驗證讀取過程中有沒有寫入。

使用Lock鎖很重要的一點就是需要自己手動釋放鎖，所以一定要寫在finally中；

使用Conditon進行喚醒執行緒時要記清楚是signal()/signalAll()方法，不是notify()/notifyAll()方法，不要用錯了。

Lock鎖的底層實現邏輯都是依賴於AbstractQueuedSynchronizer（AQS）和CAS無鎖機制來實現的，這部分內容比較複雜，我們下期單獨來說一說。

好的，今天的內容就到這裡，我們下期見。

關注我的公眾號【小黑說Java】,更多幹貨內容。
image

相關文章