LockSupportpark与unpark使用详解

本文深入解析了Java中LockSupport的park与unpark机制，揭示其核心依赖线程“许可（permit）”而非锁或标志位的独特行为：unpark提前发放许可可使后续park立即返回，导致看似“不阻塞”的常见误区；强调多次unpark不叠加、唤醒对象易错、中断处理需手动检查等关键陷阱；并对比wait/notify指出park/unpark无锁、跨线程灵活但缺乏内存可见性保障和条件绑定能力，适用于AQS、协程调度等底层并发组件开发，而日常业务逻辑仍推荐更安全成熟的同步原语。

LockSupport.park() 为什么有时不阻塞？

因为 park() 检查的是线程的“许可”（permit）状态，不是锁或标志位：有 permit 就直接消费并返回，没 permit 才真正挂起。如果之前调过 unpark()，permit 已被提前发放，park() 就会秒返回——这常被误以为“没生效”。

常见错误现象：park() 调用后线程继续执行，没停住；或者在循环里反复调用 park() 却没效果。

• 必须确保 park() 前没有残留的 permit（比如前一次 unpark() 没被消费）
• 不能依赖 park() 的“阻塞行为”做同步判断，它不保证顺序、也不清空历史 permit
• 典型场景：手写锁、条件等待、协程调度器中做轻量级挂起，但别拿来替代 Object.wait() 或 Condition.await()

unpark() 唤醒的是哪个线程？

unpark(Thread) 只影响目标线程的 permit 状态，和调用时机无关——哪怕目标线程还没执行到 park()，permit 也已存在，后续 park() 直接返回。这是它比 notify() 更灵活、也更难调试的地方。

容易踩的坑：

• 对已终止的线程调用 unpark() 无效，但不会报错，容易漏掉唤醒
• 对同一个线程多次 unpark()，permit **不会叠加**，只保留一个（即“最多一个许可”）
• 如果唤醒了错误线程（比如线程对象被复用或重用），可能导致本该阻塞的线程意外继续

示例：LockSupport.unpark(workerThread) 发出许可后，worker 线程下次调用 park() 就不会挂起——哪怕此时它正在忙别的事。

park() 和 interrupt() 能共存吗？

能，但行为要小心：如果线程在 park() 中被中断，它会立即返回，并且 Thread.interrupted() 返回 true；但 park() 本身**不抛异常**，也不会清除中断状态（除非你手动调用 interrupted()）。

关键点：

• 不要靠是否抛异常来判断是否被中断——park() 从不抛 InterruptedException
• 检查中断应放在 park() 返回后：if (Thread.currentThread().isInterrupted()) { … }
• 如果想让中断优先于 park 生效，需在 park 前先检查中断状态，避免“刚设中断、就 park、然后忽略”

性能影响小，但逻辑上容易漏掉中断响应，尤其在自定义线程池任务调度中。

为什么不用 wait/notify 而选 park/unpark？

核心区别在于：wait 必须在 synchronized 块内、依赖对象监视器、受锁竞争影响；而 park() 是 JVM 层的原语，无锁、无 monitor、可对任意线程操作，适合构建更底层的并发结构（如 AQS）。

但代价是：它不提供内存可见性保障（不像 wait/notify 隐含 happens-before），也不自动关联条件谓词。

• 使用 park() 前，通常要配合 volatile 变量或 Unsafe 内存屏障来保证状态可见
• 无法像 Condition.await() 那样绑定到特定条件上，得自己维护“该不该 park”的判断逻辑
• 调试困难：jstack 显示线程在 park() 状态，但看不出它等什么、谁该唤醒它

真正需要精确控制线程生命周期、又不愿被 synchronized 绑定时，才值得用。多数业务代码，老实用 synchronized + wait/notify 或 ReentrantLock + Condition 更稳妥。

今天关于《LockSupportpark与unpark使用详解》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！