semaphore在oom时不会自动释放许可，许可滞留源于线程在acquire成功后、release执行前崩溃；必须将release置于finally块中配对acquire，否则导致资源泄漏型饥饿。
Java中Semaphore本身不会因OOM而“卡住”或无法释放许可，它不像手动加锁那样依赖程序员显式释放——只要调用过acquire()且线程未被强制终止，JVM会在抛出OutOfMemoryError前执行对应的release()逻辑（前提是该调用已进入JVM同步调度路径）。但真实风险在于：OOM可能让线程在acquire()成功后、release()执行前就崩溃或挂起，导致许可“滞留”，其他线程无限等待。
为什么Semaphore在OOM时通常仍能释放
其底层基于AQS（AbstractQueuedSynchronizer），release()是原子操作，不依赖try-finally保护；但关键前提是线程能走到这一步。JVM对acquire()的异常处理有保障：
- 若
acquire()阻塞中发生OOM，线程被中断，AQS会自动清理节点并唤醒后续线程 - 若
acquire()已返回（即获取成功），但业务代码触发OOM，release()是否执行取决于它是否在finally块中——这是人为控制点，不是JVM兜底项 - 与
synchronized不同，Semaphore没有字节码级双出口保证（monitorexit正常/异常路径），它的释放必须由开发者负责
真正要防的不是“锁不解”，而是“许可不还”
OOM本身不破坏Semaphore状态，但会让持有许可的线程失联，造成“许可泄露”。这不是死锁，而是资源耗尽型饥饿——可用许可数永远少1。常见场景：
- 在
acquire()后立即分配大数组（如new byte[1024 * 1024 * 100]），触发堆OOM，跳过release() - 使用非标准方式获取许可（如
tryAcquire(1, 1, TimeUnit.SECONDS)超时失败，但误判为已获取） - 多层嵌套调用中，某一层未将
release()放到finally里，异常穿透后遗漏释放
安全释放的实操要点
核心原则：所有acquire()必须配对release()，且release()必须在finally中执行。不要依赖“JVM会帮我收尾”：
- 写法必须是：
try { semaphore.acquire(); ... } finally { semaphore.release(); } - 避免在synchronized块内做acquire——双重同步易引发争用，且OOM时更难定位许可归属
- 对关键资源（如连接池、文件句柄），用
try-with-resources封装Semaphore逻辑，把释放动作下沉到AutoCloseable实现里 - 上线前用压力测试+人工注入OOM（如
-XX:+CrashOnOutOfMemoryError）验证许可回收行为
OOM发生后的补救与监控
一旦出现许可滞留，靠代码无法“远程解开”，只能靠设计预防：
- 启用
-XX:+HeapDumpOnOutOfMemoryError，事后分析dump确认哪些线程卡在acquire后未释放 - 用
semaphore.availablePermits()定期上报指标，配合Prometheus告警：当可用许可长期低于阈值（如initialPermits - 1），说明有泄漏 - 对长时任务，改用带超时的
acquire(1, timeout, unit)，避免单个线程永久占住许可 - 必要时用
Semaphore(permits, true)开启公平模式，减少饥饿概率，但不解决泄漏本身
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
