Semaphore 不支持直接修改初始许可数，必须通过原子替换新实例并清空残留许可来安全动态调整，否则会导致许可泄漏、阻塞堆积或限流失效。
Semaphore 本身不支持直接修改初始许可数，所谓“动态调整”必须通过安全替换 + 状态清理的方式实现，否则容易导致许可泄漏或阻塞堆积。
为什么不能直接改 permits 数
Semaphore 构造后，其许可总数是只读的；reducePermits() 和 release(n) 虽然能临时影响计数，但无法真正“扩容”，且可能破坏限流语义：
- reducePermits(n) 只减少可用许可，不能增加；误用会加剧阻塞
- release(n) 可能让许可数超过初始值，等于悄悄放宽限制，失去可控性
- 已有线程长期持有许可（如下游超时未释放），新设置的“逻辑上限”在实际中无法生效
推荐的安全动态调整方式
核心思路：**隔离实例 + 原子替换 + 清空残留**。以服务维度管理 Semaphore 实例，避免全局单例硬编码：
- 用 ConcurrentHashMap<String, Semaphore> 按接口名或场景键隔离，例如：
"user-service-api"、"sms-batch" - 运行时需调整时，先调用 drainPermits() 清空当前剩余许可（不影响已获取许可的线程）
- 再创建新 Semaphore 实例，用 computeIfAbsent() 或显式 put() 替换旧实例
- 旧实例不再被引用后，由 GC 回收；新请求自动使用新许可数
配合监控做弹性扩缩容
动态限流不是拍脑袋调参，而是基于实时指标反馈闭环：
立即学习“Java免费学习笔记（深入）”；
- 定期调用 availablePermits() 获取剩余许可，结合 getQueueLength() 判断排队压力
- 若连续 30 秒
getQueueLength() > 5且错误率上升 → 触发扩容（如 +2 permits） - 若
availablePermits() == 初始值持续 1 分钟 → 说明负载下降，可谨慎缩容 - 熔断场景下，可先 drainPermits() 强制拒绝新请求，再切换为降级 Semaphore(0)
灰度与版本控制建议
上线新策略时避免全量切换风险：
- 对新版本服务分配更高 permits（如 v2 接口设为 8，v1 保持 5），观察稳定性
- 用配置中心（如 Nacos、Apollo）推送 permits 值，应用监听变更并触发上述替换流程
- 替换前记录旧实例的 getQueueLength()，确保无大量线程卡在 acquire 等待中
