locksupport.unpark()不能精确唤醒特定线程，因为它仅设置目标线程的permit状态，不校验线程是否存活、是否在park、甚至是否处于等待状态；许可可能被提前消费、滞后失效或因线程复用而发错对象。
LockSupport.unpark() 为什么不能“精确唤醒特定线程”
LockSupport.unpark(Thread) 确实接收一个 Thread 对象，看起来像是定向唤醒。但实际行为是：它只是给该线程的「许可（permit）」设为 1，**不关心线程当前是否挂起、是否在等待、甚至是否还存活**。如果线程没调用 LockSupport.park()，这个许可就静静留着；如果线程已终止，许可直接丢失；如果线程正在 park 中，它会立刻返回 —— 但这一切都和“唤醒逻辑”无关，只是 permit 的原子设置。
换句话说：unpark() 不是“发消息叫醒某人”，而是“往某人衣袋里塞一张入场券”。至于他有没有在门口排队、会不会用、会不会丢，全由他自己决定。
真正影响“谁被唤醒”的关键：park() 的调用时机与线程状态
所谓“精确唤醒”，本质依赖于你能否让目标线程恰好在你调用 unpark() 前进入 park()。否则许可可能提前消耗（比如线程先 park 再 unpark，许可被立即消费），也可能滞后失效（比如先 unpark 再 park，许可还在，但线程可能因其他条件继续阻塞）。
常见出错场景：
- 线程 A 执行
unpark(target)后，target 尚未执行park()→ 许可保留，但 target 后续 park 时不会阻塞（看似“唤醒成功”，实则时序错乱） - target 已 park 并被唤醒，但业务逻辑还没检查唤醒原因（比如是否因条件满足而醒），就直接继续执行 → 出现虚假唤醒或状态不一致
- 多个线程共享同一
Thread实例（如线程复用、池化），unpark()发给旧引用，而真正 park 的是新实例 → 完全无效
安全使用的三个硬性前提
要让 unpark() 表现出“定向唤醒”效果，必须同时满足：
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 目标线程对象在
unpark()调用时仍存活且唯一（不能是线程池中被回收又重建的同名线程） - 目标线程必须在
unpark()之前或之后、但在park()调用之前，**没有其他代码意外消费其 permit**（例如误调了park()两次，第二次会阻塞） - 业务逻辑必须配合自旋 + 条件检查，不能仅靠 park/unpark 同步状态。典型模式是：
while (!conditionMet()) {
LockSupport.park();
}
// 继续处理
这里的 conditionMet() 必须是 volatile 变量、AtomicBoolean 或其他线程安全判断，且修改与 unpark() 必须有 happens-before 关系（比如用 synchronized 块包裹条件更新和 unpark()）。
替代方案：什么时候该放弃 LockSupport 直接上更高级工具
如果你需要“唤醒指定 ID 的等待者”“按优先级唤醒”“批量唤醒符合条件者”，LockSupport 就不是合适选择。它只是 JVM 底层原语，不带调度语义。
更现实的选择：
- 用
Condition配合ReentrantLock：每个Condition实例天然绑定一个等待队列，signal()/signalAll()是明确的队列操作 - 用
BlockingQueue（如LinkedBlockingQueue）传递信号：把唤醒抽象为“入队一个哨兵对象”，目标线程从队列 take —— 真正解耦且可审计 - 对极少数需绕过锁机制的场景（如
Unsafe级别优化），才应直接使用LockSupport，且必须严格控制 permit 生命周期和线程生命周期的一致性
最常被忽略的一点：permit 是 per-thread 的，但 JVM 不保证跨 GC 周期的 Thread 引用有效性 —— 如果你在线程刚 start 后立刻保存其引用，又在 long-running 场景中长期持有，要注意弱引用或显式清理逻辑。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
