ReentrantLock 基于 AQS 实现，通过 volatile state 字段记录可重入计数，重写 tryAcquire/tryRelease 定义锁逻辑，用 CLH 队列管理等待线程，公平性由 acquire 分支控制，全程基于 CAS、volatile 和 LockSupport 实现。
ReentrantLock 的同步机制本质是基于 AQS（AbstractQueuedSynchronizer）构建的，它把“加锁/解锁”的逻辑转化为对 AQS 内部状态（state）的原子操作和等待队列的管理。
state 字段承载可重入计数
AQS 使用一个 volatile int 类型的 state 字段表示同步状态。ReentrantLock 将其复用为锁的持有次数：
- 初始值为 0，表示锁未被占用；
- 线程首次获取锁时，通过 CAS 将 state 从 0 改为 1；
- 同一线程再次获取（可重入），state 加 1；
- 每次释放锁，state 减 1，仅当 state 变为 0 时才真正释放锁并唤醒等待者。
独占模式下 tryAcquire / tryRelease 的语义定制
ReentrantLock 通过继承 AQS 并重写两个核心方法来定义锁行为：
- tryAcquire(int)：判断当前线程能否获取锁。需检查 state 是否为 0（无人持有），或 state > 0 且当前线程已是持有者（支持重入）；成功则更新 state 并返回 true；
- tryRelease(int)：尝试释放锁。仅当当前线程是持有者时才允许释放，并将 state 减 1；若 state 归零，清空 exclusiveOwnerThread 并返回 true，触发后续唤醒逻辑。
等待队列管理阻塞与唤醒
当线程抢锁失败，AQS 将其封装为 Node 节点加入 CLH 风格的 FIFO 同步队列：
立即学习“Java免费学习笔记（深入）”；
- 节点类型为 EXCLUSIVE（独占模式），表示等待获取排他锁；
- 入队后线程会自旋 + park 挂起，直到前驱节点释放锁并唤醒它；
- 唤醒后重新尝试 acquire，避免虚假唤醒导致状态错乱。
公平性由 acquire 逻辑分支控制
公平锁与非公平锁的区别不在队列结构，而在 tryAcquire 的实现时机：
- 非公平锁：先直接 CAS 抢锁（可能插队），失败再入队；
- 公平锁：始终检查队列是否有前驱节点（即是否有人在等），有则跳过抢锁，直接入队。
整个过程不依赖 monitor 或 synchronized 关键字，而是完全由用户态代码配合 CAS、volatile 和 LockSupport 实现，既保证了线程安全，又提供了可扩展的同步原语基础。
