new Semaphore(1) 不等于 synchronized，因前者基于AQS共享锁，支持公平性、可中断、超时等语义，后者是JVM互斥锁，无此特性；调度与唤醒机制也不同。
为什么 new Semaphore(1) 不等于 synchronized
因为 Semaphore 是基于 AQS 的共享锁，支持可重入性以外的多种语义：比如公平/非公平策略、可中断的 acquireInterruptibly()、带超时的 tryAcquire(long, TimeUnit)。而 synchronized 是 JVM 层的互斥锁，不可中断、无超时、不支持公平性配置。
更关键的是：Semaphore(1) 允许多个线程排队争抢同一许可，但 synchronized 锁定的是对象监视器，两者调度机制和唤醒逻辑完全不同。实际压测中，高并发下 Semaphore 的排队开销略大，但灵活性远超 synchronized。
如何正确释放 permit 避免泄漏
Semaphore 不像 ReentrantLock 有 lock()/unlock() 的成对强约束，release() 调用错误会导致许可数异常增长，进而破坏限流逻辑。最稳妥的方式是用 try-finally 包裹：
semaphore.acquire();
try {
// 执行受控操作
} finally {
semaphore.release(); // 必须放在这里，哪怕抛异常也要归还
}
- 不要在
catch块里释放 —— 正常流程也会走到finally，重复调用release()会让许可数超过初始化值 - 避免在异步回调中释放 —— 若回调执行在线程池不同线程，可能触发
IllegalMonitorStateException（虽然Semaphore本身不限制线程，但业务逻辑可能隐含上下文依赖） - 调试时可临时加日志：
System.out.println("released, available=" + semaphore.availablePermits());
fair 参数对排队行为的实际影响
创建 Semaphore 时传 true 表示启用公平模式：new Semaphore(5, true)。这会让等待线程按 FIFO 顺序获取许可；默认 false 是非公平的，允许后来的线程“插队”抢到刚释放的 permit。
公平模式能减少饥饿，但吞吐量通常下降 10%–20%，尤其在高竞争场景。是否开启取决于业务 SLA 要求：
- 支付类系统（需确定性响应顺序）建议设为
true - 缓存穿透防护、API 限流等对顺序无要求的场景，保持默认
false更高效 - 注意：公平性只作用于等待队列，不影响
tryAcquire()这种非阻塞尝试
常见误用：把 Semaphore 当作计数器或状态标志
有人用 semaphore.availablePe 判断“是否已满”，这是危险的 —— 该方法返回的是**当前瞬时可用数**，多线程下无法保证判断后立即执行的动作仍满足条件。
正确做法永远围绕 acquire() / release() 的原子语义展开：
- 限流控制必须用
acquire()阻塞或tryAcquire()判断，而不是轮询availablePermits() -
drainPermits()是清空所有可用许可并返回数量，常用于“紧急熔断”，但之后需重新release(n)恢复，否则永久卡死 - 不要用
getQueueLength()做监控阈值告警 —— 它返回的是等待线程数，但 AQS 队列可能包含已被取消的节点，数值不稳定
真正需要精确计数或状态管理时，应该换用 AtomicInteger 或 CountDownLatch，别硬套 Semaphore。
