信号量permit=1可实现互斥但非无缝替代ReentrantLock：它无所有权语义、不可重入、不支持Condition，仅适用于简单临界区、跨线程释放等特定场景。
当信号量的许可数设为 1 时，它在行为上确实能实现互斥效果，但“无缝替代”需要谨慎理解——它不是语法或语义上的等价替换，而是在特定约束下可达成相同临界区保护目标的一种选择。关键在于：它能守住执行边界（即同一时刻至多一个线程进入），但不继承互斥锁的“所有权语义”和配套能力。
核心差异决定能否“无缝”
信号量 permits=1 和 ReentrantLock 都能阻塞并发线程，但底层逻辑不同：
- ReentrantLock 要求“谁加锁谁解锁”：lock() 和 unlock() 必须由同一线程配对调用，否则抛出 IllegalMonitorStateException；支持可重入，也支持中断、超时、公平策略、Condition 等精细控制。
- Semaphore 不绑定线程所有权：acquire() 可由线程 A 执行，release() 却可由线程 B 执行（虽不推荐，但合法）。它没有可重入机制——连续 acquire 两次会阻塞，除非中间 release 一次；也不支持 Condition 或中断感知的等待队列。
适用“替代”的典型单机场景
以下情况中，permits=1 的 Semaphore 可以安全、简洁地承担互斥职责：
- 简单临界区保护：仅需串行化一段短小、无嵌套、无中断/超时需求的代码，例如更新一个共享计数器或写入日志缓冲区。
- 跨方法/跨线程释放需求：比如异步回调中释放资源（如 I/O 完成后释放许可），此时无法保证回调线程就是获取许可的线程，Semaphore 的无所有权特性反而是优势。
- 避免锁升级复杂度：在已使用 Semaphore 管理资源池（如连接池）的系统中，复用同一套 acquire/release 模式来保护某个全局开关，减少 API 认知负担。
实际编码注意事项
若决定采用 Semaphore(1) 替代 ReentrantLock，请注意这些实操细节：
- 必须手动确保配对：虽然 release() 允许任意线程调用，但业务逻辑仍应尽量让 acquire()/release() 成对出现在同一作用域（如 try-finally），否则易引发许可泄漏或过早释放。
- 不可重入需显式规避：若临界区内可能递归调用自身或调用其他需同样保护的方法，必须改用 ReentrantLock，或在 Semaphore 外加一层重入计数逻辑（不推荐，增加复杂性）。
- 超时与中断需换用 tryAcquire：要用 tryAcquire(long, TimeUnit) 实现带超时的获取，用 acquireUninterruptibly() 或捕获 InterruptedException 来处理中断——它不提供 lockInterruptibly() 那样语义清晰的中断入口。
- 公平性可选但非默认：new Semaphore(1, true) 可启用公平模式，使等待线程按 FIFO 获取许可，这点与 ReentrantLock(true) 行为一致。
不建议替代的情况
以下情形请坚持使用 ReentrantLock：
- 临界区包含“检查-更新”复合操作（如 if (x > 0) x--），且需防止条件竞争；
- 需要 await/signal 机制协调多个线程（如生产者-消费者），因 Semaphore 不提供 Condition；
- 要求可重入（如递归算法、AOP 切面多次进入同一方法）；
- 已有代码依赖 lock() 返回值、tryLock() 的布尔结果，或需与 synchronized 语义对齐做迁移评估。
