Semaphore通过许可计数柔性控流，许可数需匹配资源真实容量并预留缓冲；acquire/release必须成对置于finally块；优先非公平模式；生产环境必须设置超时避免雪崩。
Semaphore 通过“许可计数”机制，从源头上限制并发线程数量，避免资源被争抢、耗尽或过载。它不依赖锁的排他性，而是用可配置的配额来柔性控流——不是不让进，而是按实际承载力决定最多让几个进。
许可数量必须匹配资源真实容量
设 5 个许可，不代表系统能稳住 5 路并发。关键看底层资源瓶颈：
- 数据库连接池最大 20 个连接？建议 Semaphore 许可设为 14～16（70%～80%），留出缓冲应对慢查询或重试
- 硬件设备（如打印机、串口）明确支持 2 路并发？就设 new Semaphore(2)，多一个线程拿到许可也会在执行时失败
- API 配额每分钟 600 次？若平均调用耗时 200ms，理论并发≈20（600 ÷ 60 ÷ 0.2），但应结合限频策略协同使用，Semaphore 仅管瞬时并发
acquire 和 release 必须严格成对，且置于 finally 块
一次遗漏释放，许可数永久减少，后续所有线程都会在 acquire 处阻塞——这是最常见的泄漏根源：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 正确写法：try 中 acquire → 执行业务逻辑 → finally 中 release
- 即使发生 InterruptedException 或 RuntimeException，finally 仍会执行 release
- 禁止在 if 分支里 release，或把 release 放在 return 后面（不可达）
优先选用非公平模式，保障响应及时性
默认构造 new Semaphore(n) 即非公平模式，允许空闲许可被新线程“即时获取”，吞吐更高：
立即学习“Java免费学习笔记（深入）”；
- 公平模式（new Semaphore(n, true)）强制排队，新线程哪怕遇到空闲许可也要等前面所有等待者，反而加剧延迟
- 只在确认存在严重饥饿（如长任务持续占用、短任务永远排不上）且压测证实问题时，才考虑开启公平模式
- 日常限流、连接池、设备访问控制，一律用非公平
配合超时机制，避免无限阻塞
生产环境禁用无参 acquire()，防止线程卡死导致整个服务雪崩：
- 用 acquire(3, TimeUnit.SECONDS)：3 秒内拿不到许可就返回 false，可降级（如写入本地队列、返回 429）
- 捕获 InterruptedException 后，需恢复中断状态：Thread.currentThread().interrupt()
- 超时失败应记录日志并告警，它是资源瓶颈的重要信号
