Semaphore在Java并发编程中用于控制对共享资源的访问，其核心作用是实现资源的有限并发访问。通过维护一个许可数量（permits），Semaphore可以限制同时访问某个特定代码段的线程数量，从而避免资源过度使用或竞争。1. 基本作用Semaphore的主要功能是控制资源的并发访问数量。它类似于一个“许可证池”，线程在访问资源前必须获取一个许可，使用完毕后释放许可，供其他线程使用。例如：数

Semaphore是Java中专用于资源流量管控的并发工具，它不解决线程安全问题，而是像一位严格的“发号管理员”，通过许可（permits）机制硬性限制同时访问共享资源的线程数量，有效防止数据库连接耗尽、外部接口被压垮或I/O过载等典型过载场景；其核心在于acquire/release必须成对出现在finally块中以防许可泄漏，支持单次获取多个许可的原子操作，并可选公平模式避免饥饿——用好它，关键不是把它当锁使，而是精准设定配额、严守释放契约，让系统在高并发下既高效又稳定。

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学习网公众号。