Semaphore 是控制同时访问资源的线程数量的并发工具，而 synchronized 保证同一时刻仅一个线程进入临界区；前者是限流闸机，后者是单人通道。
什么是 Semaphore，它和 synchronized 有什么区别
Semaphore 是 Java 并发包（java.util.concurrent）中用于控制**同时访问某资源的线程数量**的工具类。它不保证线程执行顺序，只管“放行几个”。而 synchronized 或 ReentrantLock 解决的是**互斥访问**——同一时刻只允许一个线程进入临界区。
简单说：synchronized 是“单人通道”，Semaphore 是“限流闸机”，可以设成 5 人同时过、10 人同时过。
如何初始化并使用 Semaphore 控制并发数
创建时传入许可数（permits），即最大并发线程数。常用模式是：获取许可 → 执行业务 → 释放许可。务必在 finally 块中释放，否则许可泄露会导致后续线程永久阻塞。
import java.util.concurrent.Semaphore;
public class RateLimiter {
private static final Semaphore semaphore = new Semaphore(3); // 最多 3 个线程并发
public void handleRequest() {
try {
semaphore.acquire(); // 阻塞直到拿到许可
// 模拟耗时操作：数据库查询、HTTP 调用等
System.out.println("Thread " + Thread.currentThread().getName() + " acquired");
Thread.sleep(1000);
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
} finally {
semaphore.release(); // 必须释放！哪怕出异常也要放
}
}
}
- 构造函数支持第二个参数
fair（默认false）：设为true可让等待线程按 FIFO 获取许可，避免饥饿，但性能略低 -
acquire()会阻塞；若想带超时，用tryAcquire(long timeout, TimeUnit unit)，返回boolean - 不要在持有许可期间调用
System.exit()或直接杀线程，否则release()不会被执行
Semaphore 常见误用与坑
最典型的问题不是“不会用”，而是“没意识到它不绑定线程”——同一个线程可多次 acquire()（除非用 tryAcquire(1)），也必须对应次数调用 release()，否则计数错乱。
- 错误：在循环里反复
acquire()却只release()一次 → 许可被提前耗尽 - 错误：用
if (semaphore.tryAcquire()) { ... } else { throw new RuntimeException(); }后忘记release()→ 成功分支漏释放 - 注意：
Semaphore不是重入锁，acquire()和release()可跨线程调用（比如 A 线程 acquire，B 线程 release），这既是灵活性也是风险点 - 监控许可剩余数可用
semaphore.availablePermits()，但它是快照值，不可用于条件判断（竞态）
适合用 Semaphore 的真实场景
它最适合保护**外部有限资源**，比如连接池、第三方 API 调用配额、文件句柄、硬件设备访问等——这些资源本身不支持 Java 内部锁机制，只能靠应用层限流。
立即学习“Java免费学习笔记（深入）”；
- 限制对某 HTTP 接口的并发请求数（如每秒最多 20 调用）
- 控制同时写入同一日志文件的线程数（避免磁盘争抢）
- 模拟数据库连接池的“获取连接”行为（虽然真实连接池用更复杂的逻辑）
- 不适合替代
synchronized保护对象字段——那是语义错位，容易引发数据不一致
真正难的不是写那几行 acquire/release，而是想清楚：这个“3”或“10”是怎么算出来的？它是否随负载动态调整？失败后是排队、降级还是熔断？这些决策比 API 调用本身重要得多。
