semaphore限流器关键在于许可生命周期可控、异常不泄露、容量可调、行为可预期；其本质是“可用许可数”的原子计数器，需强绑定acquire/release、设合理初始值、支持超时/批量/动态调节、配公平性选择与监控闭环。
用 Semaphore 构建限流器，关键不在“加个 acquire 就完事”，而在于许可生命周期可控、异常不泄露、容量可调、行为可预期。它不是万能开关，而是需要精细配合的并发节流阀门。
限流器核心逻辑：许可即准入资格
信号量本质是“可用许可数”的原子计数器。设 permits = 10，就代表最多 10 个请求能同时进入业务逻辑；第 11 个会阻塞（或超时失败），直到有前序请求调用 release() 归还许可。
- 许可获取必须与业务执行强绑定：acquire() 后立即进 try 块，release() 必须放在 finally 中——哪怕业务抛异常、超时、提前 return，许可也得还回去
- 不要把 permits 设为库存数、余额数等业务状态值：信号量只管“并发数”，不保证业务原子性。秒杀场景中，它防的是 100 人同时查库存+扣减，但查和扣之间仍需加锁或 CAS
- 初始 permits 应基于系统吞吐压测结果设定，而非拍脑袋。例如数据库连接池最大连接数为 20，那对应资源访问的 Semaphore 最好也不超过 20
应对真实流量：超时 + 批量 + 动态调节
生产环境从不只有“理想请求”。你需要让限流器具备弹性响应能力：
-
带超时的获取：用
tryAcquire(1, 300, TimeUnit.MILLISECONDS)替代无脑acquire()。获取失败时可快速降级（返回 429、走缓存、进队列），避免线程长时间挂起 -
批量许可操作：若单次请求需占用多个资源单元（如一次导出要占 3 个线程槽位），直接
acquire(3)比循环调用 3 次更高效，减少 AQS 队列竞争 -
运行时动态调整：通过
reducePermits(n)临时缩容（如监控发现 CPU >90%），或先drainPermits()再release(n)实现扩容，无需重启服务
公平性选择与监控闭环
构造时传入 fair = true 表示按等待顺序分配许可，适合对响应时间一致性要求高的场景（如金融类接口）；默认非公平模式吞吐更高，但可能造成个别请求长期等待。
- 务必暴露监控指标：定期采集
availablePermits()和getQueueLength()（等待线程数），接入 Prometheus 或日志告警。当 availablePermits 长期为 0 且队列持续增长，说明限流阈值已成瓶颈 - 避免“伪限流”：不要在 controller 层 acquire，在 service 层又 acquire 一次——重复扣减许可会导致实际并发远低于预期
- 注意 JVM 级别影响：高并发下大量线程阻塞在 acquire，会推高线程数和 GC 压力。必要时结合 Hystrix 或 Sentinel 做熔断兜底
限流不是挡流量，而是让系统在确定边界内稳住节奏。Semaphore 是轻量可靠的工具，但它的威力，取决于你是否把它用在关键路径上、是否守住释放契约、是否让它真正“看得见、调得动、扛得住”。
