Semaphore限流本质是用许可证硬控并发量：初始化设最大许可数，acquire/release成对用于原子控制；需try-finally保障释放，支持批量许可、超时获取；不同场景需结合单例、连接池、分布式锁等协同。
用 Semaphore 实现限流，本质是把“许可证”当作可并发访问资源的配额。初始化时设定总许可数，就是系统允许的最大并发数；每次业务操作前 acquire，完成后 release，就能硬性卡住并发量——不靠监控、不靠统计，是真正的原子级控制。
初始化信号量：明确最大并发数与公平性
构造时传入的 permits 参数即为最大并发数，不是建议值，而是硬上限：
- 非公平模式（默认）：吞吐高，适合对响应延迟敏感的场景，如 API 网关限流；但极端情况下可能造成个别请求长时间等待。
- 公平模式（传 true）：按等待顺序分配许可，避免饥饿，适合任务耗时差异大、需保障响应可预期的场景，如后台批处理调度。
acquire 与 release 必须成对且受保护
许可泄露是生产事故最常见原因。acquire 后若未释放，可用许可持续减少，最终所有线程阻塞：
- 务必在 try-finally 块中调用 release，确保无论业务逻辑是否抛异常，许可都能归还。
- 避免在 if 分支或 return 前直接 release，容易遗漏路径。
- 不要依赖 GC 或作用域自动清理——Semaphore 不实现 AutoCloseable。
支持批量许可与超时控制
实际业务常需一次占用多个单位资源（如一次下载 3 个分片），或拒绝过久等待：
- 用 acquire(int permits) 申请多个许可，用 release(int permits) 对应释放，保持计数平衡。
- 用 tryAcquire(long timeout, TimeUnit) 设置获取许可的最长等待时间，超时返回 false，可降级或快速失败，防止请求堆积雪崩。
- 避免无超时的 acquire() 在高延迟下游故障时拖垮整个服务链路。
典型限流场景落地要点
不同场景对语义和可靠性要求不同，需针对性设计：
- 接口级限流：信号量实例应全局单例，粒度为接口路径或用户 ID；配合熔断器更稳妥。
- 数据库连接池控制：许可数应 ≤ 连接池最大活跃连接数，否则可能引发连接等待超时而非信号量阻塞，失去限流意义。
- 秒杀库存预占：仅靠 Semaphore 不足以防超卖，必须与数据库乐观锁或分布式锁配合，因 acquire/release 是 JVM 层操作，不保证跨进程一致性。
