Semaphore是Java中用于精准控制同时执行业务逻辑的线程数量的并发控制器，而非QPS限流器；它适用于同步阻塞型接口，需配合非公平模式、超时获取、finally释放及退避降级策略使用。
Semaphore 在 Java 多线程中不是“限流器”，而是并发数控制器——它限制的是同一时刻正在执行业务逻辑的线程数量，而非每秒请求数（QPS）。用对了能保护下游资源（如数据库连接、本地缓存写入），用错了反而引发线程池耗尽、响应延迟飙升甚至雪崩。关键不在“能不能用”，而在“怎么匹配真实场景”。
明确适用前提：只适合同步阻塞型接口
你的接口必须满足：请求进来后，整个处理流程（含远程调用、DB 操作、计算）都在同一线程内完成，且不跨线程回调或异步调度。
- ✅ 合适：Spring MVC + Tomcat 默认同步模型、传统 Servlet 接口
- ❌ 不合适：Spring WebFlux、Vert.x、gRPC 异步服务；或用了 CompletableFuture、@Async 的接口——此时 acquire() 可能阻塞在 IO 线程上，拖垮整个容器线程池
- ⚠️ 警惕：接口平均耗时低于 5ms 时，Semaphore 自身的 CAS 开销可能成为瓶颈，得不偿失
正确初始化与获取方式
别依赖默认，显式声明非公平模式 + 超时尝试，避免无限等待和长尾延迟。
- 用 new Semaphore(20, false)，而非
new Semaphore(20)或new Semaphore(20, true)；公平模式吞吐下降 30%~50%，高并发下容易卡住个别请求 - 永远用
tryAcquire(100, TimeUnit.MILLISECONDS)，而不是acquire()；超时时间建议设为接口 P99 响应时间的 1.2~1.5 倍 - 许可数不能拍脑袋定：先压测，观察 DB 连接池使用率、CPU 利用率、GC 频次，逐步调到资源不打满但吞吐最优的值
必须配对 release，且放在 finally 块里
许可泄漏是 Silent Killer：一旦某次异常没 catch 到、或 release 被跳过，剩余许可数永久减少，Semaphore 会逐渐变成“空转红灯”，所有新请求直接失败，监控却无明显指标异常。
立即学习“Java免费学习笔记（深入）”；
- release() 必须写在 try-finally 最外层，哪怕业务逻辑抛出 RuntimeException 也要确保执行
- 不要在异步回调里 release —— 如果业务逻辑启动了新线程或 Future，务必把 release 移到回调完成处，否则主线程 release 就算错
- 可加轻量日志：每次 acquire 成功/失败、release 前后打点，配合 ELK 快速定位泄漏点
结合降级做阶梯式响应
单纯拒绝请求（429）体验差。更合理的方式是：获取失败 → 短暂退避 → 再试一次 → 仍失败则走降级路径（返回缓存、兜底数据、空响应）。
- 第一次 tryAcquire 失败后，调用
getBackoffDelay()获取退避毫秒数（比如 50ms → 100ms → 200ms 逐级上升） - 用
Thread.sleep(backoffMs)后再次 tryAcquire；最多重试 2 次，否则直接降级 - 降级逻辑要独立于主流程：比如查缓存失败就返回预置 JSON，不依赖任何外部服务，保证链路绝对可靠
不复杂但容易忽略。核心就四条：匹配同步模型、非公平+超时获取、finally 里 release、失败后带退避的降级。做对这几点，Semaphore 就能稳稳托住你的核心接口，而不是悄悄埋下雪崩引信。
