LockSupport.park() 不阻塞是因为其依赖线程的permit状态：若此前已调用unpark()，permit存在则park()直接返回；多次unpark仅保留一个permit，且不保证唤醒顺序或内存可见性。
LockSupport.park() 为什么有时不阻塞？
因为 park() 检查的是线程的“许可”（permit）状态，不是锁或标志位：有 permit 就直接消费并返回，没 permit 才真正挂起。如果之前调过 unpark()，permit 已被提前发放，park() 就会秒返回——这常被误以为“没生效”。
常见错误现象：park() 调用后线程继续执行，没停住；或者在循环里反复调用 park() 却没效果。
- 必须确保
park()前没有残留的 permit（比如前一次unpark()没被消费） - 不能依赖
park()的“阻塞行为”做同步判断，它不保证顺序、也不清空历史 permit - 典型场景：手写锁、条件等待、协程调度器中做轻量级挂起，但别拿来替代
Object.wait()或Condition.await()
unpark() 唤醒的是哪个线程？
unpark(Thread) 只影响目标线程的 permit 状态，和调用时机无关——哪怕目标线程还没执行到 park()，permit 也已存在，后续 park() 直接返回。这是它比 notify() 更灵活、也更难调试的地方。
容易踩的坑：
立即学习“Java免费学习笔记（深入）”；
- 对已终止的线程调用
unpark()无效，但不会报错，容易漏掉唤醒 - 对同一个线程多次
unpark()，permit **不会叠加**，只保留一个（即“最多一个许可”） - 如果唤醒了错误线程（比如线程对象被复用或重用），可能导致本该阻塞的线程意外继续
示例：LockSupport.unpark(workerThread) 发出许可后，worker 线程下次调用 park() 就不会挂起——哪怕此时它正在忙别的事。
park() 和 interrupt() 能共存吗？
能，但行为要小心：如果线程在 park() 中被中断，它会立即返回，并且 Thread.interrupted() 返回 true；但 park() 本身**不抛异常**，也不会清除中断状态（除非你手动调用 interrupted()）。
关键点：
- 不要靠是否抛异常来判断是否被中断——
park()从不抛InterruptedException - 检查中断应放在
park()返回后：if (Thread.currentThread().isInterrupted()) { … } - 如果想让中断优先于 park 生效，需在 park 前先检查中断状态，避免“刚设中断、就 park、然后忽略”
性能影响小，但逻辑上容易漏掉中断响应，尤其在自定义线程池任务调度中。
为什么不用 wait/notify 而选 park/unpark？
核心区别在于：wait 必须在 synchronized 块内、依赖对象监视器、受锁竞争影响；而 park() 是 JVM 层的原语，无锁、无 monitor、可对任意线程操作，适合构建更底层的并发结构（如 AQS）。
但代价是：它不提供内存可见性保障（不像 wait/notify 隐含 happens-before），也不自动关联条件谓词。
- 使用
park()前，通常要配合 volatile 变量或Unsafe内存屏障来保证状态可见 - 无法像
Condition.await()那样绑定到特定条件上，得自己维护“该不该 park”的判断逻辑 - 调试困难：jstack 显示线程在
park()状态，但看不出它等什么、谁该唤醒它
真正需要精确控制线程生命周期、又不愿被 synchronized 绑定时，才值得用。多数业务代码，老实用 synchronized + wait/notify 或 ReentrantLock + Condition 更稳妥。
