Java信号量如何控制并发访问

Java信号量（Semaphore）并非简单的“同步锁替代品”，其本质是通过显式建模下游资源的并发承载边界来实现弹性、可观测的流量控制——它基于可配置许可数支持超时获取、批量申请与动态扩缩，与synchronized的独占monitor机制存在根本性差异；实践中应优先选用带超时的tryAcquire避免线程饥饿，严格配对finally中的release防止许可泄漏，并依据压测拐点而非主观猜测设定permit数量，真正发挥其在分布式调用、外部依赖等不确定性场景下的风控价值。

为什么 new Semaphore(1) 不等于 synchronized

因为 Semaphore 控制的是「许可数量」，不是「锁对象」。即使设为 1，多个线程仍可能同时调用 acquire() 并阻塞等待，而 synchronized 是基于 monitor 的独占进入机制，不排队、不累积许可。
关键区别在于：Semaphore 允许提前预占（比如 tryAcquire(1, 1, TimeUnit.SECONDS)），也支持一次性获取多个许可（acquire(3)），而 synchronized 没有超时、不可重入计数、也不支持批量。

acquire() 和 tryAcquire() 的实际选择场景

真实业务里几乎总是该用 tryAcquire()，尤其涉及外部依赖或 SLA 要求时——否则一个卡住的线程可能拖垮整个许可池。
常见误用：acquire() 在无界等待下导致线程饥饿，或在 Spring 容器中因未释放许可引发连接池耗尽。

• acquire()：仅适用于你**完全掌控下游响应时间**的场景（如纯内存计算、本地缓存读写）
• tryAcquire(long timeout, TimeUnit unit)：推荐用于 HTTP 调用、DB 查询、消息发送等不确定延迟的操作
• 永远配对使用 release()，建议放在 finally 块里，哪怕用了 tryAcquire() 成功后也要确保释放

permit 数量设多少才合理？

不能只看 CPU 核数或连接池大小。真正决定上限的是「下游瓶颈资源」的并发承载能力。比如调第三方 API，对方限流 100 QPS，你设 new Semaphore(100) 没用——如果单次请求平均耗时 2 秒，那理论最大并发只有 100 / 2 = 50 左右；再高就会触发对方熔断或 429 错误。

• 先压测确定下游稳定吞吐拐点（例如：并发 30 时 P99=120ms，到 35 就跳到 800ms）→ 取略低于拐点的值（如 28）
• 动态调整比硬编码更可靠：可结合 MetricRegistry 或 Micrometer 监控 getQueueLength()，自动缩放 permit
• 注意：availablePermits() 返回的是当前空闲许可数，不是初始值；别拿它做初始化判断

释放许可时最常见的三个坑

绝大多数 Semaphore 相关故障都发生在 release() 阶段，不是没调，就是多调、少调、错线程调。

• 在异步回调中释放：比如用 CompletableFuture 提交任务后，在 thenAccept 里 release() —— 此时很可能已脱离原许可获取线程，但 Semaphore 不校验线程归属，所以能执行，但逻辑上已错乱
• 异常分支遗漏 release()：尤其在 tryAcquire() 成功后，后续代码抛异常却没进 finally
• 重复释放：比如在重试逻辑里，每次重试都 release() 一次，导致许可数暴涨，突破限制

try {
    if (!semaphore.tryAcquire(1, 3, TimeUnit.SECONDS)) {
        throw new RuntimeException("acquire timeout");
    }
    // do work...
} finally {
    // 必须在这里 release，且只 release 一次
    semaphore.release();
}

Semaphore 的核心不是“控制数量”，而是“显式建模资源边界”。一旦把 permit 当作魔法数字硬编码，就失去了它本该提供的可观测性与弹性调控能力。

今天关于《Java信号量如何控制并发访问》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！