juc之Semaphore
内容转载自：https://www.cnblogs.com/go2sea/tag/Java%E5%A4%9A%E7%BA%BF%E7%A8%8B%E2%80%94%E2%80%94JUC%E5%8C%85/ 稍有改动
Semaphore 是什么
Semaphore是JUC包提供的一个共享锁，一般称之为信号量。可以用来控制同时访问特定资源的线程数量，通过协调各个线程，以保证合理的使用资源。
Semaphore通过自定义的同步器维护了一个或多个共享资源，线程通过调用acquire获取共享资源，通过调用release释放。
注意Semaphore并非lock的子类，所以加锁和解锁，用的是acquire，release，tryacquire，tryrelease
可以把它简单的理解成我们停车场入口立着的那个显示屏，每有一辆车进入停车场显示屏就会显示剩余车位减1，每有一辆车从停车场出去，显示屏上显示的剩余车辆就会加1，当显示屏上的剩余车位为0时，停车场入口的栏杆就不会再打开，车辆就无法进入停车场了，直到有一辆车从停车场出去为止。
用semaphore 实现停车场提示牌功能
业务场景 ：
- 停车场容纳总停车量10。
- 当一辆车进入停车场后，显示牌的剩余车位数响应的减1.
- 每有一辆车驶出停车场后，显示牌的剩余车位数响应的加1。
- 停车场剩余车位不足时，车辆只能在外面等待。
public class TestCar {
//停车场同时容纳的车辆10
private static Semaphore semaphore=new Semaphore(10);
public static void main(String[] args) {
//模拟100辆车进入停车场
for(int i=0;i<100;i++){
Thread thread=new Thread(new Runnable() {
public void run() {
try {
System.out.println("===="+Thread.currentThread().getName()+"来到停车场");
if(semaphore.availablePermits()==0){
System.out.println("车位不足，请耐心等待");
}
semaphore.acquire();//获取令牌尝试进入停车场
System.out.println(Thread.currentThread().getName()+"成功进入停车场");
Thread.sleep(new Random().nextInt(10000));//模拟车辆在停车场停留的时间
System.out.println(Thread.currentThread().getName()+"驶出停车场");
semaphore.release();//释放令牌，腾出停车场车位
} catch (InterruptedException e) {
e.printStackTrace();
}
}
},i+"号车");
thread.start();
}
}
}
源码
public Semaphore(int permits) {
sync = new NonfairSync(permits);
}
public Semaphore(int permits, boolean fair) {
sync = fair ? new FairSync(permits) : new NonfairSync(permits);
}
初始化Semaphore时需要指定共享资源的个数。Semaphore提供了两种模式：公平模式&非公平模式。如果不指定工作模式的话，默认工作在非公平模式下。后面我们将看到，两种模式的区别在于获取共享资源时的排序策略。Semaphore有三个内部类：Sync&NonfairSync&FairSync。后两个继承自Sync，Sync继承自AQS。除了序列化版本号之外，Semaphore只有一个成员变量sync，公平模式下sync初始化为FairSync，非公平模式下sync初始化为NonfairSync。
acquire 响应中断获取资源
Semaphore提供了两种获取资源的方式：响应中断&不响应中断。我们先来看一下响应中断的获取。
public void acquire() throws InterruptedException {
sync.acquireSharedInterruptibly(1);
}
acquire方法由同步器sync调用上层AQS提供的acquireSharedInterruptibly方法获取：
public final void acquireSharedInterruptibly(int arg)
throws InterruptedException {
if (Thread.interrupted())
throw new InterruptedException();
if (tryAcquireShared(arg) < 0)
doAcquireSharedInterruptibly(arg);
}
acquireSharedInterruptibly方法先检测中断。然后调用tryAcquireShared方法试图获取共享资源。这时公平模式和非公平模式的代码执行路径发生分叉，FairSync和NonfairSync各自重写了tryAcquireShared方法。
我们先来看下非公平模式下的tryAcquireShared方法：
protected int tryAcquireShared(int acquires) {
return nonfairTryAcquireShared(acquires);
}
它直接代用了父类Sync提供的nonfairTryAcquireShared方法：
final int nonfairTryAcquireShared(int acquires) {
for (;;) {
int available = getState();
int remaining = available - acquires;
if (remaining < 0 ||
compareAndSetState(available, remaining))
return remaining;
}
}
注意，这里是一个CAS自旋。因为Semaphore是一个共享锁，可能有多个线程同时申请共享资源，因此CAS操作可能失败。直到成功获取返回剩余资源数目，或者发现没有剩余资源返回负值代表申请失败。有一个问题，为什么我们不在CAS操作失败后就直接返回失败呢？因为这样做虽然不会导致错误，但会降低效率：在还有剩余资源的情况下，一个线程因为竞争导致CAS失败后被放入等待序列尾，一定在队列头部有一个线程被唤醒去试图获取资源，这比直接自旋继续获取多了操作等待队列的开销。(有剩余资源的时候就不断的自旋获取，没有剩的了再入队)
这里“非公平”的语义体现在：如果一个线程通过nonfairTryAcquireShared成功获取了共享资源，对于此时正在等待队列中的线程来说，可能是不公平的：队列中线程先到，却没能先获取资源。
如果tryAcquireShared没能成功获取，acquireSharedInterruptibly方法调用doAcquireSharedInterruptibly方法将当前线程放入等待队列并开始自旋检测获取资源：
private void doAcquireSharedInterruptibly(int arg)
throws InterruptedException {
final Node node = addWaiter(Node.SHARED);
boolean failed = true;
try {
for (;;) {
final Node p = node.predecessor();
if (p == head) {
int r = tryAcquireShared(arg);
if (r >= 0) {
setHeadAndPropagate(node, r);
p.next = null; // help GC
failed = false;
return;
}
}
if (shouldParkAfterFailedAcquire(p, node) &&
parkAndCheckInterrupt())
throw new InterruptedException();
}
} finally {
if (failed)
cancelAcquire(node);
}
}
我们注意到，doAcquireSharedInterruptibly中，当一个线程从parkAndCheckInterrupt方法中被中断唤醒之后，直接抛出了中断异常。还记得我们分析AQS时的doAcquireShared方法吗，它在这里的处理方式是用一个局部变量interrupted记录下这个异常但不立即处理，而是等到成功获取资源之后返回这个中断标志，并在上层调用selfInterrupt方法补上中断。
这正是两个方法的关键区别：是否及时响应中断。
我们再来看公平模式下的tryAcquireShared方法：
protected int tryAcquireShared(int acquires) {
for (;;) {
if (hasQueuedPredecessors())
return -1;
int available = getState();
int remaining = available - acquires;
if (remaining < 0 ||
compareAndSetState(available, remaining))
return remaining;
}
}
相比较非公平模式的nonfairTryAcquireShared方法，公平模式下的tryAcquireShared方法在试图获取之前做了一个判断，如果发现等对队列中有线程在等待获取资源，就直接返回-1表示获取失败。当前线程会被上层的acquireSharedInterruptibly方法调用doAcquireShared方法放入等待队列中。这正是“公平”模式的语义：如果有线程先于我进入等待队列且正在等待，就直接进入等待队列，效果便是各个线程按照申请的顺序获得共享资源，具有公平性。
acquireUnInterruptibly 不响应中断获取资源
public void acquireUninterruptibly() {
sync.acquireShared(1);
}
acquireUnInterruptibly方法调用AQS提供的acquireShared方法：
public final void acquireShared(int arg) {
if (tryAcquireShared(arg) < 0)
doAcquireShared(arg);
}
acquireShared方法首先试图获取资源，这与acquireSharedInterruptibly方法相比，没有先检测中断的这一步。紧接着调用doAcquireShared方法，由于这个方法在AQS中已经详细分析过，这里我们只关注它与doAcquireSharedInterruptibly方法的区别：
private void doAcquireShared(int arg) {
final Node node = addWaiter(Node.SHARED);
boolean failed = true;
try {
boolean interrupted = false;
for (;;) {
final Node p = node.predecessor();
if (p == head) {
int r = tryAcquireShared(arg);
if (r >= 0) {
setHeadAndPropagate(node, r);
p.next = null; // help GC
if (interrupted)
selfInterrupt();
failed = false;
return;
}
}
if (shouldParkAfterFailedAcquire(p, node) &&
parkAndCheckInterrupt())
interrupted = true;
}
} finally {
if (failed)
cancelAcquire(node);
}
}
正如刚刚说过的，区别只在线程从parkAndCheckInterrupt方法中因中断而返回时的处理：在这里它没有抛出异常，而是用一个局部变量interrupted记录下这个异常但不立即处理，而是等到成功获取资源之后返回这个中断标志，并在上层调用selfInterrupt方法补上中断。
acquire(int) & acquireUninterruptibly(int) 指定申请的资源数目的获取
public void acquire(int permits) throws InterruptedException {
if (permits < 0) throw new IllegalArgumentException();
sync.acquireSharedInterruptibly(permits);
}
public void acquireUninterruptibly(int permits) {
if (permits < 0) throw new IllegalArgumentException();
sync.acquireShared(permits);
}
可以看到，与不指定数目时的获取的区别仅在参数值，不再赘述。
release 释放资源
公平模式和非公平模式的释放资源操作是一样的：
public void release() {
sync.releaseShared(1);
}
public void release(int permits) {
if (permits < 0) throw new IllegalArgumentException();
sync.releaseShared(permits);
}
调用AQS提供的releaseShared方法：
public final boolean releaseShared(int arg) {
if (tryReleaseShared(arg)) {
doReleaseShared();
return true;
}
return false;
}
releaseShared方法首先调用我们重写的tryReleaseShared方法试图释放资源。然后调用doReleaseShared方法唤醒队列之后的等待线程。我们主要关注tryReleaseShared方法：
protected final boolean tryReleaseShared(int releases) {
for (;;) {
int current = getState();
int next = current + releases;
if (next < current) // overflow
throw new Error("Maximum permit count exceeded");
if (compareAndSetState(current, next))
return true;
}
}
这个方法也是一个CAS自旋，原因是应为Semaphore是一个共享锁，可能有多个线程同时释放资源，因此CAS操作可能失败。最后方法总会成功释放并返回true（如果不出错的话）。
tryAcquire & tryAcquire(timeout) 方法
public boolean tryAcquire() {
return sync.nonfairTryAcquireShared(1) >= 0;
}
public boolean tryAcquire(long timeout, TimeUnit unit)
throws InterruptedException {
return sync.tryAcquireSharedNanos(1, unit.toNanos(timeout));
}
public boolean tryAcquire(int permits) {
if (permits < 0) throw new IllegalArgumentException();
return sync.nonfairTryAcquireShared(permits) >= 0;
}
public boolean tryAcquire(int permits, long timeout, TimeUnit unit)
throws InterruptedException {
if (permits < 0) throw new IllegalArgumentException();
return sync.tryAcquireSharedNanos(permits, unit.toNanos(timeout));
}
没有指定等待时间的tryAcquire调用的是nonfairTryAcquireShared方法，我们已经分析过，不再赘述。我们重点关注指定等待时长的方法。限时等待是通过调用AQS提供的tryAcquireSharedNanos方法实现的：
public final boolean tryAcquireSharedNanos(int arg, long nanosTimeout)
throws InterruptedException {
if (Thread.interrupted())
throw new InterruptedException();
return tryAcquireShared(arg) >= 0 ||
doAcquireSharedNanos(arg, nanosTimeout);
}
注意：限时等待默认都是及时响应中断的。方法开始先检测中断，然后调用tryAcquireShared方法试图获取资源，如果成功的话直接返回true，不成功则调用doAcquireSharedNanos方法：
private boolean doAcquireSharedNanos(int arg, long nanosTimeout)
throws InterruptedException {
if (nanosTimeout <= 0L)
return false;
final long deadline = System.nanoTime() + nanosTimeout;
final Node node = addWaiter(Node.SHARED);
boolean failed = true;
try {
for (;;) {
final Node p = node.predecessor();
if (p == head) {
int r = tryAcquireShared(arg);
if (r >= 0) {
setHeadAndPropagate(node, r);
p.next = null; // help GC
failed = false;
return true;
}
}
nanosTimeout = deadline - System.nanoTime();
if (nanosTimeout <= 0L)
return false;
if (shouldParkAfterFailedAcquire(p, node) &&
nanosTimeout > spinForTimeoutThreshold)
LockSupport.parkNanos(this, nanosTimeout);
if (Thread.interrupted())
throw new InterruptedException();
}
} finally {
if (failed)
cancelAcquire(node);
}
}
方法在自旋之前先计算了一个结束等待的时间节点deadline，然后便开始自旋，每次自旋都要计算一下剩余等待时间nanosTimeout，如果nanosTimeout小于等于0，说明已经到达deadline，直接返回false表示超时。
有一点值得注意，spinForTimeoutThreshold这个值规定了一个阈值，当剩余等待时间小于这个值的时候，线程将不再被park，而是一直在自旋试图获取资源。关于这个值的作用Doug Lea是这样注释的：
/**
* The number of nanoseconds for which it is faster to spin
* rather than to use timed park. A rough estimate suffices
* to improve responsiveness with very short timeouts.
*/
park和unpark操作需要一定的开销，当nanosTimeout很小的时候，这个开销就相对很大了。这个阈值的设置可以让短时等待的线程一直保持自旋，可以提高短时等待的反应效率，而由于nanosTimeout很小，自旋又不会有过多的开销。
除此之外，doAcquireSharedNanos方法与不限时等待的doAcquireShared方法还有两点重要区别：
- 由于有等待时限，所以线程从park方法返回时我们不能确定返回的原因是中断还是超时，因此需要调用interrupted方法检测一下中断标志；
- doAcquireSharedNanos方法是及时响应中断的，而doAcquireShared方法延迟处理中断。
drainPermits & reducePermits 修改剩余共享资源数量
Semaphore提供了“耗尽”所有剩余共享资源的操作：
public int drainPermits() {
return sync.drainPermits();
}
drainPermits调用了自定义同步器Sync的同名方法：
final int drainPermits() {
for (;;) {
int current = getState();
if (current == 0 || compareAndSetState(current, 0))
return current;
}
}
用CAS自旋将剩余资源清空。
我们再来看看“缩减”剩余共享资源的操作：
protected void reducePermits(int reduction) {
if (reduction < 0) throw new IllegalArgumentException();
sync.reducePermits(reduction);
}
首先，缩减必须是单向的，即只能减少不能增加，然后调用Sync的同名方法：
final void reducePermits(int reductions) {
for (;;) {
int current = getState();
int next = current - reductions;
if (next > current) // underflow
throw new Error("Permit count underflow");
if (compareAndSetState(current, next))
return;
}
}
用CAS自旋在剩余共享资源上做缩减。
上述两个对共享资源数量的修改操作有两点需要注意：
- 是不可逆的
- 是对剩余资源的操作而不是全部资源，当剩余资源数目不足或已经为0时，方法就返回，正咋被占用的资源不参与。
总结：
Semaphore是JUC包提供的一个典型的共享锁，它通过自定义两种不同的同步器（FairSync&NonfairSync）提供了公平&非公平两种工作模式，两种模式下分别提供了限时/不限时、响应中断/不响应中断的获取资源的方法（限时获取总是及时响应中断的），而所有的释放资源的release操作是统一的。