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

smart哥

于 2024-02-20 08:59:17 发布

阅读量747

点赞数 32

分类专栏： java并发文章标签： java java并发

本文链接：https://blog.csdn.net/smart_an/article/details/136182035

版权

java并发专栏收录该内容

66 篇文章 2 订阅

订阅专栏

作者简介：大家好，我是smart哥，前中兴通讯、美团架构师，现某互联网公司CTO

联系qq：184480602，加我进群，大家一起学习，一起进步，一起对抗互联网寒冬

学习必须往深处挖，挖的越深，基础越扎实！

阶段1、深入多线程

 阶段2、深入多线程设计模式

 阶段3、深入juc源码解析

阶段4、深入jdk其余源码解析

阶段5、深入jvm源码解析

码哥源码部分

码哥讲源码-原理源码篇【2024年最新大厂关于线程池使用的场景题】

码哥讲源码【炸雷啦！炸雷啦！黄光头他终于跑路啦！】

码哥讲源码-【jvm课程前置知识及c/c++调试环境搭建】

码哥讲源码-原理源码篇【揭秘join方法的唤醒本质上决定于jvm的底层析构函数】

码哥源码-原理源码篇【Doug Lea为什么要将成员变量赋值给局部变量后再操作？】

码哥讲源码【你水不是你的错,但是你胡说八道就是你不对了！】

码哥讲源码【谁再说Spring不支持多线程事务，你给我抽他！】

终结B站没人能讲清楚红黑树的历史，不服等你来踢馆！

打脸系列【020-3小时讲解MESI协议和volatile之间的关系，那些将x86下的验证结果当作最终结果的水货们请闭嘴】

一、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原理

3.1 Semaphore的内部结构

我们先来看下 Semaphore 的内部：

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

3.2 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)

4.1 创建公平策略的Semaphore对象

    Semaphore sm = new Semaphore (2, true);

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

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

4.2 ThreadA调用acqure方法

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

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

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

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

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

4.3 ThreadB调用acqure(2)方法

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

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

ThreadB会调用 doAcquireSharedInterruptibly 方法：