aqs用volatile int state而非atomicinteger，因其需轻量级happens-before保证且cas由unsafe直接操作更高效；acquire负责排队与恢复，tryacquire由子类实现具体获取逻辑；clh为逻辑队列，靠前驱通知而非自旋；conditionobject另起单向等待队列以隔离条件等待与锁竞争语义。
为什么 AQS 用 volatile int state 而不是 AtomicInteger
因为 state 的读写必须和内存可见性、重排序约束强绑定，而 volatile 恰好提供最轻量的 happens-before 保证；AtomicInteger 多了一层方法调用和对象封装，在 AQS 的核心路径（如 compareAndSetState）中会引入无谓开销。AQS 自己用 Unsafe.compareAndSwapInt 实现 CAS，直接操作 volatile 字段更高效。
常见误判：以为 “原子类更安全”，其实 AQS 的线程安全不靠原子类，而靠状态机 + CAS + 队列协作。用 AtomicInteger 反而会让子类难以复写 getState/setState 等模板方法。
acquire 和 tryAcquire 的分工边界在哪
acquire 是 AQS 提供的顶层模板方法，负责公共逻辑：先调用 tryAcquire 尝试获取锁；失败则入队、挂起、等待唤醒；被唤醒后再次尝试。它不关心“怎么判是否能获取”，只管“怎么排队和恢复”。
tryAcquire 必须由子类实现，决定具体语义：
立即学习“Java免费学习笔记（深入）”；
- 对于
ReentrantLock.NonfairSync：直接 CAS 修改state，不检查队列是否为空 - 对于
ReentrantLock.FairSync：先检查hasQueuedPredecessors()，再 CAS - 对于
Semaphore：判断剩余许可数是否足够
容易踩的坑：tryAcquire 返回 false 后，AQS 会无条件把当前线程包装成 Node 加入同步队列——如果你在 tryAcquire 里做了阻塞或重试，就破坏了 AQS 的协作契约。
CLH 队列为什么是「逻辑上的」而不是真实链表
AQS 的队列叫 CLH（Craig, Landin, and Hagersten），但它不是标准 CLH：真实节点只有 prev 和 next，没有自旋字段；等待逻辑靠 LockSupport.park() 实现，而非自旋。所以它是“CLH 思想的变种”——用前驱节点的状态通知后继，但不自旋。
关键设计点：
- 入队时只设置
prev，next由前驱节点在唤醒后置（避免并发写next冲突） - 每个节点的
waitStatus初始为0，被前驱设为SIGNAL后才可安全挂起 - 取消节点（
CANCELLED）会被前驱跳过，形成“逻辑断连”，物理指针仍存在
这导致一个常见困惑：打印队列时看到 next == null，不等于节点不在队列里——它可能只是还没被前驱链接上。
为什么 ConditionObject 要另起一套等待队列
因为 await() 不是释放锁后“重新竞争”，而是释放锁 + 进入条件等待 + 被 signal() 唤醒后重新竞争同步状态。如果复用 AQS 同步队列，就会混淆“因锁竞争阻塞”和“因条件不满足阻塞”两种语义。
ConditionObject 的等待队列是单向链表（firstWaiter / lastWaiter），节点类型也是 Node，但 waitStatus == Node.CONDITION，且不参与 AQS 的 acquire 流程。
关键转换点：
-
await()：先完全释放锁（可能多次setState），再把自己加入条件队列，最后调用LockSupport.park() -
signal()：把条件队列头节点移到 AQS 同步队列尾部，并设waitStatus = 0，触发后续竞争
这里最容易忽略的是：一个 Condition 对应一个等待队列，但多个 Condition 共享同一个 AQS 同步队列——所以 signalAll() 是把整个条件队列迁移过去，不是广播。
// 示例：ReentrantLock 中 fair tryAcquire 的简化逻辑
protected final boolean tryAcquire(int acquires) {
final Thread current = Thread.currentThread();
int c = getState();
if (c == 0) {
// 公平模式下，必须确保前面没人排队
if (!hasQueuedPredecessors() &&
compareAndSetState(0, acquires)) {
setExclusiveOwnerThread(current);
return true;
}
}
else if (current == getExclusiveOwnerThread()) {
int nextc = c + acquires;
if (nextc < 0)
throw new Error("Maximum lock count exceeded");
setState(nextc);
return true;
}
return false;
}
AQS 的精妙不在代码多复杂，而在所有状态变更都收敛到几个原子操作（state、head、tail、waitStatus）和两套队列的职责隔离上。真正难 debug 的，永远是条件队列和同步队列之间的状态迁移时机，以及 waitStatus 在各种取消/中断场景下的跃迁路径。 
