Java多线程进阶（二十）—— J.U.C之synchronizer框架：Semaphore

图片描述

本文首发于一世流云的专栏：https://segmentfault.com/blog...

一、Semaphore简介

Semaphore，又名信号量，这个类的作用有点类似于“许可证”。有时，我们因为一些原因需要控制同时访问共享资源的最大线程数量，比如出于系统性能的考虑需要限流，或者共享资源是稀缺资源，我们需要有一种办法能够协调各个线程，以保证合理的使用公共资源。

Semaphore维护了一个许可集，其实就是一定数量的“许可证”。
当有线程想要访问共享资源时，需要先获取(acquire)的许可；如果许可不够了，线程需要一直等待，直到许可可用。当线程使用完共享资源后，可以归还(release)许可，以供其它需要的线程使用。

另外，Semaphore支持公平/非公平策略，这和ReentrantLock类似，后面讲Semaphore原理时会看到，它们的实现本身就是类似的。

二、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仅仅是保证了线程由权限使用共享资源，至于使用过程中是否由并发问题，需要通过锁来保证。

总结一下，许可数 ≤ 0代表共享资源不可用。许可数＞ 0，代表共享资源可用，且多个线程可以同时访问共享资源。

这是不是和CountDownLatch有点像？
我们来比较下：

同步器	作用
CountDownLatch	同步状态`State > 0`表示资源不可用，所有线程需要等待；`State == 0`表示资源可用，所有线程可以同时访问
Semaphore	`剩余许可数 < 0`表示资源不可用，所有线程需要等待； `许可剩余数 ≥ 0`表示资源可用，所有线程可以同时访问

如果读者阅读过本系列的AQS相关文章，应该立马可以反应过来，这其实就是对同步状态的定义不同。
CountDownLatch内部实现了AQS的共享功能，那么Semaphore是否也一样是利用内部类实现了AQS的共享功能呢？

三、Semaphore原理

Semaphore的内部结构

我们先来看下Semaphore的内部：

可以看到，Semaphore果然是通过内部类实现了AQS框架提供的接口，而且基本结构几乎和ReentrantLock完全一样，通过内部类分别实现了公平/非公平策略。

Semaphore对象的构造

Semaphore sm = new Semaphore (3, true);

Semaphore有两个构造器：

构造器1：

构造器2：

构造时需要指定“许可”的数量——permits，内部结构如下：

四、Semaphore的公平策略分析

我们还是通过示例来分析：

假设现在一共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对象

Semaphore sm = new Semaphore (2, true);

可以看到，内部创建了一个FairSync对象，并传入许可数permits：

Sync是Semaphore的一个内部抽象类，公平策略的FairSync和非公平策略的NonFairSync都继承该类。
可以看到，构造器传入的permits值就是同步状态的值，这也体现了我们在AQS系列中说过的：
AQS框架的设计思想就是分离构建同步器时的一系列关注点，它的所有操作都围绕着资源——同步状态（synchronization state）来展开，并将资源的定义和访问留给用户解决：

ThreadA调用acqure方法

Semaphore的acquire方法内部调用了AQS的方法，入参"1"表示尝试获取1个许可：

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

关键来看下Semaphore是如何实现tryAcquireShared方法的：

对于Semaphore来说，线程是可以一次性尝试获取多个许可的，此时只要剩余的许可数量够，最终会通过自旋操作更新成功。如果剩余许可数量不够，会返回一个负数，表示获取失败。

显然，ThreadA获取许可成功。此时，同步状态值State == 1，等待队列的结构如下：

ThreadB调用acqure(2)方法

带入参的aquire方法内部和无参的一样，都是调用了AQS的acquireSharedInterruptibly方法：

此时，ThreadB一样进入tryAcquireShared方法。不同的是，此时剩余许可数不足，因为ThreadB一次性获取2个许可，tryAcquireShared方法返回一个负数，表示获取失败：
remaining = available - acquires = 1- 2 = -1;

ThreadB会调用doAcquireSharedInterruptibly方法：