semaphore需匹配资源能力、任务特征与系统目标，通过选对模式、设准数量、控住释放、盯紧指标四步实现高效可控并发。
Semaphore不是“越多越好”或“越公平越稳”，而是要匹配资源能力、任务特征和系统目标。选对模式、设准数量、控住释放、盯紧指标，四步就能让并发既高效又可控。
许可数量必须贴合真实资源容量
信号量的许可数不是拍脑袋定的，它本质是后端资源处理能力的映射。设小了，线程排队久、吞吐掉；设大了，资源过载、响应变慢甚至崩溃。
- 数据库连接池场景：许可数 ≈ 连接池最大活跃连接数，不能高于数据库服务端允许的并发连接上限
- CPU密集型任务：参考公式 许可数 ≈ CPU核心数 × (1 + 等待时间 / 计算时间)，避免线程空转争抢CPU
- IO密集型任务（如HTTP调用、文件读写）：可适当放宽，比如设为CPU核心数的2–5倍，但需压测验证
- 动态验证：上线前做阶梯式压测（如5/20/50许可），观察平均等待时间与错误率拐点——表格中50并发下许可从5升到20，等待时间从128ms骤降至18ms，就是典型收益区间
公平性模式要按场景切换，别默认开true
公平模式（new Semaphore(10, true)）保证FIFO排队，适合强顺序要求或防饥饿场景；非公平模式（默认）允许新线程插队，能显著减少CAS失败和上下文切换，吞吐更高。
- 高吞吐短任务（如API网关限流、缓存穿透防护）→ 用非公平模式，吞吐提升15%–30%，延迟波动稍大但可接受
- 关键业务链路（如支付扣款、库存预占）→ 启用公平模式，避免某个请求因持续被插队而超时失败
- 注意：公平模式会增加AQS同步队列维护开销，尤其在高争用下，可能让获取许可的平均耗时上升2–5倍
批量获取+超时控制，减少阻塞风险
单次acquire一个许可，在资源密集型操作中效率低；无超时的阻塞调用，容易引发雪崩。
- 用
acquire(int permits)批量申请，比如一次拿3个许可执行批量DB写入，同步次数减少，上下文切换下降 - 必用
tryAcquire(long timeout, TimeUnit unit)替代无参acquire，设置合理超时（如50–200ms），超时后走降级逻辑（返回缓存、返回默认值、记录告警） - 绝不裸写 acquire() → release()，必须套 try-finally 或 try-with-resources，确保异常时许可不泄漏
运行时监控+弹性调整，让信号量活起来
静态配置扛不住流量峰谷，得靠实时指标驱动动态调优。
- 关键监控项：
availablePermits()（剩余许可）、getQueueLength()（等待线程数）——持续为0且队列长度＞10，说明已成瓶颈 - 支持运行时伸缩：
reducePermits(int reduction)快速缩容，release(int permits)增加可用许可（注意：release本质是“伪造释放”，需确保底层资源真能承载） - 结合Metrics埋点（如Prometheus），当队列长度P99＞5时自动触发扩容脚本，或联动熔断器限流上游
