该用 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 —— 它得经压测验证，还得随部署环境动态调整。
