必须用 tryacquire 而非 acquire，因 acquire 会无限阻塞导致线程饥饿和服务雪崩；tryacquire 非阻塞，配合合理超时（p90×1.2–1.5）和 finally 中强制 release，可实现可控降级与防泄漏。
为什么不用 acquire 而必须用 tryAcquire
因为 acquire 会无限阻塞，下游慢查询一旦卡住（比如数据库响应延迟突增到 5s+），上游线程池就会被迅速占满，进而引发线程饥饿、HTTP 连接超时、甚至整个服务不可用。而 tryAcquire 是非阻塞的——它只看当前有没有空闲许可，有就拿，没有就立刻返回 false，给你留出做降级决策的空间。
如何配置 tryAcquire 的超时与降级路径
直接用无参 tryAcquire() 容易误判：下游只是稍慢（比如 300ms），但许可刚好被占满，就粗暴拒绝；更稳妥的是带超时的 tryAcquire(long timeout, TimeUnit unit)，给一个合理等待窗口（比如 200ms），既避免长阻塞，又容忍轻微抖动。
- 超时值建议设为下游接口 P90 响应时间的 1.2–1.5 倍，不是拍脑袋定 1s
- 超时后必须明确走降级逻辑：返回缓存结果、兜底文案、空数据，或抛
ServiceUnavailableException - 绝不能在
catch (InterruptedException)里吞掉中断状态，要立即调用Thread.currentThread().interrupt()
release 必须放在 finally 块里，且不能依赖业务成功与否
许可证泄漏是 Semaphore 最隐蔽也最致命的问题。只要 tryAcquire 成功了，哪怕后续业务抛异常、IO 失败、甚至 JVM crash，都必须确保 release 执行。否则几轮请求后，所有许可都被“悬空”，整个限流器就彻底失效。
-
release必须写在finally块中，和tryAcquire是否成功无关 - 不要把
release放在 if 分支里（比如只在 success == true 时 release） - 如果业务逻辑里还嵌套了其他需要释放的资源（如 DB 连接、文件句柄），
release要和它们平级，不互相依赖
公平性开关对降级稳定性的影响
默认非公平模式下，新请求可能插队抢走刚释放的许可，导致慢请求反复被挤掉；而开启公平模式（new Semaphore(permits, true)）会让请求严格按 FIFO 排队，虽然吞吐略低，但在下游不稳定时能更好控制尾部延迟、避免饥饿。
- 如果你的下游慢查询本身就有明显长尾（比如 P99 是 2s，P90 是 300ms），建议开公平模式
- 公平模式下，
tryAcquire(timeout, unit)的超时判断仍有效，不会因排队而无限等 - 别在运行时动态切换公平性，构造时定死即可
tryAcquire 返回 false 并不等于“系统扛不住”，它只说明此刻并发已满。真正需要关注的是单位时间内 false 的比例是否持续高于阈值（比如 >5%），这才是触发告警或自动扩容的信号点。
