AQS核心是state语义与CLH变体队列协同：state由子类定义语义、volatile保证可见、CAS确保原子；CLH为双向队列，head为哨兵，唤醒目标是head.next，waitStatus控制调度；独占模式点对点唤醒，共享模式广播式唤醒；acquire流程为tryAcquire→addWaiter→acquireQueued，含自旋+阻塞混合策略。
想靠AQS拿高薪，不能只背“state+队列+模板方法”这九个字。面试官要的是你真正吃透它在真实并发场景中怎么起作用、为什么这么设计、踩过哪些坑——也就是能讲清逻辑、画出关键路径、指出性能取舍。
抓住 state 的语义与原子性边界
state 不是万能计数器，它的含义完全由子类定义，但所有操作必须守住两个底线：
- 可见性靠 volatile 保证：任何线程读 getState() 都能看到最新值，这是唤醒/判断的前提
- 修改必须用 compareAndSetState：setState(int) 是非原子的，直接调用可能引发状态覆盖（比如两个线程同时 tryRelease 导致 state 少减一次）
- 语义必须自洽：ReentrantLock 中 state=0 表示无锁；Semaphore 中 state=0 表示无许可；CountDownLatch 中 state=0 表示门已打开。混淆语义会导致锁永远无法释放或误唤醒
说清 CLH 变体队列的真实行为
别再说“AQS 用 CLH 队列”——它其实是 CLH 的双向变体，关键不在结构，而在行为逻辑：
- 入队不是“加到尾部就完事”：addWaiter() 用 CAS 拼尾节点，失败就重试，避免竞争导致链表断裂
- 头节点不存等待线程：head 哨兵节点仅作占位，真正等待的是 head.next；释放锁时唤醒的是 head.next，不是 head 自身
- waitStatus 是调度开关：SIGNAL(-1) 才触发 unpark；CANCELLED(1) 节点会被前驱节点主动跳过，不参与唤醒链
能对比独占 vs 共享模式的关键差异
这不是概念题，是设计判断题。高薪岗会追问“为什么 CountDownLatch 用共享模式，而 ReentrantLock 必须独占？”
立即学习“Java免费学习笔记（深入）”；
- 独占模式：acquire() → tryAcquire() 成功则结束；失败则入队 + park；release() 只唤醒一个后继（head.next）
- 共享模式：acquireShared() → tryAcquireShared() 返回 ≥0 才成功；释放时 releaseShared() 可能连续唤醒多个后继（比如最后一个 countDown() 让 state=0，所有等待线程都该放行）
- 关键区别在唤醒粒度：独占是“点对点”，共享是“广播式”。错用模式会导致线程饿死或资源泄露
点出模板方法背后的真实控制流
别光列 acquire() / release() 方法名。要画出实际执行链条，并说明每一步谁负责、谁兜底：
- acquire(int arg) = tryAcquire(arg) → 失败 → addWaiter(Node.EXCLUSIVE) → acquireQueued(node, arg)
- acquireQueued 的核心是：只有当前驱是 head 且 tryAcquire 再次成功，才真正获取成功；否则 continue park —— 这就是“自旋+阻塞”混合策略
- interruptibly 版本会在 park 期间响应中断，抛出 InterruptedException；而普通 acquire 不响应，中断只是设置线程 interrupt status
