Semaphore 管理“许可”而非权限，核心在于许可数贴合下游容量、包围范围精准、释放逻辑兜底；需动态调整、超时获取、finally 释放，并可结合失败统计实现简易熔断。

Semaphore 不是分配“权限”，而是管理“许可”——它通过一个可配置的计数器，控制同一时刻能进入临界区的线程数量。真正有效的并发控制，不靠堆参数，而靠三点：许可数设得准、包围范围缩得小、释放逻辑兜得住。

许可数要贴着下游资源容量设

初始 permits 值不能拍脑袋定。设太小，资源闲置、吞吐上不去；设太大，形同虚设，可能压垮 DB 连接池或第三方接口。

• 参考依据优先用下游实际承载力：比如数据库连接池最大为 20，Semaphore 可设 15～18，留出缓冲余量应对偶发抖动
• 秒杀场景下，许可数 ≠ 库存数——库存扣减是非原子操作，必须配合数据库行锁或 CAS 才能防超卖，仅靠 Semaphore 无法保证一致性
• 动态调整比静态配置更稳：可通过监控 availablePermits() + 失败率指标，在运行时自动升降许可阈值

acquire/release 必须精准包围耗资源动作

许可不该被轻量逻辑占用。把 acquire 放在 Controller 入口，等于让参数校验、日志打印也抢占许可，白白浪费并发能力。

• 正确姿势：校验通过后、调用远程服务前 acquire；远程返回后、组装响应前 release
• 避免空转：网络超时、业务异常、熔断降级等路径，都必须确保许可归还，否则一次泄漏就可能引发雪崩
• 典型反例：try 块内 acquire，但 catch 中没 release，或 release 写在 return 后——这些都会导致许可永久丢失

必须带超时 + finally 释放，拒绝“裸调用”

无超时的 acquire() 在下游卡死时会无限阻塞，拖垮整个线程池；不加 finally 的 release() 是生产环境最常见泄漏源头。

• 强制使用 tryAcquire(long timeout, TimeUnit unit)，超时建议 100–300ms，超时返回 false 后可快速降级（如返回缓存、默认值）
• release() 必须放在 finally 块中，哪怕业务逻辑抛 RuntimeException 或 Error，也要保证许可回收
• 禁用 acquireUninterruptibly() 和无参 acquire()：前者屏蔽中断信号，后者无保护机制，都不适合线上高可用场景

用失败统计补足熔断能力

Semaphore 本身不熔断，但可以低成本组合实现简易熔断器，防止故障扩散。

• 用 AtomicInteger 记录 60 秒窗口内的总请求数和失败数
• 当失败率 ≥50% 且总请求数 ≥20，状态切为 OPEN，新请求直接拒绝（跳过 acquire）
• OPEN 持续 30 秒后进 HALF-OPEN，只放行少量试探请求；成功则恢复，失败则重置计时器