Java中的鎖

Java中的鎖

鎖像synchronized同步塊同樣，是一種線程同步機制，但比Java中的synchronized同步塊更復雜。由於鎖（以及其它更高級的線程同步機制）是由synchronized同步塊的方式實現的，因此咱們還不能徹底擺脫synchronized關鍵字（譯者注：這說的是Java 5以前的狀況）。

自Java 5開始，java.util.concurrent.locks包中包含了一些鎖的實現，所以你不用去實現本身的鎖了。可是你仍然須要去了解怎樣使用這些鎖，且瞭解這些實現背後的理論也是頗有用處的。能夠參考我對java.util.concurrent.locks.Lock的介紹，以瞭解更多關於鎖的信息。

一個簡單的鎖

讓咱們從java中的一個同步塊開始：

public class Counter{
    private int count = 0;

    public int inc(){
        synchronized(this){
            return ++count;
        }
    }
}

能夠看到在inc()方法中有一個synchronized(this)代碼塊。該代碼塊能夠保證在同一時間只有一個線程能夠執行return ++count。雖然在synchronized的同步塊中的代碼能夠更加複雜，可是++count這種簡單的操做已經足以表達出線程同步的意思。

如下的Counter類用Lock代替synchronized達到了一樣的目的：

public class Counter{
    private Lock lock = new Lock();
    private int count = 0;

    public int inc(){
        lock.lock();
        int newCount = ++count;
        lock.unlock();
        return newCount;
    }
}

lock()方法會對Lock實例對象進行加鎖，所以全部對該對象調用lock()方法的線程都會被阻塞，直到該Lock對象的unlock()方法被調用。

這裏有一個Lock類的簡單實現：

public class Counter{
public class Lock{
    private boolean isLocked = false;

    public synchronized void lock()
        throws InterruptedException{
        while(isLocked){
            wait();
        }
        isLocked = true;
    }

    public synchronized void unlock(){
        isLocked = false;
        notify();
    }
}

注意其中的while(isLocked)循環，它又被叫作「自旋鎖」。自旋鎖以及wait()和notify()方法在線程通訊這篇文章中有更加詳細的介紹。當isLocked爲true時，調用lock()的線程在wait()調用上阻塞等待。爲防止該線程沒有收到notify()調用也從wait()中返回（也稱做虛假喚醒），這個線程會從新去檢查isLocked條件以決定當前是否能夠安全地繼續執行仍是須要從新保持等待，而不是認爲線程被喚醒了就能夠安全地繼續執行了。若是isLocked爲false，當前線程會退出while(isLocked)循環，並將isLocked設回true，讓其它正在調用lock()方法的線程可以在Lock實例上加鎖。

當線程完成了臨界區（位於lock()和unlock()之間）中的代碼，就會調用unlock()。執行unlock()會從新將isLocked設置爲false，而且通知（喚醒）其中一個（如有的話）在lock()方法中調用了wait()函數而處於等待狀態的線程。

鎖的可重入性

Java中的synchronized同步塊是可重入的。這意味着若是一個java線程進入了代碼中的synchronized同步塊，並所以得到了該同步塊使用的同步對象對應的管程上的鎖，那麼這個線程能夠進入由同一個管程對象所同步的另外一個java代碼塊。下面是一個例子：

public class Reentrant{
    public synchronized outer(){
        inner();
    }

    public synchronized inner(){
        //do something
    }
}

注意outer()和inner()都被聲明爲synchronized，這在Java中和synchronized(this)塊等效。若是一個線程調用了outer()，在outer()裏調用inner()就沒有什麼問題，由於這兩個方法（代碼塊）都由同一個管程對象（」this」)所同步。若是一個線程已經擁有了一個管程對象上的鎖，那麼它就有權訪問被這個管程對象同步的全部代碼塊。這就是可重入。線程能夠進入任何一個它已經擁有的鎖所同步着的代碼塊。

前面給出的鎖實現不是可重入的。若是咱們像下面這樣重寫Reentrant類，當線程調用outer()時，會在inner()方法的lock.lock()處阻塞住。

public class Reentrant2{
    Lock lock = new Lock();

    public outer(){
        lock.lock();
        inner();
        lock.unlock();
    }

    public synchronized inner(){
        lock.lock();
        //do something
        lock.unlock();
    }
}

調用outer()的線程首先會鎖住Lock實例，而後繼續調用inner()。inner()方法中該線程將再一次嘗試鎖住Lock實例，結果該動做會失敗（也就是說該線程會被阻塞），由於這個Lock實例已經在outer()方法中被鎖住了。

兩次lock()之間沒有調用unlock()，第二次調用lock就會阻塞，看過lock()實現後，會發現緣由很明顯：

public class Lock{
    boolean isLocked = false;

    public synchronized void lock()
        throws InterruptedException{
        while(isLocked){
            wait();
        }
        isLocked = true;
    }

    ...
}

一個線程是否被容許退出lock()方法是由while循環（自旋鎖）中的條件決定的。當前的判斷條件是隻有當isLocked爲false時lock操做才被容許，而沒有考慮是哪一個線程鎖住了它。

爲了讓這個Lock類具備可重入性，咱們須要對它作一點小的改動：

public class Lock{
    boolean isLocked = false;
    Thread  lockedBy = null;
    int lockedCount = 0;

    public synchronized void lock()
        throws InterruptedException{
        Thread callingThread =
            Thread.currentThread();
        while(isLocked && lockedBy != callingThread){
            wait();
        }
        isLocked = true;
        lockedCount++;
        lockedBy = callingThread;
  }

    public synchronized void unlock(){
        if(Thread.curentThread() ==
            this.lockedBy){
            lockedCount--;

            if(lockedCount == 0){
                isLocked = false;
                notify();
            }
        }
    }

    ...
}

注意到如今的while循環（自旋鎖）也考慮到了已鎖住該Lock實例的線程。若是當前的鎖對象沒有被加鎖(isLocked = false)，或者當前調用線程已經對該Lock實例加了鎖，那麼while循環就不會被執行，調用lock()的線程就能夠退出該方法（譯者注：「被容許退出該方法」在當前語義下就是指不會調用wait()而致使阻塞）。

除此以外，咱們須要記錄同一個線程重複對一個鎖對象加鎖的次數。不然，一次unblock()調用就會解除整個鎖，即便當前鎖已經被加鎖過屢次。在unlock()調用沒有達到對應lock()調用的次數以前，咱們不但願鎖被解除。

如今這個Lock類就是可重入的了。

鎖的公平性

Java的synchronized塊並不保證嘗試進入它們的線程的順序。所以，若是多個線程不斷競爭訪問相同的synchronized同步塊，就存在一種風險，其中一個或多個線程永遠也得不到訪問權——也就是說訪問權老是分配給了其它線程。這種狀況被稱做線程飢餓。爲了不這種問題，鎖須要實現公平性。本文所展示的鎖在內部是用synchronized同步塊實現的，所以它們也不保證公平性。飢餓和公平中有更多關於該內容的討論。

在finally語句中調用unlock()

若是用Lock來保護臨界區，而且臨界區有可能會拋出異常，那麼在finally語句中調用unlock()就顯得很是重要了。這樣能夠保證這個鎖對象能夠被解鎖以便其它線程能繼續對其加鎖。如下是一個示例：

lock.lock();
try{
    //do critical section code,
    //which may throw exception
} finally {
    lock.unlock();
}

這個簡單的結構能夠保證當臨界區拋出異常時Lock對象能夠被解鎖。若是不是在finally語句中調用的unlock()，當臨界區拋出異常時，Lock對象將永遠停留在被鎖住的狀態，這會致使其它全部在該Lock對象上調用lock()的線程一直阻塞。

---

原文 locks
譯者 申章 校對 丁一
via ifeve