LockSupport.unpark()能精准唤醒指定线程，notify()则随机唤醒同一锁等待队列中任一线程；前者通过传入Thread对象直接发放permit，后者依赖共享锁对象且无参数，无法控制目标，且unpark可前置生效而notify不可。
LockSupport.unpark() 能精准唤醒指定线程，notify() 则无法做到——这是由底层机制决定的本质差异，不是用法技巧能弥补的。
唤醒目标明确：直接传入 Thread 对象
unpark() 方法签名是 LockSupport.unpark(Thread thread)，必须显式传入要唤醒的线程实例。JVM 会把许可（permit）直接发给那个线程，其他线程完全不受影响。
- 你可以只唤醒生产者线程，不影响消费者；只唤醒某个重试任务线程，不波及其他工作线程
- 即使多个线程在 park() 等待，只要没被 unpark() 点名，就继续阻塞
- notify() 只能唤醒“同一个对象锁等待队列里的任意一个”，既不能选谁，也无法确认唤醒了谁
无需共享锁对象，避免耦合与误唤醒
notify() 必须和 wait() 使用同一个 synchronized 锁对象，所有用该锁调用 wait() 的线程都挤在一个等待队列里。一旦 notify() 被调用，JVM 随机挑一个放行——哪怕它根本不是你当前想通知的那个逻辑角色。
- 比如用 new Object() 作为通用锁，A、B、C 三个不同功能线程都用它 wait()，notify() 就像闭眼扔飞镖
- LockSupport 不依赖任何锁对象，每个线程有独立 permit，唤醒行为和线程身份强绑定
- 没有“锁对象生命周期管理”负担，也不用担心 notify() 调早了、锁被其他代码意外持有等问题
唤醒信号不会丢失，顺序无关更可靠
如果线程还没 park()，你就先调了 unpark()，这个许可会被安全保留，等它后续第一次 park() 时立刻返回。notify() 没有这种容错能力——调早了，信号彻底消失。
立即学习“Java免费学习笔记（深入）”；
- 典型场景：异步回调中快速完成前置准备后立即 unpark() 后续处理线程，不管对方是否已进入 park()
- notify() 提前调用等于白干，wait() 线程只能无限期挂起，调试时极难定位
- 这种“先发后到也有效”的特性，让 LockSupport 更适合事件驱动、状态机、协程调度等对时序鲁棒性要求高的场景
不触发锁竞争，唤醒后直接进入 RUNNABLE
notify() 唤醒的线程从 WAITING 进入 BLOCKED，必须重新抢夺 synchronized 锁才能继续执行；而 unpark() 唤醒的线程 park() 返回后直接变成 RUNNABLE，跳过了锁竞争阶段。
- 减少了不必要的上下文切换和锁开销
- 避免因锁争抢导致的唤醒延迟或饥饿现象
- 更适合高性能、低延迟的并发结构，如 AQS 队列节点的唤醒逻辑
