new Semaphore(n) 的 n 应根据资源真实承载能力设定，如数据库连接池为10则设10；需预留缓冲、避免动态修改、用tryAcquire防阻塞、release必须放finally、非公平模式性能更优。
new Semaphore(n) 的 n 设多少才合理
信号量的许可数 n 不是拍脑袋定的，它直接对应「你允许同时访问该资源的线程上限」。比如数据库连接池最大 10 个连接，那 new Semaphore(10) 才匹配；设成 20 就可能触发连接超时异常，设成 5 则人为压低吞吐。
常见错误是把 n 和线程池大小混为一谈——线程池有 20 个线程，不代表资源能撑住 20 并发。关键看资源本身瓶颈：文件句柄、第三方 API QPS 限制、内存敏感的缓存计算等。
- 查清下游资源的真实承载能力（如 Redis 官方建议单实例不要超过 10k 并发连接，但实际业务接口可能 50 并发就响应变慢）
- 预留缓冲：如果压测发现 8 并发时 P99 延迟开始上扬，别设
new Semaphore(8)，设7或6更稳妥 - 避免动态改
n：构造后调用release(int)或acquire(int)可能绕过预期控制，除非你明确需要可变配额
acquire() 阻塞时线程中断会被忽略吗
会。默认 acquire() 不响应中断，线程卡在那儿，Thread.interrupt() 白叫。这在超时控制或服务优雅停机时非常危险——你发了中断，线程却还在等许可，停不掉。
正确做法是用 acquireUninterruptibly()（不响应中断，适合必须拿到许可的场景），或更常用的是 tryAcquire(long, TimeUnit) 配合超时判断。
立即学习“Java免费学习笔记（深入）”；
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
if (!sem.tryAcquire(3, TimeUnit.SECONDS)) { throw new RuntimeException("获取许可超时"); }- 别写
sem.acquire(); // 危险！无超时、不响应中断 - 如果真要用阻塞版，至少包一层
try-catch (InterruptedException e)，并在 catch 里做清理（如还原状态、记录日志），然后重新抛出或返回
release() 忘记调用会导致什么
许可证永远不归还，availablePermits() 持续减少，最终所有线程卡死在 acquire()。这不是内存泄漏，但效果类似——系统逐渐失去响应能力，且极难排查，因为堆栈里只看到一堆 WAITING 状态的线程在等 Semaphore。
典型场景：带 try-finally 的写法被简化，或者异步回调里漏了 release()。
- 必须把
release()放进finally块，哪怕只是单行逻辑 - 避免在 lambda 或 CompletableFuture 回调中直接调用
release()，容易因异常跳过——先捕获再显式 release - 调试时可定期打点：
System.out.println("permits left: " + sem.availablePermits());，上线前删掉
公平模式（fair = true）有什么实际影响
设 new Semaphore(n, true) 后，等待线程按 FIFO 顺序获取许可。听起来很理想？但代价是每次 acquire() 和 release() 都要走队列操作，性能比非公平模式低 10%–30%，尤其在高并发争抢时。
除非你明确需要「先到先得」语义（比如任务排队执行不能乱序），否则默认非公平更合适。JVM 默认就是非公平，也符合多数服务对吞吐优先的取舍。
- 公平模式不会防止饥饿，只是让等待队列有序；如果持续有新线程快速 acquire/release，老线程仍可能长期等不到
- 测试时开启公平模式可能掩盖竞争 bug——因为调度太「规矩」，反而看不出真实压力下的行为
- 线上环境几乎不用公平模式，除非业务逻辑强制要求顺序性（如支付扣减必须严格按请求时间）
最麻烦的不是怎么写对，而是许可证和业务逻辑的生命周期怎么对齐——比如一次 HTTP 请求开了 3 个 DB 查询，该用 1 个许可还是 3 个？这里没标准答案，得看你保护的是连接池本身，还是单次查询的资源消耗。细节错一点，压测时才暴露，但那时已经晚了。
