LockSupport.unpark能精准唤醒指定线程，关键在于其基于permit机制：unpark发放许可，park消费许可，许可可预存不丢失；而notify/notifyAll依赖同步块和等待队列，易信号丢失且无法指定目标。
LockSupport.unpark 能实现比 notifyAll 更精准的线程唤醒，关键不在“唤醒能力更强”，而在于它不依赖共享监视器、不丢失信号、且可跨线程任意调度。用错场景或忽略 permit 语义，反而会引发隐性死锁或唤醒失效。
为什么 unpark(Thread) 不会丢失唤醒信号
因为 unpark 发放的是一个“许可（permit）”，每个线程最多持有一个；即使目标线程还没执行到 park()，许可也已存在，后续调用 park() 会立即消费并返回——这和 notify() 必须在对方 wait() 之后才有效完全不同。
常见错误现象：
- 主线程先 notify()，子线程后 wait() → 永久阻塞
- 用 unpark() 先发，子线程再 park() → 正常继续
使用场景：
- 启动阶段预唤醒（如线程池 worker 初始化后主动 unpark）
- 异步回调中唤醒特定等待线程（如 RPC 响应匹配 request-id）
注意：
- 对已终止的线程调用 unpark() 无效但不报错，容易漏掉唤醒
- 多次 unpark() 同一线程，permit 不叠加，只保留一个
如何避免唤醒错误线程导致逻辑错乱
unpark() 是“指名道姓”的操作，但线程对象可能被复用（比如线程池中 Thread 实例被重复使用），若未及时清理旧状态，就可能唤醒本不该醒的逻辑上下文。
实操建议：
- 不直接持有裸 Thread 引用，改用带生命周期标识的 wrapper（如 WorkerHandle 封装 Thread + state + id）
- 在 park() 前检查业务条件（例如用 volatile boolean 标记“是否已就绪”），防止 permit 被误消费
- 若需严格顺序控制（如 A→B→C），确保 unpark(b) 在 A 的逻辑完成之后、且 B 尚未开始处理前执行，否则 B 可能提前消费 permit 并跳过等待
park() 不抛 InterruptedException 是双刃剑
park() 被中断时只设置中断状态，不抛异常，也不清中断标志——这让你能自主决定是否响应中断，但也极易漏掉中断处理。
容易踩的坑：
- 在循环中反复 park()，却没检查 Thread.interrupted()，导致无法响应 shutdown
- 以为 park() 抛异常就能捕获中断，结果逻辑卡死
正确做法：
- 每次 park() 前先检查 Thread.interrupted()，决定是否跳过阻塞
- 或在 park() 返回后立刻调用一次 Thread.interrupted() 清除并响应
- 示例：
if (Thread.interrupted()) {<br> return; // 或抛 RuntimeException<br>}<br>LockSupport.park();<br>if (Thread.interrupted()) {<br> cleanup();<br> return;<br>}
与 notifyAll 相比，真正省在哪
notifyAll 唤醒所有等待线程，靠竞争锁+条件重判来筛选有效者，本质是“广播+过滤”；而 unpark() 是点对点直达，省掉了：
- synchronized 锁竞争开销
- 条件变量的 while 循环重检（避免虚假唤醒）
- 线程从 WAITING → BLOCKED → RUNNABLE 的状态切换成本
但代价是：你必须自己维护线程身份、生命周期和唤醒时机。没有现成的“等待队列”抽象，也没有自动的条件绑定——这些都得编码实现。AQS 底层用 park/unpark 构建 ReentrantLock，正是因为它把调度权交还给上层，而不是封装成黑盒。
复杂点往往藏在“谁该被唤醒”和“什么时候发放 permit”这两个问题里，而不是调用本身。
