AQS 的核心是 state 状态机、CLH 变种队列与 park/unpark 三支柱；state 不开放自增/自减以保障语义一致性，waitStatus 仅 0、CANCELLED、SIGNAL、CONDITION、PROPAGATE 五值有效，acquireQueued 中 park 前检查中断以实现“获取成功后才响应”，共享模式通过返回值正数触发传播唤醒。
理解 AQS 的关键不在通读全部源码，而在抓住它的状态机模型和等待队列协作机制——state 变量 + CLH 变种队列 + park/unpark 是三根支柱，其余都是围绕它们的封装和边界处理。
为什么 AbstractQueuedSynchronizer 不直接暴露 state 操作？
AQS 把 state 设为 volatile int，但只提供 getState()、setState(int) 和原子更新的 compareAndSetState(int, int)，不开放自增/自减。这是为了强制子类通过明确的语义控制同步状态：比如 ReentrantLock 用 state 表示重入次数，Semaphore 表示剩余许可数，CountDownLatch 表示倒计数值。直接修改会破坏状态含义的一致性。
常见误用：
- 在 tryAcquire() 中用 state++ 而非 compareAndSetState(old, old + 1) → 竞态下丢失更新
- 忘记在 tryRelease() 中校验当前线程是否持有锁（如 ReentrantLock 非公平模式下需检查 getExclusiveOwnerThread() == current）→ 导致非法释放
Node 节点的 waitStatus 哪些值真正影响排队逻辑？
waitStatus 是 Node 内部的状态标记，实际起作用的只有五个常量：
-
0：初始状态，刚入队未挂起 -
CANCELLED（1）：线程被中断或超时，该节点将被跳过且不会参与后续唤醒 -
SIGNAL（-1）：前驱节点释放后需唤醒本节点 → 这是“通知链”的核心标记 -
CONDITION（-2）：仅用于ConditionObject，表示在条件队列中等待 -
PROPAGATE（-3）：仅CountDownLatch和Shared模式下使用，表示共享传播需继续唤醒后继
注意：waitStatus 不是靠轮询更新的，而是由前驱节点在 shouldParkAfterFailedAcquire() 中主动设为 SIGNAL，再由它自己调用 LockSupport.park()。这个“前驱负责通知”的设计避免了竞态唤醒丢失。
立即学习“Java免费学习笔记（深入）”；
acquireQueued() 里为什么要在 park 前再 checkInterrupt()？
acquireQueued(final Node node, int arg) 的循环体中，每次 park 前都调用 Thread.interrupted() 检查中断状态，不是为了立即响应中断，而是为了区分「被唤醒是因正常释放」还是「被唤醒是因中断」。
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
这个细节决定了两种行为路径：
- 如果
park返回后发现是被中断唤醒，且尚未获得锁，则记录interrupted = true，但继续尝试获取（避免响应过早） - 只有在最终成功获取锁后，才根据
interrupted标志决定是否补发中断（selfInterrupt()）→ 这就是“可中断但不响应中断直到获取成功”的语义来源
漏掉这步会导致：中断信号在等待期间丢失，或者在未持锁时抛出 InterruptedException，破坏同步器的原子性保证。
共享模式（shared）和独占模式（exclusive）的核心差异在哪？
区别不在队列结构，而在唤醒策略和状态更新逻辑：
- 独占模式：一次只唤醒一个后继节点（
unparkSuccessor()），tryAcquire()返回true即认为获取成功 - 共享模式：获取成功后需调用
setHeadAndPropagate(node, r)，判断是否要继续唤醒后继（例如r > 0表示还有剩余资源）→ 这是doReleaseShared()存在的原因 -
tryAcquireShared()返回值语义不同：负数表示失败，0 表示成功但不传播，正数表示成功且可传播
典型陷阱：Semaphore 使用共享模式，但如果 tryAcquireShared() 错误返回 0（而非剩余许可数），会导致只唤醒一个等待者，即使还有多个许可可用。
真正难啃的不是 acquire 或 release 的主干逻辑，而是各种边界条件下节点如何安全出队、如何避免虚假唤醒、以及 propagate 和 cancel 之间如何协作——这些都在 cancelAcquire()、doReleaseShared() 和 fullyRelease() 的几十行代码里反复博弈。
