Java 中 Semaphore 内部信号量管理的异常安全与资源释放-Java面试题-PHP中文网

semaphore异常安全关键在于开发者必须显式保障许可释放，jvm不会自动补救遗漏的release()；许可滞留会导致资源耗尽型饥饿，oom时线程在acquire后崩溃而未release是主因，正确做法是将release置于finally块中。

java 中 semaphore 内部信号量管理的异常安全与资源释放

Java 中 Semaphore 的异常安全关键在于：许可释放必须由开发者显式保障，JVM 不会自动补救遗漏的 release()。它本身不“卡住”，但许可一旦滞留，就会造成资源耗尽型饥饿——可用许可数永久减少，其他线程无限等待。

OutOfMemoryError 并非让 Semaphore 失效，而是打断线程执行流。真正危险的是：线程在 acquire() 成功返回后、尚未执行 release() 前就崩溃。此时许可已被扣减，但无人归还。

release() 不是可选操作，而是与 acquire() 严格配对的义务。不能依赖 JVM 或 AQS 自动兜底——AQS 只保证自身状态变更原子性，不保证业务线程一定走到释放语句。

Java JDK 25

Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。

下载

正确写法：
try { semaphore.acquire(); /* 业务逻辑 */ } finally { semaphore.release(); }
禁止写法：
semaphore.acquire(); /* 业务逻辑 */ semaphore.release(); // 无 try-finally，任何异常都会跳过 release
若需响应中断，acquire() 的异常需在 catch 中重置中断状态，再抛出或处理，但 finally 中的 release() 仍不可省略

把许可获取与释放下沉为资源生命周期的一部分，降低人为疏漏概率。

对关键资源（如连接、文件句柄），封装成 AutoCloseable 实现，在 close() 中执行 release()，配合 try-with-resources 自动收尾
避免在 synchronized 块内调用 acquire()：双重同步易掩盖许可归属，OOM 时更难定位哪段代码持有了许可
上线前做破坏性验证：用 -XX:+CrashOnOutOfMemoryError 配合压力测试，观察许可是否能稳定回收；监控 availablePermits() 和 getQueueLength() 指标变化