Semaphore资源控制详解与应用示例

Semaphore是Java并发编程中专用于控制共享资源并发访问数量的“配额闸门”，它不解决线程安全问题，而是通过许可（permits）机制严格限制同时使用资源的线程数，有效防止因过度争抢导致的系统过载——无论是数据库连接池、API调用限流还是磁盘I/O管控，它都扮演着冷静理性的“发号排队管理员”角色；但必须谨记：acquire与release须成对出现在finally块中以防泄漏，公平模式仅在确有饥饿风险时启用，而acquire(n)要求原子性扣减、不支持弹性获取，稍有疏忽就可能让整个系统悄然卡死。

Semaphore 的核心作用是对共享资源施加明确的并发数上限——它不解决线程安全（如数据竞争），而是解决“太多人同时抢一个有限资源”带来的过载问题。

比如：你有 3 个数据库连接，却有 20 个线程争着用；你提供一个文件写入服务，但磁盘 I/O 能力只撑住 5 路并发；你调用一个外部 HTTP 接口，对方限流为 QPS=10。这些场景下，Semaphore 就是那个“发号排队”的管理员。

acquire() 和 release() 必须成对出现，否则会永久阻塞

这是最常踩的坑：忘记 release()，或在异常路径里没进 finally 块。

• acquire() 成功后，许可计数器减 1；若为 0，后续线程调用 acquire() 就会无限期挂起
• release() 不校验调用者是否曾 acquire() 过——它只是无条件给计数器 +1
• 所以一旦漏掉 release()，可用许可数永远回不到初始值，整个系统逐步“卡死”

try {
    semaphore.acquire();
    doSomething(); // 可能抛异常
} catch (InterruptedException e) {
    Thread.currentThread().interrupt();
    return;
} finally {
    semaphore.release(); // ✅ 必须放在这里
}

公平模式（fair = true）不是“性能更好”，而是“更守序”

默认构造是 new Semaphore(3)，即非公平模式；加 true 才启用 FIFO 排队：

• 非公平：新线程可能插队抢到刚释放的许可，吞吐略高，但老线程可能一直等不到（饥饿）
• 公平：严格按等待时间排序，避免饥饿，但每次获取许可都要走队列查找，延迟略高

Semaphore fairSemaphore = new Semaphore(3, true); // 公平
Semaphore unfairSemaphore = new Semaphore(3);      // 默认非公平

实测中，除非你明确观察到某类请求长期超时（怀疑饥饿），否则别盲目开公平模式。

一次 acquire 多个许可（acquire(int n)）要小心整除逻辑

当你用 acquire(2)，不代表“只要剩 ≥2 个就一定能拿到”——它要求**原子性地一次性扣减 2 个**。

• 若当前 availablePermits() 是 1，acquire(2) 仍会阻塞，哪怕稍后有人 release() 1 次也不够
• 常见误用：想“尽量拿，拿多少算多少”，但 Semaphore 不支持“尝试拿最多 N 个”，只支持“要么全拿，要么等”

• 需要弹性配额？自己封装逻辑，用 tryAcquire(n) 循环重试
• 需要分批释放？release(2) 合法，且会立刻唤醒最多 2 个等待线程（取决于当前队列长度）

关键点其实就一个：把 Semaphore 当作“资源配额闸门”，而不是“锁”。它不管临界区里干了什么，只管“此刻允许几个人进门”。配额设太小，业务吞吐上不去；设太大，下游扛不住；漏关闸门（漏 release），整条流水线就停摆。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于文章的相关知识，也可关注golang学习网公众号。