Java Semaphore 释放许可次数错误时如何定位并发泄漏

Java Semaphore 出现“并发越来越高”或“线程一直等不到许可”时，先别急着调大初始化数量。最常见的根因是 release(n) 的数量没有和成功的 acquire(n) 对上：多释放会让可用许可虚增，少释放则会让许可长期被占着。排查的关键不是看某个线程有没有调用 release，而是核对每个任务边界的许可数量是否守恒。

先看清 Semaphore 的许可守恒关系

把初始许可数记为 P，成功获取总数为 A，释放总数为 R，那么某一时刻的可用许可可以近似理解为 P - A + R。在任务都已经结束的测试场景里，理想结果是 A = R，可用许可回到 P。

这里有一个容易被忽略的语义：Java API 不会替应用检查归还数量。一次 acquire(2) 后调用两次 release()，结果是正确的；但只调用一次就少还了一个许可。反过来，成功只获取一个许可却执行 release(2)，可用许可会多出一个，信号量原本的并发上限也随之失真。

用一条责任边界记录许可是否对称

排查时建议把“成功获取”作为释放资格的起点，而不是把 finally 当成无条件补偿点。下面的写法把批量许可数固定在局部变量中；只有 acquire(permits) 成功后，才会进入归还逻辑。

import java.util.concurrent.Semaphore;

public final class LimitedWorker {
    private final Semaphore slots = new Semaphore(8, true);

    public void run(Runnable task, int permits) throws InterruptedException {
        // 先拒绝无意义的数量，避免把错误传入并发控制层。
        if (permits  8) {
            throw new IllegalArgumentException("许可数量超出任务边界");
        }

        slots.acquire(permits);
        boolean acquired = true;
        try {
            // 业务代码只能使用已经成功取得的 permits 个资源名额。
            task.run();
        } finally {
            // 归还数量必须来自同一个变量，不能写成固定的 release() 或 release(1)。
            if (acquired) {
                slots.release(permits);
            }
        }
    }
}

boolean acquired 在这个最小示例中总会为真，是为了把“是否成功获取”的责任边界写清楚。实际代码若使用 tryAcquire，应当只有返回 true 才进入 try/finally；如果 acquire 因中断直接抛出异常，也不能执行释放。

从指标和日志中区分多释放与少释放

先在同一个任务标识下记录三类数字：请求希望获取的数量、实际成功获取的数量、最终归还的数量。不要只打印“release called”，因为那只能说明调用发生过，不能说明数量正确。

检查代码时，再把 availablePermits() 和在途任务数放在一起看。API 文档将它定位为调试和测试用途；它只能告诉你当前还有多少许可，不能直接证明哪个请求持有许可。若等待线程也需要观察，可以记录 hasQueuedThreads()，但它同样是状态线索，不是精确的排队人数。

用最小测试锁定真正的泄漏路径

测试不要只覆盖“正常执行后释放”。至少准备四个分支：成功获取后正常归还、获取两项却只归还一项、获取一项却归还两项、获取被中断后不应释放。让任务全部结束后再检查 availablePermits() 是否恢复初始值，并用一个原子计数器记录实际并发数，确认峰值没有超过许可上限。

修复后，最值得保留的断言是“所有成功获取的许可最终都被归还”。在生产监控中，可以按任务类型聚合 acquire_total、release_total 和 in_flight；如果总量不相等，优先定位代码分支，而不是继续增加信号量容量掩盖问题。

常见问题

release 只能由 acquire 的同一线程调用吗？

不需要。Semaphore 不建立线程所有权关系，但业务上仍应把获取和归还绑定在清晰的任务责任边界内，否则很难追踪数量。

availablePermits 变大一定是内存泄漏吗？

不一定，它更像是许可账本漂移。若释放总量大于获取总量，表现为并发限制被放宽；这和 Java 堆内存泄漏不是同一个概念。

tryAcquire 超时后要不要 release？

如果 tryAcquire 返回 false，说明没有成功拿到对应许可，不能释放；只有成功获取的数量才拥有归还义务。

排查这类问题可以只记住一句话：先统计成功获取了多少，再核对最终归还了多少。数量对称、路径完整、测试结束回到初始许可数，才说明并发控制真正恢复。