Java并发编程中的信号量与资源控制

该用 Semaphore 而不是 synchronized 时：需限制同时访问资源的线程数量（如连接池、限流），而非仅互斥；synchronized 无法表达“最多 N 个”，且不支持超时、公平性、非阻塞获取等特性。

什么时候该用 Semaphore 而不是 synchronized

当你要限制「同时访问某类资源的线程数量」，而不是「同一时刻只允许一个线程进入某段代码」时，Semaphore 才是正确选择。比如连接池最多 10 个数据库连接、API 调用限流每秒 5 次、文件句柄复用控制等——这些都不是“互斥”，而是“配额”。synchronized 或 ReentrantLock 只能做二元控制（有/无），没法表达“最多 N 个”。

常见错误现象：
- 用 synchronized 包裹整个资源获取逻辑，导致吞吐量暴跌，明明有 8 个空闲连接却只能串行等待；
- 把 Semaphore 的 acquire() 放在 try 块里，没配对 release()，造成许可证永久泄漏。

• 许可数设为 1 的 Semaphore ≠ synchronized：前者不保证可重入，后者默认可重入
• 构造时传 true 表示公平模式（FIFO 等待队列），但会降低吞吐，仅在必须避免饥饿时启用
• tryAcquire(long timeout, TimeUnit unit) 是防止无限阻塞的关键，尤其在外部依赖超时场景下必须用

Semaphore 的正确释放姿势

许可证必须在资源使用结束后、且无论是否异常都确保归还。最安全的方式是把 release() 放在 finally 块里，且要检查是否真的成功 acquire() 了——因为 tryAcquire() 可能返回 false，此时调用 release() 会抛 IllegalMonitorStateException。

Semaphore sem = new Semaphore(3);
boolean acquired = false;
try {
    acquired = sem.tryAcquire(1, TimeUnit.SECONDS);
    if (!acquired) {
        throw new RuntimeException("资源不可用");
    }
    // 使用受控资源
    doSomething();
} finally {
    if (acquired) {
        sem.release(); // 必须加条件判断
    }
}

与 ThreadPoolExecutor 配合时的典型陷阱

很多人用 Semaphore 控制线程池提交任务的并发度，但容易忽略：线程池本身已有队列和拒绝策略，和信号量叠加后行为变得难预测。例如 FixedThreadPool(5) + Semaphore(3)，看起来最多 3 个任务运行，实际可能有 5 个线程在跑（信号量只管 acquire/release，不管线程生命周期）。

• 真正想控的是「执行中任务数」，应优先考虑 ThreadPoolExecutor 的 getActiveCount() + 自定义拒绝策略，而非* Semaphore
• 若必须组合使用，确保 acquire() 在任务 真正开始执行前（比如在 Runnable.run() 开头），而不是提交时
• Semaphore 不感知线程中断，acquireInterruptibly() 才响应 Thread.interrupt()，异步任务中别漏掉这个

性能与监控：许可证耗尽时你在等什么

Semaphore 本身开销极小，但许可证争用严重时，线程会在 AQS 队列里自旋+挂起，表现为 CPU 升高或大量线程处于 WAITING 状态。这时候光看 Semaphore 对象没用，得结合 JVM 线程堆栈和许可剩余数诊断。

立即学习“Java免费学习笔记（深入）”；

• 用 sem.availablePermits() 定期采样，低于阈值时告警（比如持续 5 秒
• 通过 sem.getQueueLength() 查看当前阻塞线程数，突然飙升说明下游资源瓶颈已暴露
• 注意：这两个方法都不加锁，返回的是瞬时快照，不能用于业务逻辑判断

信号量不是银弹，它把资源竞争从“代码段”转移到了“许可证”，而许可证的分配逻辑本身又依赖底层同步机制。真正难的从来不是怎么写 acquire/release，而是确定那个数字 N —— 它得经压测验证，还得随部署环境动态调整。