semaphore仅控制瞬时并发数，不支持时间窗口限流；适用于单机临界资源保护，需确保释放进finally、使用带超时tryacquire、许可获取贴近真实耗时操作，且多实例需分布式方案替代。
Semaphore 本身不防洪，它只管“此刻有几个在跑”，不管“这一秒来了多少”。想用它做时间窗口限流（比如每秒最多100次），会失效；但它做单机并发控制轻量、高效、零依赖。
明确它的能力边界：控并发，不控频次
信号量本质是计数器型许可池，没有时间维度。new Semaphore(5) 表示最多5个线程能同时执行——这5个可能是1毫秒内涌进来的，也可能是5分钟内陆续进来的。它适合的场景是：
- 保护本地有限资源：数据库连接池、文件句柄、CPU密集型任务槽位
- 下游系统有明确并发上限：比如老核心接口只支持8路并发
- 后台定时任务导出、批量处理等低频但需防堆积的场景
- 单机部署、无横向扩缩容需求的服务
三处必须写对，否则线上容易出问题
生产环境90%的 Semaphore 问题，都出在这三点没落实：
- 释放必须进 finally：acquire() 后一旦业务抛异常，没 release() 就等于许可证永久丢失。正确写法是 try-finally 包裹业务逻辑，release() 放在 finally 块里
- Web 接口禁用无超时 acquire()：阻塞式获取会让 Tomcat 线程卡住，拖垮整个容器。应改用 tryAcquire(1, 100, MILLISECONDS)，超时直接返回 429
- 许可获取点要贴近真实耗时操作：不要在 Controller 入口就 acquire，而应在调用第三方 API 或执行 DB 查询前才拿许可——避免空转占坑
公平模式通常没必要，非公平更合适
默认构造 new Semaphore(10) 是非公平模式，允许后来线程插队抢到刚释放的许可，吞吐更高；公平模式（new Semaphore(10, true)）强制 FIFO 队列，降低吞吐、增加延迟。除极少数要求严格请求顺序的审计类场景，其余都用非公平。
限流+熔断可组合，但不是内置能力
Semaphore 不直接支持熔断，但可以和失败率统计配合使用：比如维护一个失败计数器，连续失败超过阈值就切换为“熔断态”，拒绝所有 acquire 请求；恢复期再逐步放行。这种组合形成简易双控机制，适用于单机场景，但不支持分布式自适应调整。
