tryacquire本质是原子性扣减许可的瞬时写操作，非状态查询；高并发下cas失败属正常竞争，需用try-finally确保release，超时版仍为非阻塞，调优应兼顾许可数、公平性与退避策略。
理解 tryAcquire 的本质：瞬时快照，不是状态查询
tryAcquire() 不是「检查当前还有几个许可」的读操作，而是「此刻能否原子性地扣减一个许可」的写操作。它底层依赖 CAS 修改内部计数器，每次调用都是独立尝试，不排队、不等待、不记忆历史。高并发下多个线程同时抢同一个计数器，绝大多数会因 CAS 失败返回 false——这不是 bug，是正常竞争现象。所以看到失败率飙升，先别怀疑信号量配置，要意识到这是高争用下的自然结果。
避免常见误用：别把它当 if-else 判断开关用
下面这种写法看似简洁，实则隐患大：
✘ 错误示范：
if (sem.tryAcquire()) {<br>
doWork(); // 若这里抛异常，release() 就永远不会执行<br>
sem.release();<br>
}
正确做法必须用 try-finally 包裹业务逻辑，且只在获取成功后才释放：
✔ 正确写法：
if (sem.tryAcquire()) {<br>
try {<br>
doWork();<br>
} finally {<br>
sem.release();<br>
}<br>
} else {<br>
// 降级、限流响应或重试逻辑<br>
}
超时版 tryAcquire(long, TimeUnit) 的实用建议
带超时的版本仍属非阻塞语义延伸，不是“保证等 100ms 就能拿到”。它只承诺最多花这么多时间尝试，期间可能被调度延迟、GC 或其他线程抢占打断。
- 超时值不宜过小：低于 5–10ms 在中高负载下基本无效，建议设为 20–100ms 范围，视业务容忍延迟而定
- 必须处理 InterruptedException：不能吞掉，需恢复中断状态或按需传播
- 成功后仍需 release()：和无参版一样，不配对就会导致许可泄漏
- 不要用于强一致性场景：它不参与 AQS 等待队列，无法保证“只要有人 release，我就一定能等到”
高并发下的调优方向：许可数 + 公平性 + 退避策略
单纯增加许可数治标不治本；关键是从三方面协同优化：
- 许可数量要匹配真实瓶颈：比如下游接口 QPS 瓶颈是 200，而你设了 500 个许可，大量线程会空转竞争，徒增 CAS 冲突。应基于压测数据反推合理上限
- 公平模式慎用：公平模式虽降低饥饿风险，但强制排队会显著增加上下文切换和锁开销，在短任务、高吞吐场景下反而拉低整体性能。默认非公平更合适
- 引入轻量级退避：连续几次 tryAcquire() 失败后，可加微小随机延时（如 1–5ms）再重试，避免所有线程在同一毫秒级窗口疯狂重试，缓解 CAS 雪崩
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
