AQS 通过 volatile int state 实现 ReentrantLock 的可重入、公平性与释放逻辑：state=0 表示空闲，state=N 表示同线程重入 N 次；结合 exclusiveOwnerThread 判断重入；公平性由是否检查队列决定；state 归零才触发唤醒。
AQS 的状态管理机制是 ReentrantLock 实现可重入、公平性控制与锁释放逻辑的底层支柱。它不依赖 JVM 隐式锁机制，而是用一个 volatile int state 变量精准刻画锁的持有状态，让 ReentrantLock 能自主决定“谁在持锁”“持了多少次”“是否该唤醒下一个线程”。
state 变量直接支撑可重入语义
ReentrantLock 允许同一线程多次调用 lock() 而不阻塞，这完全由 state 的数值化表达实现：
- state = 0：锁空闲，无任何线程持有
- state = 1：被某线程首次获取
- state = N（N > 1）：同一线程已重入 N 次，每次
lock()都使 state 原子递增 - 每次
unlock()都原子递减 state；仅当 state 减至 0 时才真正释放锁并唤醒队列首节点
state 与线程身份绑定实现重入校验
AQS 本身不记录持有线程，但 ReentrantLock 的 Sync 子类在 tryAcquire 中额外维护了 exclusiveOwnerThread 字段：
- 获取锁前先检查当前线程是否已是持有者 → 是，则只做 state++，不入队
- 若 state == 0 且 exclusiveOwnerThread 为 null，才尝试 CAS 设置 owner 并置 state = 1
- 这种“state + 线程引用”的组合，构成了可重入判断的完整依据，比单纯计数更安全
state 值驱动公平/非公平策略差异
公平性不是靠“排队顺序”本身保证的，而是靠对 state 和队列状态的联合判断：
立即学习“Java免费学习笔记（深入）”；
- 非公平锁：
lock()直接尝试 CAS 修改 state，成功即抢到锁，不管队列是否有等待者 - 公平锁：
lock()先调用hasQueuedPredecessors()检查同步队列是否为空或自己是否为队首；只有队列为空时，才尝试 CAS 获取 state - 两种模式共享同一套 state 管理逻辑，差异仅在于“是否跳过队列检查”，state 始终是决策前提
state 归零是唤醒等待线程的明确信号
释放锁不只是“把锁还回去”，更是向等待队列发出“资源可用”的精确通知：
-
tryRelease(int)中，只有 state 减为 0 才返回 true，表示完全释放 - AQS 的
acquireQueued流程依赖这个返回值：true → 尝试唤醒后继节点；false → 继续挂起 - 如果 state 未归零（如重入锁只释放一次），即使调用了
unlock()，也不会触发唤醒，避免误唤醒
