new Semaphore(1) 不等于 synchronized，因前者基于可配置许可数、支持超时与批量获取，后者基于独占monitor机制；关键差异在于资源建模方式与线程协作模型。
为什么 new Semaphore(1) 不等于 synchronized
因为 Semaphore 控制的是「许可数量」，不是「锁对象」。即使设为 1，多个线程仍可能同时调用 acquire() 并阻塞等待，而 synchronized 是基于 monitor 的独占进入机制，不排队、不累积许可。
关键区别在于：Semaphore 允许提前预占（比如 tryAcquire(1, 1, TimeUnit.SECONDS)），也支持一次性获取多个许可（acquire(3)），而 synchronized 没有超时、不可重入计数、也不支持批量。
acquire() 和 tryAcquire() 的实际选择场景
真实业务里几乎总是该用 tryAcquire()，尤其涉及外部依赖或 SLA 要求时——否则一个卡住的线程可能拖垮整个许可池。
常见误用：acquire() 在无界等待下导致线程饥饿，或在 Spring 容器中因未释放许可引发连接池耗尽。
-
acquire()：仅适用于你**完全掌控下游响应时间**的场景（如纯内存计算、本地缓存读写） -
tryAcquire(long timeout, TimeUnit unit)：推荐用于 HTTP 调用、DB 查询、消息发送等不确定延迟的操作 - 永远配对使用
release()，建议放在finally块里，哪怕用了tryAcquire()成功后也要确保释放
permit 数量设多少才合理？
不能只看 CPU 核数或连接池大小。真正决定上限的是「下游瓶颈资源」的并发承载能力。比如调第三方 API，对方限流 100 QPS，你设 new Semaphore(100) 没用——如果单次请求平均耗时 2 秒，那理论最大并发只有 100 / 2 = 50 左右；再高就会触发对方熔断或 429 错误。
- 先压测确定下游稳定吞吐拐点（例如：并发 30 时 P99=120ms，到 35 就跳到 800ms）→ 取略低于拐点的值（如 28）
- 动态调整比硬编码更可靠：可结合
MetricRegistry或 Micrometer 监控getQueueLength()，自动缩放 permit - 注意：
availablePermits()返回的是当前空闲许可数，不是初始值；别拿它做初始化判断
释放许可时最常见的三个坑
绝大多数 Semaphore 相关故障都发生在 release() 阶段，不是没调，就是多调、少调、错线程调。
立即学习“Java免费学习笔记（深入）”；
- 在异步回调中释放：比如用
CompletableFuture提交任务后，在thenAccept里release()—— 此时很可能已脱离原许可获取线程，但Semaphore不校验线程归属，所以能执行，但逻辑上已错乱 - 异常分支遗漏
release()：尤其在tryAcquire()成功后，后续代码抛异常却没进finally - 重复释放：比如在重试逻辑里，每次重试都
release()一次，导致许可数暴涨，突破限制
try {
if (!semaphore.tryAcquire(1, 3, TimeUnit.SECONDS)) {
throw new RuntimeException("acquire timeout");
}
// do work...
} finally {
// 必须在这里 release，且只 release 一次
semaphore.release();
}
Semaphore 的核心不是“控制数量”，而是“显式建模资源边界”。一旦把 permit 当作魔法数字硬编码，就失去了它本该提供的可观测性与弹性调控能力。 
