摘要：當線程使用完共享資源后，可以歸還許可，以供其它需要的線程使用。所以，并不會阻塞調用線程。立即減少指定數目的可用許可數。方法用于將可用許可數清零，并返回清零前的許可數六的類接口聲明類聲明構造器接口聲明

本文首發(fā)于一世流云的專欄：https://segmentfault.com/blog...

Semaphore，又名信號量，這個類的作用有點類似于“許可證”。有時，我們因為一些原因需要控制同時訪問共享資源的最大線程數量，比如出于系統性能的考慮需要限流，或者共享資源是稀缺資源，我們需要有一種辦法能夠協調各個線程，以保證合理的使用公共資源。

Semaphore維護了一個許可集，其實就是一定數量的“許可證”。
當有線程想要訪問共享資源時，需要先獲取(acquire)的許可；如果許可不夠了，線程需要一直等待，直到許可可用。當線程使用完共享資源后，可以歸還(release)許可，以供其它需要的線程使用。

另外，Semaphore支持公平/非公平策略，這和ReentrantLock類似，后面講Semaphore原理時會看到，它們的實現本身就是類似的。

我們來看下Oracle官方給出的示例：

class Pool {
    private static final int MAX_AVAILABLE = 100; // 可同時訪問資源的最大線程數
    private final Semaphore available = new Semaphore(MAX_AVAILABLE, true);
    protected Object[] items = new Object[MAX_AVAILABLE];   //共享資源
    protected boolean[] used = new boolean[MAX_AVAILABLE];
    public Object getItem() throws InterruptedException {
        available.acquire();
        return getNextAvailableItem();
    }
    public void putItem(Object x) {
        if (markAsUnused(x))
            available.release();
    }
    private synchronized Object getNextAvailableItem() {
        for (int i = 0; i < MAX_AVAILABLE; ++i) {
            if (!used[i]) {
                used[i] = true;
                return items[i];
            }
        }
        return null;
    }
    private synchronized boolean markAsUnused(Object item) {
        for (int i = 0; i < MAX_AVAILABLE; ++i) {
            if (item == items[i]) {
                if (used[i]) {
                    used[i] = false;
                    return true;
                } else
                    return false;
            }
        }
        return false;
    }
}

items數組可以看成是我們的共享資源，當有線程嘗試使用共享資源時，我們要求線程先獲得“許可”（調用Semaphore 的acquire方法），這樣線程就擁有了權限，否則就需要等待。當使用完資源后，線程需要調用Semaphore 的release方法釋放許可。

 注意：上述示例中，對于共享資源訪問需要由鎖來控制，Semaphore僅僅是保證了線程由權限使用共享資源，至于使用過程中是否由并發(fā)問題，需要通過鎖來保證。

總結一下，許可數 ≤ 0代表共享資源不可用。許可數 ＞ 0，代表共享資源可用，且多個線程可以同時訪問共享資源。

這是不是和CountDownLatch有點像？
我們來比較下：

如果讀者閱讀過本系列的AQS相關文章，應該立馬可以反應過來，這其實就是對同步狀態(tài)的定義不同。
CountDownLatch內部實現了AQS的共享功能，那么Semaphore是否也一樣是利用內部類實現了AQS的共享功能呢？

我們先來看下Semaphore的內部：

可以看到，Semaphore果然是通過內部類實現了AQS框架提供的接口，而且基本結構幾乎和ReentrantLock完全一樣，通過內部類分別實現了公平/非公平策略。

Semaphore sm = new Semaphore (3, true);

Semaphore有兩個構造器：

構造器1：

構造器2：

構造時需要指定“許可”的數量——permits，內部結構如下：

我們還是通過示例來分析：

假設現在一共3個線程：ThreadA、ThreadB、ThreadC。一個許可數為2的公平策略的Semaphore。線程的調用順序如下：

Semaphore sm = new Semaphore (2, true);

// ThreadA: sm.acquire()

// ThreadB: sm.acquire(2)

// ThreadC: sm.acquire()

// ThreadA: sm.release()

// ThreadB: sm.release(2)

Semaphore sm = new Semaphore (2, true);

可以看到，內部創(chuàng)建了一個FairSync對象，并傳入許可數permits：

Sync是Semaphore的一個內部抽象類，公平策略的FairSync和非公平策略的NonFairSync都繼承該類。
可以看到，構造器傳入的permits值就是同步狀態(tài)的值，這也體現了我們在AQS系列中說過的：
AQS框架的設計思想就是分離構建同步器時的一系列關注點，它的所有操作都圍繞著資源——同步狀態(tài)（synchronization state）來展開，并將資源的定義和訪問留給用戶解決：

Semaphore的acquire方法內部調用了AQS的方法，入參"1"表示嘗試獲取1個許可：

AQS的acquireSharedInterruptibly方式是共享功能的一部分，我們在AQS系列中就已經對它很熟悉了：

關鍵來看下Semaphore是如何實現tryAcquireShared方法的：

對于Semaphore來說，線程是可以一次性嘗試獲取多個許可的，此時只要剩余的許可數量夠，最終會通過自旋操作更新成功。如果剩余許可數量不夠，會返回一個負數，表示獲取失敗。

顯然，ThreadA獲取許可成功。此時，同步狀態(tài)值State == 1，等待隊列的結構如下：

帶入參的aquire方法內部和無參的一樣，都是調用了AQS的acquireSharedInterruptibly方法：

此時，ThreadB一樣進入tryAcquireShared方法。不同的是，此時剩余許可數不足，因為ThreadB一次性獲取2個許可，tryAcquireShared方法返回一個負數，表示獲取失敗：
remaining = available - acquires = 1- 2 = -1;

ThreadB會調用doAcquireSharedInterruptibly方法：

上述方法首先通過addWaiter方法將ThreadB包裝成一個共享結點，加入等待隊列：

然后會進入自旋操作，先嘗試獲取一次資源，顯然此時是獲取失敗的，然后判斷是否要進入阻塞（shouldParkAfterFailedAcquire）：

上述方法會先將前驅結點的狀態(tài)置為SIGNAL，表示ThreadB需要阻塞，但在阻塞之前需要將前驅置為SIGNAL，以便將來可以喚醒ThreadB。

最終ThreadB會在parkAndCheckInterrupt中進入阻塞：

此時，同步狀態(tài)值依然是State == 1，等待隊列的結構如下：

流程和步驟3完全相同，ThreadC被包裝成結點加入等待隊列后：

同步狀態(tài)：State == 1

Semaphore的realse方法調用了AQS的releaseShared方法，默認入參為"1"，表示歸還一個許可：

來看下Semaphore是如何實現tryReleaseShared方法的，tryReleaseShared方法是一個自旋操作，直到更新State成功：

更新完成后，State == 2,ThreadA會進入doReleaseShared方法，先將頭結點狀態(tài)置為0，表示即將喚醒后繼結點：

此時，等待隊列結構：

然后調用unparkSuccessor方法喚醒后繼結點：

此時，ThreadB被喚醒，會從原阻塞處繼續(xù)向下執(zhí)行：

此時，同步狀態(tài)：State == 2

ThreadB被喚醒后，從下面開始繼續(xù)往下執(zhí)行，進入下一次自旋：

在下一次自旋中，ThreadB調用tryAcquireShared方法成功獲取到共享資源（State修改為0），setHeadAndPropagate方法把ThreadB變?yōu)轭^結點，
并根據傳播狀態(tài)判斷是否要喚醒并釋放后繼結點：

同步狀態(tài)：State == 0

ThreadB會調用doReleaseShared方法，繼續(xù)嘗試喚醒后繼的共享結點（也就是ThreadC），這個過程和ThreadB被喚醒完全一樣：

同步狀態(tài)：State == 0

由于目前共享資源仍為0，所以ThreadC被喚醒后，在經過嘗試獲取資源失敗后，又進入了阻塞：

內部和無參的release方法一樣：

更新完成后，State == 2,ThreadA會進入doReleaseShared方法，喚醒后繼結點：

此時，等待隊列結構：

同步狀態(tài)：State == 2

由于目前共享資源為2，所以ThreadC被喚醒后，獲取資源成功：

最終同步隊列的結構如下：

同步狀態(tài)：State == 0

Semaphore其實就是實現了AQS共享功能的同步器，對于Semaphore來說，資源就是許可證的數量：

剩余許可證數（State值） - 嘗試獲取的許可數（acquire方法入參） ≥ 0：資源可用

剩余許可證數（State值） - 嘗試獲取的許可數（acquire方法入參） < 0：資源不可用

這里共享的含義是多個線程可以同時獲取資源，當計算出的剩余資源不足時，線程就會阻塞。

注意：Semaphore不是鎖，只能限制同時訪問資源的線程數，至于對數據一致性的控制，Semaphore是不關心的。當前，如果是只有一個許可的Semaphore，可以當作鎖使用。

另外，上述我們討論的是Semaphore的公平策略，非公平策略的差異并不大：

可以看到，非公平策略不會去查看等待隊列的隊首是否有其它線程正在等待，而是直接嘗試修改State值。

Semaphore還有兩個比較特殊的方法，這兩個方法的特點是采用自旋操作State變量，直到成功為止。所以，并不會阻塞調用線程。

reducePermits

reducePermits立即減少指定數目的可用許可數。

drainPermits

drainPermits方法用于將可用許可數清零，并返回清零前的許可數