semaphore是资源配额控制器而非锁，通过许可计数器控制并发线程数，依赖aqs实现阻塞队列与唤醒，需acquire/release成对调用以防泄漏，并支持动态调优以应对突发流量、平滑扩容与预热启动。
Semaphore 不是锁，而是资源配额控制器。它不保证临界区互斥，只控制“同时能用资源的线程数”。用对了，能稳住秒杀、压测、连接池等关键链路；用错了，轻则限流失效，重则许可泄露、服务雪崩。
核心机制：许可计数器 + 阻塞队列
信号量本质是一个带状态的整数计数器（state），初始值为构造时传入的 permits 数。每次 acquire() 尝试原子性地将计数器减 1；release() 则加 1。当计数器为 0 时，后续 acquire() 会把线程挂起，并加入 AQS 同步队列等待唤醒。
- 计数器归零 ≠ 资源耗尽，只是当前无可用许可；释放操作会触发唤醒逻辑
- 底层依赖 AQS 实现排队与唤醒，公平模式下按 FIFO 分配，非公平模式可能插队
- acquire() 和 release() 必须成对出现，否则会导致许可永久丢失（即“许可泄露”）
限流策略设计要点
单纯设个固定 permits 值远远不够。真实场景中需结合业务节奏动态调节：
- 突发流量应对：初始化时预留冗余许可（如设为峰值预估的 1.5 倍），配合 tryAcquire(timeout) 做超时降级
- 平滑扩容：运行时调用 reducePermits() 缩减许可（如故障熔断），或通过多次 release() 模拟扩容（注意：不能直接增加 state，需先有释放动作）
- 预热启动：初始设为 0，再通过定时任务逐步 release()，避免冷启瞬间打满下游
- 监控联动：定期采集 availablePermits()、getQueueLength()，当排队线程持续 > 50 且可用许可
典型场景落地细节
不同场景对 Semaphore 的使用方式差异很大，关键在“谁获取、何时释放、是否可中断”：
- 数据库连接池：acquire() 放在 getConnection() 入口，release() 必须在 connection.close() 后、finally 块中执行，防止连接未归还导致池饥饿
- 秒杀接口：acquire() 在库存校验前，但 release() 一定要在事务提交/回滚后；否则超卖或死锁风险极高
- 异步协程限流（Python asyncio）：必须用 async with semaphore: 语法，确保即使协程抛异常也能自动释放，避免整个协程池卡死
- 文件批量写入：可批量 acquire(5) 减少同步开销，但对应 release(5) 也必须一次性完成，不可拆分
避坑指南：高频失效原因
很多团队反馈“加了 Semaphore 还是被打垮”，问题往往不在信号量本身，而在使用姿势：
- 忘记在异常路径 release() —— 许可永久泄漏，可用许可逐次归零
- acquire() 后未用 try-finally 包裹 —— 任何中间 throw 都会导致释放逻辑跳过
- 误将 permits 设为库存数 —— 信号量只管并发度，不保证业务原子性，超卖仍会发生
- 混合使用 fair=true 与高吞吐场景 —— 公平模式带来额外队列维护开销，QPS 下降约 15%~20%
