semaphore是资源配额控制器而非锁，通过许可数限制并发量；需基于瓶颈（如db连接、api频次、内存）精准设值，结合压测与监控调优，并严格配对acquire/release，按场景选择公平性策略。
Semaphore信号量不是“锁”，而是资源配额控制器——它不决定谁先谁后，只决定最多允许多少个线程（或协程）同时通行。用对了，系统扛得住突发流量；设错了，轻则响应变慢，重则线程堆积、OOM或雪崩。
明确你要限什么资源
信号量的价值在于“精准限流”，前提是清楚瓶颈在哪：
- 数据库连接数：许可数应等于连接池最大活跃连接数，避免连接耗尽
- 外部API调用频次：比如每秒最多调用第三方服务5次，就设permits=5，并配合定时释放（如用ScheduledExecutorService周期性release）
- 内存敏感操作：如批量解析大文件，每个任务占用200MB内存，机器总可用堆为2GB，则最多并发4个，设permits=4
- 非核心接口降级保护：把次要接口的permits设小（如2），确保主流程线程不被抢占
许可数不能拍脑袋定
初始值必须基于实测数据和容量模型：
- 参考80/20原则估算峰值QPS：若日PV 1200万，80%集中在20%时间（约4.8小时），则峰值QPS ≈ (1200万 × 0.8) ÷ (4.8 × 3600) ≈ 555
- 单机压测得出极限QPS（比如稳定承载120 QPS），再算所需许可数：555 ÷ 120 ≈ 5 → 取整为5或6（留10%余量）
- 上线后持续观察RT与availablePermits()返回值，若长期接近0且RT上升，说明许可偏少；若长期>80%空闲，说明过度保守
必须配对使用acquire和release
漏释放=许可证永久丢失=后续所有线程阻塞，这是最常见线上故障原因：
- 永远用try-finally包裹临界区，release写在finally里
- Java中推荐用try-with-resources（需封装成AutoCloseable）；Python asyncio中直接用async with更安全
- 避免在acquire后、执行前抛异常导致跳过release——可改用tryAcquire(timeout)做前置校验
- 不要在异步回调里跨线程release，确保acquire和release发生在同一上下文（尤其注意CompletableFuture链式调用）
公平性要按场景选
默认非公平模式吞吐高，但可能让某些请求等太久；公平模式保响应稳定性，代价是轻微性能损失：
- 面向用户接口（如下单、支付）建议用fair=true，防止个别请求排队超时
- 后台批处理、日志聚合等对延迟不敏感的任务，用默认非公平即可
- 可通过availablePermits() + getQueueLength()监控等待队列长度，若持续增长且无下降趋势，需检查是否公平策略+许可不足共同导致饥饿
