LockSupport.park() 为什么线程没反应？
它根本不会“挂起线程”——park() 只是检查当前线程的许可（permit）是否为 1，是就消费掉并立即返回；否则阻塞。没有“主动挂起”的语义，只有“等待许可”。常见错误是调用 park() 前没确保许可可用，结果线程直接卡住。
- 许可是二值的：0 或 1，不可叠加（多次
unpark()只保留一次效果） -
park()不响应中断，但会设置线程的中断状态（Thread.interrupted()为 true） - 如果线程已中断后调用
park()，它仍会阻塞，只是返回后你得手动处理中断逻辑 - 不要在循环外裸调
park()，典型模式是 while + 条件检查 +park()
unpark() 提前发了，park() 还会阻塞吗？
不会。unpark(Thread) 是“发许可”，只要目标线程还没消费，下次调用 park() 就直接返回。这是它和 Object.wait() 最关键的区别：许可可“预支”，不依赖调用顺序。
-
unpark()对已终止线程无效，但也不会报错 - 对未启动线程调用
unpark()是安全的，启动后首次park()立即返回 - 同一个线程反复
unpark()多次，等效于只发一次许可（许可无法累积） - 注意：许可归属线程，不是调用者；
unpark(t)给t发，不是给当前线程发
底层怎么做到“无锁挂起”？
HotSpot 里 park()/unpark() 最终走的是 OS 层的线程阻塞原语（如 Linux 的 pthread_cond_wait() / pthread_cond_signal()），但封装了一层 Unsafe.park() —— 它绕过了 JVM 的 monitor 锁机制，不进 ObjectMonitor 队列，也不参与 synchronized 语义。
- 没有竞争时，
park()是轻量级的系统调用（非忙等） - 被
unpark()唤醒的线程不保证立刻执行，只是从阻塞态转为就绪态，仍需调度器安排 - 在 GC 安全点附近调用
park()可能被延迟唤醒（JVM 会等安全点再真正挂起） - 不能替代
synchronized或ReentrantLock做同步，它只负责阻塞/唤醒，不提供内存可见性保障（需配合 volatile 或VarHandle）
为什么 LockSupport 被 AQS 当作基石？
因为 park() 和 unpark() 是唯一能精准控制单个线程阻塞/唤醒、且不依赖对象监视器的 JVM 原语。AQS 的 acquire()/release() 流程靠它把线程“按住”或“松开”，而不用管锁对象、条件队列这些上层抽象。
立即学习“Java免费学习笔记（深入）”；
- AQS 中每个节点（Node）对应一个线程，
park()挂起的是节点里存的线程，不是当前线程本身 -
unpark()在释放锁时触发，但只唤醒 head.next，不是广播唤醒所有等待者 - 如果你手写同步器，忘记在合适时机
unpark()，就会永久挂起；多调一次，只是浪费一次许可 - 调试时看到线程状态为
WAITING (parking)，说明它正卡在park()，此时查谁该发unpark()更有效
unpark() 调少了、调早了，或者压根没调。 
