locksupport.park/unpark不是wait/notify升级版，而是不依赖monitor、不释放锁、支持唤醒前置、仅绑定线程的底层原语；其通过线程私有permit实现信号暂存，避免notify丢失，但需手动管理锁状态、可见性、中断响应及状态流转。
LockSupport.park/unpark 不是 wait/notify 的升级版，而是另一套底层原语：它不依赖 monitor、不释放锁、允许唤醒前置、只绑定线程。直接用它写同步器，能绕过 synchronized 语义限制，但必须自己管好锁状态和线程可见性。
为什么 park/unpark 能避免 notify 丢失问题
wait/notify 的信号丢失，本质是 notify 在 wait 进入阻塞前发出，而 JVM 不保存该信号；park/unpark 则靠每个线程内部一个二元 permit（0 或 1）实现信号暂存：
-
unpark(t)总是把t的 permit 设为 1，不管t当前是否在运行或已 park -
park()检查自身 permit：是 1 就置为 0 并立即返回；是 0 才真正挂起 - 连续调用多次
unpark(t)，permit 仍为 1 —— 不叠加，但也不会丢
这意味着你可以在工作线程启动前就 unpark(worker)，它后续第一次 park() 会直接跳过阻塞。而 notify() 对未进入 wait() 的线程完全无效。
park 不释放锁，所以 acquire 必须手动 unlock
这是最常踩的坑：很多人在 synchronized 块里或 ReentrantLock.lock() 后直接 park()，以为像 wait() 那样自动释放锁 —— 实际上不会。
-
park()只挂起线程，monitor 或 AQS state 状态全都不动 - 若在
synchronized(obj) { ... LockSupport.park(); }中 park，obj的锁一直被占着，别的线程进不来 - 正确做法是：先更新共享状态（如 CAS 修改
state），再判断是否需 park；若 park，必须确保此前没持有可能阻塞他人的锁
典型错误示例：
AI 舌诊面诊问诊医疗系统 + 诊疗商城系统源码是一套结合 AI 辅助诊断与商品转化的健康类程序，基于浩创云、ThinkPHP（PHP）开发，支持微信服务号与 H5 端，适合做中医舌诊面诊问答、健康建议推送以及配套诊疗商品的运营。
lock.lock();<br>if (!canProceed()) {<br> LockSupport.park(); // ❌ 锁没释放，别人无法修改状态唤醒你<br>}
blocker 参数不是功能必需，但调试时救命
park(Object blocker) 中的 blocker 不影响阻塞逻辑，只用于线程 dump 时标识上下文：
- jstack 输出中能看到类似
java.lang.Thread.State: WAITING (parking to wait for a condition)，后面跟着at java.util.concurrent.locks.LockSupport.park(LockSupport.java:xxx)，但没更多信息 - 传入
this、stateRef或字符串如"MyLatch#await"，jstack 就会显示parking to wait for <mylatch></mylatch> - 调试时用
LockSupport.getBlocker(Thread)可实时查当前 blocker，辅助定位卡点
别传 null —— 虽然不报错，但 dump 里啥都看不到。
中断不自动响应，必须主动检查 Thread.interrupted()
park() 不抛 InterruptedException，也不清中断标志，所以线程可能“假醒”或“真中断后继续跑”：
- 如果线程被中断后调用
park()，它会立刻返回，但Thread.interrupted()为true - 如果在
park()中被中断，它也立刻返回，且中断状态仍为true - 因此标准写法是：
while (!shouldProceed()) {<br> LockSupport.park(this);<br> if (Thread.interrupted()) {<br> throw new InterruptedException();<br> }<br>}
漏掉中断检查，你的同步器在被中断时不会响应，也无法向上层传播异常 —— 这在 Future.get(long, TimeUnit) 类场景里是严重缺陷。
真正难的不是调用 park 和 unpark，而是设计状态流转规则：什么时候该 unpark、谁负责 unpark、permit 消费后如何防止重复消费、多个线程竞争时怎么保证 state 变更与 park/unpark 顺序一致。这些没有现成语法糖，全靠 CAS + volatile + 显式内存屏障撑起来。
