AQS线程调度的底层基础是LockSupport的许可机制：每个线程自带初始为0的二值permit，unpark设为1，park检查并清零或阻塞；该机制支持精确唤醒、无需锁上下文、许可可预支，克服了wait/notify的随机性、锁依赖以及时序问题。
许可机制是 AQS 线程调度的底层基础
AQS 不靠对象监视器，也不用 synchronized 或 wait/notify，它把每个等待线程看作一个节点（Node），每个节点内部关联一个线程。这个线程是否挂起、何时唤醒，完全由 LockSupport.park() 和 unpark() 控制。核心在于：每个线程自带一个二值许可（permit），初始为 0；unpark(Thread) 就是把目标线程的 permit 设为 1；park() 则先检查自己的 permit 是否为 1 —— 是就清零并立即返回，否则阻塞。
acquire 流程中 park 如何“按住”线程
当线程调用 acquire（比如 ReentrantLock.lock()）失败时，AQS 会把它封装成 Node 加入同步队列尾部，并执行：
- 调用 LockSupport.park(this) —— 注意不是 park() 无参版，而是带 blocker 的重载，便于调试时定位阻塞原因
- 此时若该线程尚未被 unpark 过，permit=0，线程进入 WAITING 状态，JVM 将其挂起，不消耗 CPU
- 挂起前，AQS 会设置线程的 parkBlocker 字段指向当前 AQS 实例，这样 jstack 能看到 “parking to wait for
”
release 流程中 unpark 如何精准“松开”下一个线程
释放锁（release）成功后，AQS 会尝试唤醒队列中头节点的后继节点（head.next），但只唤醒一个，不广播：
- 取出 head.next 对应的 Node，从中拿到 thread 字段
- 调用 LockSupport.unpark(node.thread)，向该线程发放一个许可
- 如果该线程正处于 park 状态，立刻被唤醒；如果还没 park（比如刚入队、还没来得及执行 park），许可已预存，下次 park 直接返回
- 这种“唤醒可预支”的特性，让 AQS 避免了 wait/notify 的时序依赖问题，也支撑了非公平锁的抢占逻辑
为什么不能用 wait/notify 替代 park/unpark
AQS 需要满足三个关键约束，而 wait/notify 全部不满足：
立即学习“Java免费学习笔记（深入）”；
- 精确控制单个线程：notify 是随机唤醒，notifyAll 效率低；unpark 明确指定 Thread 对象
- 无需持有锁即可操作：park/unpark 可在任意上下文调用；wait/notify 必须在 synchronized 块内
- 许可可前置发放：AQS 在 tryAcquire 失败前就可能触发 unpark（如条件队列迁移），或在节点入队后立即 unpark 后继（公平锁优化），这依赖 permit 的可累积性（虽不叠加，但可“欠着”）
