LockSupport 的 park/unpark 能精准控制单个线程，依赖线程绑定的二值许可机制：unpark 设许可为1（不叠加），park 检查并消费许可（为1则立即返回，为0则挂起）；许可可提前发放、跨调用有效；支持指定线程唤醒，避免唤醒丢失与随机性。

LockSupport 的 park 与 unpark 能精准控制单个线程，核心在于它的“许可（permit）机制”和线程级绑定能力——不依赖锁、不依赖对象监视器，直接对目标线程发号施令。

许可机制是精准控制的基础

每个线程内部关联一个二值许可（0 或 1），初始为 0：

• unpark(Thread t)：将 t 的许可设为 1（重复调用无效，不会叠加）
• park()：检查当前线程许可；若为 1，则原子置 0 并立即返回；若为 0，则挂起，等待被 unpark 或中断
• 许可属于线程本身，跨方法、跨类、跨栈帧都有效，只要能拿到 Thread 对象就能操作

唤醒指定线程，不靠运气

unpark 必须传入具体 Thread 实例，天然支持一对一控制：

• 对比 notify()：只能随机唤醒同一对象上 wait 的某个线程，无法指定谁该醒
• 对比 notifyAll()：唤醒全部，引发“惊群效应”，低效且难管理
• 而 LockSupport.unpark(worker) 明确指向 worker 线程，哪怕它还没 start、正在执行、或已 park，只要线程还活着，许可就生效

顺序无关，避免唤醒丢失

unpark 可以先于 park 执行，许可会“存住”，下次 park 直接消费：

• 主线程先 unpark(worker)，worker 后调 park() → 不阻塞，立刻继续
• worker 先 park()，主线程后 unpark(worker) → 被唤醒，恢复执行
• 这种“可提前发放许可”的特性，彻底规避了 wait/notify 中 notify 提前导致的永久等待问题

实际使用时的关键细节

要真正实现可靠精准控制，需注意三点：

• 始终持有目标线程引用：不能仅靠线程名查找，应显式保存 Thread 对象（如作为成员变量或通过回调传递）
• 配合状态变量判断条件：park 应放在 while 循环中，检查业务条件是否满足，防止虚假唤醒
• 主动响应中断：park 不抛 InterruptedException，但 Thread.interrupted() 可查中断状态，建议在 park 前后做判断并退出逻辑