Java Semaphore 怎样限制并发资源数

做Java多线程开发时，要是碰到需要限制同时访问某类稀缺资源的线程数量的场景，用JUC包中的Semaphore实现非常省心，它本身就是专门用来做并发配额管控的工具类。

Semaphore内部维护了指定数量的许可计数器，同一时间只允许等于许可数的线程拿到访问权限，没拿到许可的线程会自动阻塞等待，等持有许可的线程执行完业务逻辑归还许可后，后续等待线程才能获取许可继续执行，以此就实现了对并发资源数的限制。

我在给外部 API 做并发保护时，最容易踩的坑不是线程池开得太大，而是线程池里的任务同时冲进了一个容量有限的资源区。Java 的 Semaphore 可以把“最多同时使用几个资源”表达成 permits：拿到许可才能进入，使用完必须归还；如果不希望请求无限等待，就用带超时的 tryAcquire。

本文结论：把真实资源上限写成许可数，把 acquire 和 release 放在同一个资源生命周期里，并为等待设置上限。这样限制的是资源区的并发数，不是线程池总线程数。

把资源上限映射为许可数

Semaphore 内部维护的是许可数量，不是一个个真实资源对象。比如外部服务允许同时处理 8 个请求，就可以创建 8 个许可；第 9 个任务要么等待，要么走超时降级。Oracle 的 API 文档也明确把它定位为限制线程访问物理或逻辑资源的计数信号量。

import java.util.concurrent.Semaphore;

public final class QuotaGate {
    // 许可数对应外部资源允许的最大并发量。
    private final Semaphore permits = new Semaphore(8, true);

    public void callResource() throws InterruptedException {
        permits.acquire();
        try {
            // 这里放数据库连接、文件句柄或外部 API 调用。
            doCall();
        } finally {
            // 无论调用成功还是异常，都必须归还许可。
            permits.release();
        }
    }

    private void doCall() {
        // 示例只表示受限资源区，不在此处伪造运行输出。
    }
}

构造器的第二个参数是公平性。资源访问长期排队时，我通常会先用 true，让等待线程按进入顺序获得许可，降低某个请求长期抢不到资源的风险；如果更看重吞吐并且能接受非严格顺序，再评估默认的非公平模式。

成对使用 acquire 与 release

许可控制最重要的约束是“成功获取之后一定释放”。acquire() 可能阻塞，也可能因线程中断抛出 InterruptedException；只有拿到许可后才进入 try/finally，不要在尚未获取成功的路径里无条件释放。

public void borrowOne() throws InterruptedException {
    boolean acquired = false;
    try {
        // acquire 成功后再进入资源生命周期。
        permits.acquire();
        acquired = true;
        useOne();
    } finally {
        // 防止 acquire 被中断时错误增加许可数量。
        if (acquired) {
            permits.release();
        }
    }
}

private void useOne() {
    // 业务代码应保持短小，避免长期占用许可。
}

这也是我更愿意把许可操作封装在资源适配器里的原因：调用方只看到“借用—归还”的生命周期，较少机会把 release 写到另一个分支或忘在异常处理之外。Semaphore 没有锁那样的线程所有权，谁释放都能增加计数，所以正确性必须靠应用代码约定。

用 tryAcquire 控制最长等待

如果请求已经有明确的响应时限，阻塞式 acquire() 往往不合适。带超时的 tryAcquire 会在许可可用时返回 true，等待时间耗尽返回 false；被中断时仍会抛出 InterruptedException，调用方要保留中断语义或交给上层处理。

import java.util.concurrent.TimeUnit;

public boolean tryCall() throws InterruptedException {
    // 等待预算要小于请求剩余超时时间，避免拿到许可后没有处理时间。
    if (!permits.tryAcquire(300, TimeUnit.MILLISECONDS)) {
        // 资源忙时可以返回稍后重试、使用缓存或排入业务队列。
        return false;
    }
    try {
        doCall();
        return true;
    } finally {
        // 只有 tryAcquire 返回 true 才进入释放路径。
        permits.release();
    }
}

无超时的 tryAcquire() 适合“现在没有就马上降级”的场景，但它即使在公平模式下也可能抢先拿到现成许可。如果必须遵守公平等待，可以使用带零等待时间、同时可感知中断的重载形式。

公平性、观察值和常见误区

availablePermits() 适合调试和测试，getQueueLength() 只是等待线程数量的估计值，都不应被拿来做精确的并发控制判断。实际监控中，可以把它们和请求拒绝数、资源调用耗时一起看，避免把瞬时读数误认为严格事实。

还要留意三个边界：第一，Semaphore 限制的是许可覆盖的代码区，许可之外的 CPU、内存和网络仍可能成为瓶颈；第二，多许可请求会等待足够数量的许可，不要用循环替代原子批量获取；第三，release 次数必须和成功获取的许可数匹配，否则资源上限会被悄悄放大。

适合谁，以及我的取舍

如果你需要限制连接池外的一段共享资源、为第三方服务设置并发预算，Semaphore 是轻量而直观的选择；如果任务需要复杂排队、取消、重试和结果收集，仍应把它放在更完整的任务编排外层。我的经验是先写清“一个许可代表什么”，再决定许可数和超时，最后把成功获取与释放封装在同一个方法里。

相关问题：

• Semaphore 和 synchronized 有什么区别？前者表达可计数的并发许可，后者通常表达互斥进入一个临界区。
• tryAcquire 超时后要不要 release？没有拿到许可就不要释放；只有返回成功的获取才需要归还。
• 公平模式一定更快吗？不一定，公平性主要减少饥饿风险，吞吐和调度开销仍要结合场景判断。