在Java中如何使用Semaphore控制并发量_Java信号量类库说明-java教程-PHP中文网

new Semaphore(1) 不等于 synchronized，因前者基于AQS共享锁，支持公平性、可中断、超时等语义，后者是JVM互斥锁，无此特性；调度与唤醒机制也不同。

在java中如何使用semaphore控制并发量_java信号量类库说明

为什么 new Semaphore(1) 不等于 synchronized

因为 Semaphore 是基于 AQS 的共享锁，支持可重入性以外的多种语义：比如公平/非公平策略、可中断的 acquireInterruptibly()、带超时的 tryAcquire(long, TimeUnit)。而 synchronized 是 JVM 层的互斥锁，不可中断、无超时、不支持公平性配置。

更关键的是：Semaphore(1) 允许多个线程排队争抢同一许可，但 synchronized 锁定的是对象监视器，两者调度机制和唤醒逻辑完全不同。实际压测中，高并发下 Semaphore 的排队开销略大，但灵活性远超 synchronized。

如何正确释放 permit 避免泄漏

Semaphore 不像 ReentrantLock 有 lock()/unlock() 的成对强约束，release() 调用错误会导致许可数异常增长，进而破坏限流逻辑。最稳妥的方式是用 try-finally 包裹：

semaphore.acquire();
try {
    // 执行受控操作
} finally {
    semaphore.release(); // 必须放在这里，哪怕抛异常也要归还
}

不要在 catch 块里释放 —— 正常流程也会走到 finally，重复调用 release() 会让许可数超过初始化值
避免在异步回调中释放 —— 若回调执行在线程池不同线程，可能触发 IllegalMonitorStateException（虽然 Semaphore 本身不限制线程，但业务逻辑可能隐含上下文依赖）
调试时可临时加日志：System.out.println("released, available=" + semaphore.availablePermits());

fair 参数对排队行为的实际影响

创建 Semaphore 时传 true 表示启用公平模式：new Semaphore(5, true)。这会让等待线程按 FIFO 顺序获取许可；默认 false 是非公平的，允许后来的线程“插队”抢到刚释放的 permit。

公平模式能减少饥饿，但吞吐量通常下降 10%–20%，尤其在高竞争场景。是否开启取决于业务 SLA 要求：

Java注释规范Skills

当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。

下载