Java ReentrantLock 锁获取阻塞唤醒机制原理

ReentrantLock 中线程获取锁失败时的阻塞与唤醒机制，核心依赖的是 AQS 与 LockSupport 的组合，而非传统的 wait/notify。这套方案更加轻量、灵活，同时规避了 wait/notify 的诸多限制。先给出几个关键结论：整个过程基于 AQS 的 CLH 队列与 LockSupport 的 park/unpark 原语，公平锁与非公平锁在唤醒路径上存在本质差异。

阻塞：线程如何暂停等待锁？

当线程调用 lock() 但锁已被其他线程占用，且并非自身重入时，AQS 会将其封装为一个 Node 节点，追加到 CLH 同步队列尾部，并执行 LockSupport.park() 使其挂起。这里的 park() 是 JVM 层提供的底层阻塞原语，不依赖 synchronized，也无需在同步块中调用。被 park 的线程状态会变为 WAITING，不消耗 CPU 资源，也不会响应中断（除非使用 lockInterruptibly()）。每个线程内部都拥有一个私有的“许可”（permit），park() 会消耗该 permit；如果 permit 已用完，线程便可靠地进入阻塞状态。

唤醒：谁来唤醒线程？何时触发？

锁释放时（unlock()），AQS 会从同步队列头部开始，尝试唤醒下一个等待节点——调用 LockSupport.unpark(thread) 向目标线程发放一个 permit，使其恢复执行。注意，唤醒动作由释放锁的线程主动完成，并非锁本身“通知”，而是 AQS 按队列顺序逐个 unpark。被 unpark 的线程会重新进入锁竞争逻辑（tryAcquire()），成功则获取锁继续运行；失败则可能再次 park（例如在公平锁下仍有前序节点）。非公平锁允许新线程“插队”竞争，因此刚被 unpark 的线程不一定能立刻拿到锁。

与 wait/notify 的关键区别在哪里？

这套机制绕开了 Object 监视器模型的约束，解决了几个经典痛点：无需写在 synchronized 块中——park/unpark 可在任意位置调用；不需要持有某个对象的 monitor——不再绑定特定对象实例；不会因虚假唤醒而意外返回——park() 只有收到 unpark 或被中断才会返回；支持精准唤醒——unpark(Thread t) 可指定唤醒哪个线程，而 notify() 是随机选择。

公平性如何影响唤醒行为？

公平锁和非公平锁在唤醒路径上差异显著。公平锁严格按 CLH 队列顺序唤醒，先到先得，保证 FIFO 特性；非公平锁释放锁后，先让新来的线程尝试一次 CAS 获取锁，失败后才去唤醒队列头节点。这种“插队”机制可能提升吞吐量，但牺牲了公平性。最后，无论哪种锁，唤醒动作都只作用于队列头部节点，AQS 不会跳过中间节点——这是底层设计的基本底线。