Semaphore是可观测、可调优的并发资源管理节点，许可数须对齐真实资源能力：数据库连接池对应最大活跃连接数，CPU密集型依公式估算，IO密集型需压测验证；运行时依赖availablePermits、getQueueLength、超时率等指标动态调优；释放必须严格闭环，公平性按场景选。
Semaphore 不只是“限流开关”，它本身就是一个可观测、可调优的并发资源管理节点。用得好，它能成为系统性能监控的天然探针；用得随意，反而会掩盖瓶颈、放大延迟。
许可数必须对齐真实资源能力
设 10 个许可不等于“允许 10 个线程跑”，而是代表后端资源最多能稳定支撑 10 路并发。关键看资源类型：
- 数据库连接池：许可数 ≈ 连接池最大活跃连接数，且不能超过数据库服务端允许的并发连接上限（如 MySQL 默认 max_connections=151，但实际业务连接池常设为 20–50）
- CPU 密集型任务：参考公式 许可数 ≈ CPU 核心数 × (1 + 平均等待时间 / 平均计算时间)，避免线程争抢 CPU 导致上下文切换飙升
- IO 密集型任务（HTTP 调用、文件读写）：可设为 CPU 核心数的 2–5 倍，但必须通过压测验证——比如阶梯式放开许可（5 → 20 → 50），观察平均等待时间与错误率拐点
运行时指标是调优核心依据
静态配置扛不住流量波动，真正有效的管理依赖实时指标反馈：
- availablePermits()：持续接近 0，说明资源长期饱和；若长期 >80%，说明许可冗余，可能浪费吞吐潜力
- getQueueLength()：等待线程数持续 >10，且伴随响应延迟上升，就是明确的瓶颈信号
- acquire 超时率：配合 tryAcquire(timeout, unit) 使用，超时比例 >5% 就需介入——不是加许可，而是先查下游是否慢或失败
释放逻辑必须严格闭环
许可泄漏比线程泄漏更隐蔽，也更致命。常见错误包括：
立即学习“Java免费学习笔记（深入）”；
- 没套 try-finally 或 try-with-resources，异常路径下 release() 被跳过
- 跨线程释放：A 线程 acquire，B 线程 release —— 语义错乱，AQS 不校验线程归属，但会破坏排队逻辑
- 重复 release：多次调用 release() 会导致许可数虚高，突破真实资源容量，引发雪崩
公平性模式要按场景选，别一刀切
公平模式（new Semaphore(n, true)）不是“更稳”的代名词：
- 非公平模式（默认）：适合 API 网关限流、缓存穿透防护等短耗时高频场景，吞吐高 15%–30%，延迟波动可接受
- 公平模式：只用于强顺序或防饥饿场景，如支付扣款、库存预占——避免某个请求因持续插队而超时，但获取许可平均耗时可能上升 2–5 倍
