Java之 Semaphore信号量的原理和示例

Java之 Semaphore信号量的原理和示例

 

概要

本章,我们对JUC包中的信号量Semaphore进行学习。内容包括:
Semaphore简介
Semaphore数据结构
Semaphore源码分析(基于JDK1.7.0_40)
Semaphore示例

出处:http://www.cnblogs.com/skywang12345/p/3534050.html

 

Semaphore简介

Semaphore是一个计数信号量,它的本质是一个"共享锁"。

信号量维护了一个信号量许可集。线程可以通过调用acquire()来获取信号量的许可;当信号量中有可用的许可时,线程能获取该许可;否则线程必须等待,直到有可用的许可为止。 线程可以通过release()来释放它所持有的信号量许可。


Semaphore的函数列表

复制代码

// 创建具有给定的许可数和非公平的公平设置的 Semaphore。
Semaphore(int permits)
// 创建具有给定的许可数和给定的公平设置的 Semaphore。
Semaphore(int permits, boolean fair)

// 从此信号量获取一个许可,在提供一个许可前一直将线程阻塞,否则线程被中断。
void acquire()
// 从此信号量获取给定数目的许可,在提供这些许可前一直将线程阻塞,或者线程已被中断。
void acquire(int permits)
// 从此信号量中获取许可,在有可用的许可前将其阻塞。
void acquireUninterruptibly()
// 从此信号量获取给定数目的许可,在提供这些许可前一直将线程阻塞。
void acquireUninterruptibly(int permits)
// 返回此信号量中当前可用的许可数。
int availablePermits()
// 获取并返回立即可用的所有许可。
int drainPermits()
// 返回一个 collection,包含可能等待获取的线程。
protected Collection<Thread> getQueuedThreads()
// 返回正在等待获取的线程的估计数目。
int getQueueLength()
// 查询是否有线程正在等待获取。
boolean hasQueuedThreads()
// 如果此信号量的公平设置为 true,则返回 true。
boolean isFair()
// 根据指定的缩减量减小可用许可的数目。
protected void reducePermits(int reduction)
// 释放一个许可,将其返回给信号量。
void release()
// 释放给定数目的许可,将其返回到信号量。
void release(int permits)
// 返回标识此信号量的字符串,以及信号量的状态。
String toString()
// 仅在调用时此信号量存在一个可用许可,才从信号量获取许可。
boolean tryAcquire()
// 仅在调用时此信号量中有给定数目的许可时,才从此信号量中获取这些许可。
boolean tryAcquire(int permits)
// 如果在给定的等待时间内此信号量有可用的所有许可,并且当前线程未被中断,则从此信号量获取给定数目的许可。
boolean tryAcquire(int permits, long timeout, TimeUnit unit)
// 如果在给定的等待时间内,此信号量有可用的许可并且当前线程未被中断,则从此信号量获取一个许可。
boolean tryAcquire(long timeout, TimeUnit unit)

复制代码

 

Semaphore数据结构

Semaphore的UML类图如下:

从图中可以看出:
(01) 和"ReentrantLock"一样,Semaphore也包含了sync对象,sync是Sync类型;而且,Sync是一个继承于AQS的抽象类。
(02) Sync包括两个子类:"公平信号量"FairSync 和 "非公平信号量"NonfairSync。sync是"FairSync的实例",或者"NonfairSync的实例";默认情况下,sync是NonfairSync(即,默认是非公平信号量)。

 

Semaphore源码分析(基于JDK1.7.0_40)

Semaphore完整源码(基于JDK1.7.0_40)

 View Code

Semaphore是通过共享锁实现的。根据共享锁的获取原则,Semaphore分为"公平信号量"和"非公平信号量"。


"公平信号量"和"非公平信号量"的区别

"公平信号量"和"非公平信号量"的释放信号量的机制是一样的!不同的是它们获取信号量的机制线程在尝试获取信号量许可时,对于公平信号量而言,如果当前线程不在CLH队列的头部,则排队等候;而对于非公平信号量而言,无论当前线程是不是在CLH队列的头部,它都会直接获取信号量。该差异具体的体现在,它们的tryAcquireShared()函数的实现不同。

"公平信号量"类

 View Code

"非公平信号量"类

 View Code

下面,我们逐步的对它们的源码进行分析。


1. 信号量构造函数

复制代码

public Semaphore(int permits) {
    sync = new NonfairSync(permits);
}

public Semaphore(int permits, boolean fair) {
    sync = fair ? new FairSync(permits) : new NonfairSync(permits);
}

复制代码

从中,我们可以信号量分为“公平信号量(FairSync)”和“非公平信号量(NonfairSync)”。Semaphore(int permits)函数会默认创建“非公平信号量”。


2. 公平信号量获取和释放

2.1 公平信号量的获取
Semaphore中的公平信号量是FairSync。它的获取API如下:

复制代码

public void acquire() throws InterruptedException {
    sync.acquireSharedInterruptibly(1);
}

public void acquire(int permits) throws InterruptedException {
    if (permits < 0) throw new IllegalArgumentException();
    sync.acquireSharedInterruptibly(permits);
}

复制代码

信号量中的acquire()获取函数,实际上是调用的AQS中的acquireSharedInterruptibly()。

 

acquireSharedInterruptibly()的源码如下:

复制代码

public final void acquireSharedInterruptibly(int arg)
        throws InterruptedException {
    // 如果线程是中断状态,则抛出异常。
    if (Thread.interrupted())
        throw new InterruptedException();
    // 否则,尝试获取“共享锁”;获取成功则直接返回,获取失败,则通过doAcquireSharedInterruptibly()获取。
    if (tryAcquireShared(arg) < 0)
        doAcquireSharedInterruptibly(arg);
}

复制代码

 

Semaphore中”公平锁“对应的tryAcquireShared()实现如下:

复制代码

protected int tryAcquireShared(int acquires) {
    for (;;) {
        // 判断“当前线程”是不是CLH队列中的第一个线程线程,
        // 若是的话,则返回-1。
        if (hasQueuedPredecessors())
            return -1;
        // 设置“可以获得的信号量的许可数”
        int available = getState();
        // 设置“获得acquires个信号量许可之后,剩余的信号量许可数”
        int remaining = available - acquires;
        // 如果“剩余的信号量许可数>=0”,则设置“可以获得的信号量许可数”为remaining。
        if (remaining < 0 ||
            compareAndSetState(available, remaining))
            return remaining;
    }
}

复制代码

说明:tryAcquireShared()的作用是尝试获取acquires个信号量许可数。
对于Semaphore而言,state表示的是“当前可获得的信号量许可数”。

 

下面看看AQS中doAcquireSharedInterruptibly()的实现:

复制代码

private void doAcquireSharedInterruptibly(long arg)
    throws InterruptedException {
    // 创建”当前线程“的Node节点,且Node中记录的锁是”共享锁“类型;并将该节点添加到CLH队列末尾。
    final Node node = addWaiter(Node.SHARED);
    boolean failed = true;
    try {
        for (;;) {
            // 获取上一个节点。
            // 如果上一节点是CLH队列的表头,则”尝试获取共享锁“。
            final Node p = node.predecessor();
            if (p == head) {
                long 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()会使当前线程一直等待,直到当前线程获取到共享锁(或被中断)才返回。
(01) addWaiter(Node.SHARED)的作用是,创建”当前线程“的Node节点,且Node中记录的锁的类型是”共享锁“(Node.SHARED);并将该节点添加到CLH队列末尾。关于Node和CLH在"Java多线程系列--“JUC锁”03之 公平锁(一)"已经详细介绍过,这里就不再重复说明了。
(02) node.predecessor()的作用是,获取上一个节点。如果上一节点是CLH队列的表头,则”尝试获取共享锁“。
(03) shouldParkAfterFailedAcquire()的作用和它的名称一样,如果在尝试获取锁失败之后,线程应该等待,则返回true;否则,返回false。
(04) 当shouldParkAfterFailedAcquire()返回ture时,则调用parkAndCheckInterrupt(),当前线程会进入等待状态,直到获取到共享锁才继续运行。
doAcquireSharedInterruptibly()中的shouldParkAfterFailedAcquire(), parkAndCheckInterrupt等函数在"Java多线程系列--“JUC锁”03之 公平锁(一)"中介绍过,这里也就不再详细说明了。


2.2 公平信号量的释放

Semaphore中公平信号量(FairSync)的释放API如下:

复制代码

public void release() {
    sync.releaseShared(1);
}

public void release(int permits) {
    if (permits < 0) throw new IllegalArgumentException();
    sync.releaseShared(permits);
}

复制代码

信号量的releases()释放函数,实际上是调用的AQS中的releaseShared()。

 

releaseShared()在AQS中实现,源码如下:

复制代码

public final boolean releaseShared(int arg) {
    if (tryReleaseShared(arg)) {
        doReleaseShared();
        return true;
    }
    return false;
}

复制代码

说明:releaseShared()的目的是让当前线程释放它所持有的共享锁。
它首先会通过tryReleaseShared()去尝试释放共享锁。尝试成功,则直接返回;尝试失败,则通过doReleaseShared()去释放共享锁。

 

Semaphore重写了tryReleaseShared(),它的源码如下:

复制代码

protected final boolean tryReleaseShared(int releases) {
    for (;;) {
        // 获取“可以获得的信号量的许可数”
        int current = getState();
        // 获取“释放releases个信号量许可之后,剩余的信号量许可数”
        int next = current + releases;
        if (next < current) // overflow
            throw new Error("Maximum permit count exceeded");
        // 设置“可以获得的信号量的许可数”为next。
        if (compareAndSetState(current, next))
            return true;
    }
}

复制代码

 

如果tryReleaseShared()尝试释放共享锁失败,则会调用doReleaseShared()去释放共享锁。doReleaseShared()的源码如下:

复制代码

private void doReleaseShared() {
    for (;;) {
        // 获取CLH队列的头节点
        Node h = head;
        // 如果头节点不为null,并且头节点不等于tail节点。
        if (h != null && h != tail) {
            // 获取头节点对应的线程的状态
            int ws = h.waitStatus;
            // 如果头节点对应的线程是SIGNAL状态,则意味着“头节点的下一个节点所对应的线程”需要被unpark唤醒。
            if (ws == Node.SIGNAL) {
                // 设置“头节点对应的线程状态”为空状态。失败的话,则继续循环。
                if (!compareAndSetWaitStatus(h, Node.SIGNAL, 0))
                    continue;
                // 唤醒“头节点的下一个节点所对应的线程”。
                unparkSuccessor(h);
            }
            // 如果头节点对应的线程是空状态,则设置“文件点对应的线程所拥有的共享锁”为其它线程获取锁的空状态。
            else if (ws == 0 &&
                     !compareAndSetWaitStatus(h, 0, Node.PROPAGATE))
                continue;                // loop on failed CAS
        }
        // 如果头节点发生变化,则继续循环。否则,退出循环。
        if (h == head)                   // loop if head changed
            break;
    }
}

复制代码

说明:doReleaseShared()会释放“共享锁”。它会从前往后的遍历CLH队列,依次“唤醒”然后“执行”队列中每个节点对应的线程;最终的目的是让这些线程释放它们所持有的信号量。

 

3 非公平信号量获取和释放

Semaphore中的非公平信号量是NonFairSync。在Semaphore中,“非公平信号量许可的释放(release)”与“公平信号量许可的释放(release)”是一样的。
不同的是它们获取“信号量许可”的机制不同,下面是非公平信号量获取信号量许可的代码。

非公平信号量的tryAcquireShared()实现如下:

protected int tryAcquireShared(int acquires) {
    return nonfairTryAcquireShared(acquires);
}

 

nonfairTryAcquireShared()的实现如下:

复制代码

final int nonfairTryAcquireShared(int acquires) {
    for (;;) {
        // 设置“可以获得的信号量的许可数”
        int available = getState();
        // 设置“获得acquires个信号量许可之后,剩余的信号量许可数”
        int remaining = available - acquires;
        // 如果“剩余的信号量许可数>=0”,则设置“可以获得的信号量许可数”为remaining。
        if (remaining < 0 ||
            compareAndSetState(available, remaining))
            return remaining;
    }
}

复制代码

说明:非公平信号量的tryAcquireShared()调用AQS中的nonfairTryAcquireShared()。而在nonfairTryAcquireShared()的for循环中,它都会直接判断“当前剩余的信号量许可数”是否足够;足够的话,则直接“设置可以获得的信号量许可数”,进而再获取信号量。
而公平信号量的tryAcquireShared()中,在获取信号量之前会通过if (hasQueuedPredecessors())来判断“当前线程是不是在CLH队列的头部”,是的话,则返回-1。 

 

Semaphore示例

复制代码

 1 import java.util.concurrent.ExecutorService; 
 2 import java.util.concurrent.Executors; 
 3 import java.util.concurrent.Semaphore; 
 4 
 5 public class SemaphoreTest1 { 
 6     private static final int SEM_MAX = 10;
 7     public static void main(String[] args) { 
 8         Semaphore sem = new Semaphore(SEM_MAX);
 9         //创建线程池
10         ExecutorService threadPool = Executors.newFixedThreadPool(3);
11         //在线程池中执行任务
12         threadPool.execute(new MyThread(sem, 5));
13         threadPool.execute(new MyThread(sem, 4));
14         threadPool.execute(new MyThread(sem, 7));
15         //关闭池
16         threadPool.shutdown();
17     }
18 }
19 
20 class MyThread extends Thread {
21     private volatile Semaphore sem;    // 信号量
22     private int count;        // 申请信号量的大小 
23 
24     MyThread(Semaphore sem, int count) {
25         this.sem = sem;
26         this.count = count;
27     }
28 
29     public void run() {
30         try {
31             // 从信号量中获取count个许可
32             sem.acquire(count);
33 
34             Thread.sleep(2000);
35             System.out.println(Thread.currentThread().getName() + " acquire count="+count);
36         } catch (InterruptedException e) {
37             e.printStackTrace();
38         } finally {
39             // 释放给定数目的许可,将其返回到信号量。
40             sem.release(count);
41             System.out.println(Thread.currentThread().getName() + " release " + count + "");
42         }
43     }
44 }

复制代码

(某一次)运行结果:

pool-1-thread-1 acquire count=5
pool-1-thread-2 acquire count=4
pool-1-thread-1 release 5
pool-1-thread-2 release 4
pool-1-thread-3 acquire count=7
pool-1-thread-3 release 7

结果说明:信号量sem的许可总数是10个;共3个线程,分别需要获取的信号量许可数是5,4,7。前面两个线程获取到信号量的许可后,sem中剩余的可用的许可数是1;因此,最后一个线程必须等前两个线程释放了它们所持有的信号量许可之后,才能获取到7个信号量许可。

<think>嗯,用户想比较令牌桶算法JavaSemaphore的区别。首先需要理解两者的核心机制。令牌桶算法属于限流算法,通过固定速率生成令牌来控制请求处理速率,允许突发流量。而SemaphoreJava并发工具,基于计数器控制同时访问资源的线程数,不涉及时间概念。 用户可能正在设计高并发系统,需要选择合适的流量控制方案。从引用材料看,令牌桶适合需要平滑突发流量的场景(如API限流),而Semaphore更适合资源池管理(如数据库连接池)。用户可能混淆了"限流""并发控制"这两个相似但不同的概念。 需要重点区分三点:第一是时间维度,令牌桶依赖时间窗口,Semaphore只关注数量;第二是突发处理,令牌桶允许短时超额,Semaphore严格按许可数执行;第三是用途差异,令牌桶侧重保护下游系统,Semaphore侧重资源隔离。 用户提供的引用很有价值,特别是引用[3]提到令牌桶允许突发传输,引用[2]展示Semaphore实现线程限流的代码。可以结合这些例子说明:用Semaphore实现类似令牌桶功能需要额外增加时间维度计算(如引用[5]的等待时间计算),而原生令牌桶实现(如Guava的RateLimiter)更简洁。 最后要提醒实际应用场景的区别。当用户需要应对秒杀场景的瞬间流量时,令牌桶是更优解;当控制数据库连接这类稀缺资源时,Semaphore更合适。用户可能还需要考虑分布式环境下的实现差异,不过当前问题聚焦在单机层面。</think>以下是令牌桶算法与Java Semaphore的详细对比,结合核心区别应用场景分析: --- ### **一、工作机制对比** | **特性** | **令牌桶算法** | **Java Semaphore** | |----------------------|----------------------------------------|-------------------------------------| | **核心原理** | 固定速率生成令牌,桶满丢弃新令牌 | 基于计数器的许可证机制 | | **时间维度** | 依赖时间窗口(令牌生成速率) | 无时间概念,仅关注许可证数量 | | **突发流量处理** | ✅ 允许消耗积攒的令牌应对突发 | ❌ 严格按许可证数量控制,无突发能力 | | **底层实现** | 需独立实现时间调度(如定时器) | 基于AQS队列的线程阻塞/唤醒 | --- ### **二、关键差异点解析** 1. **时间敏感度** - **令牌桶**:令牌生成速率(如 `10个/秒`)是核心参数,例如Guava的 `RateLimiter`。 ```java RateLimiter limiter = RateLimiter.create(10.0); // 每秒10令牌 ``` - **Semaphore**:仅控制并发数量(如 `new Semaphore(5)` 允许5线程同时执行),不涉及时间单位。 2. **突发流量适应性** - **令牌桶**:若桶容量=100,即使长时间无请求,后续可瞬间处理100个请求(突发)。 - **Semaphore**:许可证数量固定。若 `permits=5`,第6个请求必须等待前5个释放许可证[^3]。 3. **资源分配策略** - **令牌桶**:请求消耗令牌,令牌不足时直接拒绝或等待。 - **Semaphore**:线程通过 `acquire()` 阻塞等待许可证,或使用 `tryAcquire()` 非阻塞尝试[^2]。 --- ### **三、典型应用场景** | **场景** | **推荐方案** | **原因** | |------------------------|-------------------|----------------------------------------| | API接口限流(QPS控制) | ✅ 令牌桶 | 精准控制单位时间请求量,允许突发 | | 数据库连接池管理 | ✅ Semaphore | 直接限制并发连接数,无需时间维度 | | 秒杀系统流量削峰 | ✅ 令牌桶 | 平滑突发请求,避免服务崩溃 | | 线程池任务调度控制 | ✅ Semaphore | 防止任务堆积导致资源耗尽 | --- ### **四、代码实现对比** #### **令牌桶简化实现(核心逻辑)** ```java class TokenBucket { private int tokens; private final int capacity; private long lastRefillTime; private final double refillRate; // 令牌/毫秒 public synchronized boolean tryConsume() { refillTokens(); // 基于时间差补充令牌 if (tokens > 0) { tokens--; return true; } return false; } } ``` #### **Semaphore限流示例** ```java Semaphore semaphore = new Semaphore(5); // 最大5并发 executor.submit(() -> { semaphore.acquire(); // 阻塞直到获取许可 try { // 执行业务逻辑 } finally { semaphore.release(); } }); ``` --- ### **五、如何选择?** - **选令牌桶当**:需控制**速率+允许突发**(如网络流量整形、API限流)[^3][^4]。 - **选Semaphore当**:只需控制**最大并发数**(如资源池管理、线程隔离)[^2]。 > 💡 **关键洞察**:令牌桶本质是**时间感知的速率限制器**,Semaphore本质是**并发资源计数器**。两者解决不同维度的问题,实际中可组合使用(如用Semaphore实现桶容量限制)[^5]。 ---
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值