semaphore 不适合 web 接口限流，因其仅为单机 jvm 内并发控制，多实例部署下限流失效；易因未释放、跨线程调用或异常中断导致许可证泄漏；阻塞式 acquire() 会耗尽 web 容器线程池，应优先使用带超时的 tryacquire() 快速失败。
为什么 Semaphore 不适合直接用在 Web 接口限流上
它本身不是为跨请求、跨线程池的分布式场景设计的。Java 的 Semaphore 是 JVM 进程内对象，每个实例只对当前 JVM 有效；如果你用的是多实例部署（比如 Spring Boot 打成 jar 跑了 3 个节点），那每个节点都持有一个独立的 Semaphore，实际总并发会变成「单节点限制 × 实例数」，完全失效。
常见错误现象：IllegalStateException: Semaphore acquired but not released 或接口压测时 QPS 明显超出预期——往往是因为没配全局唯一实例，或忘了在 finally 块里 release()。
- 必须确保
Semaphore是单例且生命周期与应用一致（比如 Spring 中声明为@Bean） - 不能在异步线程（如
CompletableFuture、@Async）里 acquire 后在主线程 release，必须同一线程配对 - HTTP 请求超时、异常中断时，
acquire()成功但没走到release()，会导致许可证永久泄漏
Semaphore.tryAcquire() 比 acquire() 更适合接口限流
阻塞式 acquire() 会让线程挂起，Web 容器线程池（如 Tomcat 的 maxThreads）很快被耗尽，用户看到的是整体响应变慢甚至 503，而不是精准限流。而 tryAcquire() 可立即返回布尔值，配合 HTTP 状态码控制更可控。
使用场景：需要快速失败、返回 429 Too Many Requests，而非让用户干等。
- 推荐加超时：
semaphore.tryAcquire(1, 100, TimeUnit.MILLISECONDS)，避免瞬时毛刺导致全部排队 - 不要用
tryAcquire()不带参数的重载——它不等，抢不到就 false，对突发流量太敏感，容易误伤正常请求 - 如果业务逻辑本身耗时长（比如调第三方 API），建议把
tryAcquire()放在真正要受控的临界区前，而不是 Controller 入口——否则空转也占着许可证
和 Redis + Lua 做分布式限流比，Semaphore 的真实适用边界在哪
它只在单机、无水平扩展、且对精度要求不高的内部服务中能用。比如一个定时任务触发的后台导出接口，QPS 不超过 5，又不想引入 Redis 依赖，这时 Semaphore 是轻量解法。
性能影响几乎为零，兼容性无问题（JDK 5+ 都支持），但代价是：无法做滑动窗口、无法按用户/租户维度隔离、无法持久化统计。
- 别试图用
Semaphore实现「每分钟最多 100 次」——它没有时间维度，只能控并发数，不是控频次 - 如果用了 Spring Cloud Gateway 或 Nginx，优先在网关层用
redis-rate-limiter或limit_req，别下沉到业务代码里重复造轮子 - 测试时记得模拟线程竞争：用 JMeter 并发 200 线程打一个
tryAcquire()限 10 的接口，观察 true/false 比例是否符合预期
Spring 中注入 Semaphore 的两个关键配置点
不是 new 出来就行，得让它能参与 Spring 生命周期管理，并避开 AOP 代理陷阱。
错误写法：new Semaphore(10) 写在 Controller 里——每次请求新建，彻底失效。
- 声明为
@Bean时加上@Scope(ConfigurableBeanFactory.SCOPE_SINGLETON)，避免被误设成 prototype - 如果类被
@Async或事务代理，不要把acquire()/release()放在被代理的方法里——CGLIB 代理可能绕过你的 try-finally，改用TaskDecorator或手动传入Semaphore实例 - 考虑用
Resilience4j的RateLimiter替代：它底层可选 Semaphore，但封装了自动 cleanup、指标暴露、配置中心集成，复杂度上升不多，鲁棒性高一截
acquire() 和 release() 很难严格成对。真要压稳，得靠日志埋点+定期 dump Semaphore.availablePermits() 值来验证。
