Java Semaphore 公平参数怎么选：许可不足、线程饥饿与超时回收

接口限流改成了 Semaphore，压测却出现一个很难复现的现象：大多数请求很快拿到许可，少数线程在高峰期等了很久，甚至在超时后仍然看见后台任务继续占用资源。这里真正需要先定下来的不是 permits 填 20 还是 50，而是等待顺序、超时退出和许可归还这三件事的边界。

公平参数到底改变了什么

Semaphore用一组许可表示有限资源。线程调用 acquire() 后，如果当前没有可用许可，就会进入等待；调用 release() 才会把许可归还。第二个构造参数 fair 为 true 时，等待线程按先来先服务的方式参与获取，设为 false 则允许后来线程在竞争窗口中插入。

Semaphore fairGate = new Semaphore(20, true);
Semaphore fastGate = new Semaphore(20, false);

开启公平模式也不代表所有线程的业务完成时长完全一致，更不会杜绝线程超时的情况。它只是遵守了先到先得的许可获取排队规则，实际数据库操作、网络调用还有系统线程调度的不可控性，依然可能让刚拿到许可的线程执行很长时间。

先用最小代码把许可生命周期固定下来

一个批量调用外部服务的限流入口，可以把“获取、执行、归还”收拢在同一个方法里。这里别在多个 helper 之间传递一个模糊的“是否获取成功”，成功获取后立刻进入 try/finally，能少掉一类异常分支忘记归还的问题。

private final Semaphore gate = new Semaphore(20, true);

boolean callRemote(Duration wait) throws InterruptedException {
    long start = System.nanoTime();
    if (!gate.tryAcquire(wait.toNanos(), TimeUnit.NANOSECONDS)) {
        timeoutCounter.increment();
        return false;
    }
    waitNanos.record(System.nanoTime() - start);
    try {
        remoteClient.call();
        return true;
    } finally {
        gate.release();
    }
}

示例中只有一次 acquire，所以只调用一次 release。如果某个分支需要一次拿两张许可，就应记录实际数量并在同一个 finally 中释放两张，不能把默认的 1 当成业务事实。

什么压力下公平 Semaphore 才值得用

如果不同请求的耗时差得很多，长时间等待直接会变成用户侧超时，甚至出现部分任务一直抢不到许可的饥饿问题，开公平队列反而更容易做效果对齐和结果验收。比如批处理线程和用户交互请求共享图片转码的配额，非公平模式下很可能晚到的一批短任务反复抢到许可，排在队列前的慢任务半天拿不到执行机会。

公平模式本身会带来排队管理的额外开销，绝对不能理解成“打开公平模式性能就更好”。要是资源本身已经被单个慢调用长时间占住，开公平最多只能让等待的顺序更稳定，没法替代调用超时配置、线程池隔离还有下游接口限速这些基础措施。

tryAcquire 的超时边界不能写成装饰

tryAcquire返回 false 时，调用方没有拿到许可，不能执行远程调用，也不能调用 release。返回 true 后即使业务在执行中抛出异常，仍然要归还许可。两条路径的指标要分开：前者是排队超时，后者是已占用资源的业务失败。

if (!gate.tryAcquire(80, TimeUnit.MILLISECONDS)) {
    rejectedByWait.increment();
    return fallback();
}
try {
    return loadFromDependency();
} catch (TimeoutException ex) {
    dependencyTimeout.increment();
    return fallback();
} finally {
    gate.release();
}

如果线程被中断，带超时的获取会抛出 InterruptedException。上层决定取消时，通常应恢复中断标记或把取消继续向上传播，不要捕获后悄悄当作普通业务失败。否则线程池里的任务可能看起来完成了，实际却丢掉了取消信号。

最容易留下隐患的三种写法

把公平当成全局排队器

Semaphore只管理它自己的许可。另一个线程池、HTTP 连接池或数据库连接池仍有独立排队规则。想控制整条链路时，要分别检查这些边界，否则只调大 Semaphore 的 permits，可能把压力推给下游。

获取失败也执行 release

这种写法会凭空增加可用许可，最终让并发上限失效。应让释放动作紧跟成功获取后的 try/finally，不要放到一个无法判断状态的公共清理函数里。

用 sleep 代替等待策略

线程先 sleep 再重试既不能保证公平，也会占用线程池工作线程。对有截止时间的请求使用 tryAcquire(timeout)，对可长期排队的后台任务则应使用真正的队列和明确的取消策略。

用四个指标验收是否真的合适

上线之前至少统计四类核心指标：许可获取等待时长、业务持有许可的时长、等待超时的数量、当前可用许可数。压测的时候分别跑公平和非公平两组用例，固定请求比例和下游接口延迟，重点看p95和p99分位的耗时，不要只盯着平均值下判断。

• 获取等待持续升高：许可数小于稳定并发量，或者下游调用耗时太长。
• 当前许可长期为零：先查许可持有时间和线程栈，再排查有没有漏掉释放许可的逻辑。
• 超时数上升但持有时间正常：留给等待的时间预算可能比业务峰值的排队时间还小。
• 非公平模式吞吐略高但尾延迟恶化：结合真实用户请求的权重，判断能不能接受这个取舍。

相关问题

公平 Semaphore 会让吞吐下降吗？

公平模式确实会新增少量排队处理开销，但实际影响有多大，完全看竞争强度、临界区耗时还有系统线程调度的情况。一定要在固定负载的前提下对比吞吐和尾延迟，不能只看构造参数就直接下结论。

tryAcquire 返回 false 后还需要 release 吗？

不需要，因为线程没有拿到许可。只有成功获取后，才需要在对应的 finally 中释放相同数量的许可。

Semaphore 能替代线程池大小配置吗？

不行。Semaphore 是用来限制访问某部分稀缺资源的并发数，线程池决定任务用多少个工作线程去执行，两者要根据下游的容量和任务的运行模型分别配置，不能互相替代。

最后的判断清单

如果等待顺序本身会影响业务公平性，而且资源持有时间已经做好超时和监控，开公平模式值得做一组对照实验；如果当前的核心问题是下游接口慢、任务没法取消或者许可偶尔会泄漏，先把资源生命周期管理和超时边界修好，再讨论公平参数的选择。Semaphore 用得对不对，关键从来不是构造函数传的是 true 还是 false，而是所有成功获取许可的路径，都能做到可靠归还。