juc之Semaphore

Author Avatar
Sean Yu 6月 22, 2020
  • 在其它设备中阅读本文章

内容转载自: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操作是统一的。