Semaphore的核心作用是限制并发数而非保证线程安全；它通过acquire/release控制资源配额，需成对调用且置于finally块；公平模式启用FIFO排队防饥饿但性能略低；acquire(n)要求原子性扣减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 排队：
立即学习“Java免费学习笔记（深入）”；
- 非公平：新线程可能插队抢到刚释放的许可，吞吐略高，但老线程可能一直等不到（饥饿）
- 公平：严格按等待时间排序，避免饥饿，但每次获取许可都要走队列查找，延迟略高
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），整条流水线就停摆。
