1. 从一次线程卡死说起为什么要认识LockSupport先讲个我印象很深的排查经历。有一个线上服务深夜高峰期突然出现请求大量超时线程池里的工作线程全部堆在同一个调用点上CPU占用率却非常低。我抓了线程dump一看所有线程都停在同一个状态WAITING (parking)。当时对LockSupport还只是停留在知道有个类叫这个名字的程度于是赶紧去查那个调用链发现是框架内部用了LockSupport.park()做条件等待而某个上游返回异常后唤醒信号被提前消费掉了导致线程永久park住整个线程池被冻住。那次之后我把LockSupport的源码和AQS里对它的调用翻来覆去读了几遍才真正理解许可机制是怎么回事。这个类在java.util.concurrent里几乎是无处不在的——AQS队列同步器的acquireQueued、await、signal各种阻塞队列的put/take读写锁的阻塞等待底层全是通过LockSupport的park/unpark实现的。可以说不理解LockSupport你对JUC包的理解就始终隔着一层窗户纸。这篇文章我打算把LockSupport的许可机制掰开揉碎讲清楚包括它和wait/notify的本质区别、permit内部状态的流转过程、在AQS里是怎么被调用的典型场景、以及实际编码中最容易踩的几个坑。不管你是刚接触并发编程还是写了不少线程代码但总感觉哪里没想透这篇应该都能帮你把这块补上。2. 许可机制的本质一把只有两个档位的通行令牌2.1 许可证的底层模型LockSupport的核心就一个概念permit许可。你可以把它理解成一把只有一个座位的候车长椅——有人坐下椅子被占再来一个人就得站着等等人起身离开椅子上空出来了下一个等的人才能坐。但和真实椅子不同的是这个permit本质上是一个二元状态只有两个可能的值0和1。0代表没有许可1代表有一个许可。park()方法做的事情可概括为尝试消费一个许可如果当前permit为0线程就进入等待如果已经有许可则消费掉许可并立即返回。unpark(Thread thread)方法做的事情则是给指定线程发放一个许可如果该线程正因为缺少许可而park等待就把它唤醒。这里有几个非常关键的点我建议你先记住多次调用unpark(Thread)并不会累积多个许可。无论你调用多少次permit最多也就是从0变到1不可能变成2、3、4。也就是说这个许可不是计数器它不具备叠加能力。相应地你在代码里连续调用两次unpark想靠这个让线程连续两次从park()中穿过是做不到的。park()在拥有许可时不会阻塞。它会把那个1消费成0然后立刻返回。这一点意味着什么意味着先unpark后park是完全合法的——我先发一张许可证你后到也能直接凭票入场不需要排队等。这正是LockSupport和synchronized的wait/notify最根本的分水岭。permit初始值为0。刚创建出来的线程默认是没有许可的所以一个线程首次调用park()几乎必然阻塞如果没有其他线程提前对它调用过unpark的话。unpark的许可发放不要求持有锁。这就意味着你可以在任何地方、任何时机、只要持有目标线程的引用就能给它发放许可。从设计上看这个模型天然规避了wait/notify中那个著名的必须在同步块内调用的限制和通知丢失问题。2.2 为什么wait/notify做不到这件事要理解LockSupport的不可替代性我们需要回头看看synchronized体系下的wait/notify为什么会漏消息。Object.wait()的语义要求当前线程必须持有对象的monitor监视器锁然后才能释放锁并挂起。Object.notify()也必须在持有同一把锁的代码路径里调用。这生产了一个经典的时序困境一个线程准备wait而另一个线程此时恰好执行了notify如果notify发生在wait之前那么这次通知就彻底丢失了——等线程真的进入wait挂起时再也没有新的通知能唤醒它这就是著名的lost wakeup丢失唤醒问题。我记得一个很形象的说法wait/notify像是进屋开会谁先到谁发言错过会议记录就不再补发而LockSupport的许可机制像是入场券制先发券后入场照用不误。因为许可被保存在线程内部只要unpark执行成功这个许可就会一直在那里等着无论目标线程是在调用park之前还是之后收到它。正是这个特性让AQS里那些复杂的条件队列逻辑可以安全地处理竞态窗口。2.3 park/unpark的源码级别理解其实LockSupport的park()和unpark(Thread)内部都是通过Unsafe类的native方法实现的。在JDK 8及之前核心工作全部委托给UNSAFE.park()和UNSAFE.unpark()从JDK 9开始内部改为了VarHandle机制setBlocker相关的部分也换成了VarHandle的compareAndSet但对我们使用方来说语义完全一致。看源码时你会发现一个有趣的地方LockSupport里还有一个容易被忽略的伙伴对象——blocker。每次park之前都可以通过LockSupport.setBlocker(Thread, Object)来记录这个线程是因为什么而被阻塞的。它不参与许可的发放和消费逻辑纯粹是为了诊断和监控。public static void park() { UNSAFE.park(false, 0L); }park(boolean isAbsolute, long time)中如果isAbsolute为false表示相对时间time单位是纳秒如果为true表示绝对时间time是毫秒时间戳。但这两者在绝大多数常用场景里不需要我们直接操作JDK已经帮我们封装好了parkNanos、parkUntil这些便捷方法。所以你在线程dump里看到WAITING (parking)本质是线程进入到pthread_cond_wait这种底层等待状态操作系统层面的wait queue里挂着它。排查时我们经常把parking状态线程形象地叫做被吊起来的线程这个状态说明它不消耗CPU但也表示它在等一个可能永远不会来的唤醒信号。2.4 三次unpark也无法唤醒两次park这个点特别容易让人犯迷糊我用一个实际例子说明。Thread thread new Thread(() - { LockSupport.park(); System.out.println(第一次park返回); LockSupport.park(); System.out.println(第二次park返回); }); thread.start(); Thread.sleep(100); LockSupport.unpark(thread); LockSupport.unpark(thread); LockSupport.unpark(thread);你猜输出是什么很多人以为会打印两行park返回但实际上程序只会打印一行第一次park返回然后永远卡在第二次park上。原因就在那个permit只是一个布尔开关而不是计数器。三张许可证发过去开关最多从0翻到1第一park()消费掉这个1变成0第二个park()看到permit为0自然还是要阻塞等待。这个例子告诉我们一个非常重要的使用原则如果你想让一个线程在执行过程中连续跨越多个需要许可的检查点就必须在每个检查点之前单独发放许可而不是寄希望于提前发好几次攒着用。顺着这个思路你也就不难理解为什么Phaser、CyclicBarrier这些同步组件在内部处理跨代唤醒时要那么小心翼翼地去循环检查状态了。3. 从AQS到阻塞队列LockSupport的真实战场3.1 AQS和LockSupport的协同关系理解LockSupport最好的方式是去看它在AQSAbstractQueuedSynchronizer里是怎么被调用的。AQS是ReentrantLock、Semaphore、CountDownLatch、读写锁这些工具的中枢而AQS对于线程抢锁失败怎么办和条件不满足怎么办这两个问题答案都是同一个把线程包装成Node挂进队列然后用LockSupport.park()让它休息。以ReentrantLock为例线程抢占锁失败时会进入AQS的acquireQueued方法。我简化一下核心循环final boolean acquireQueued(final Node node, int arg) { boolean failed true; try { boolean interrupted false; for (;;) { final Node p node.predecessor(); if (p head tryAcquire(arg)) { setHead(node); p.next null; failed false; return interrupted; } if (shouldParkAfterFailedAcquire(p, node) parkAndCheckInterrupt()) interrupted true; } } finally { if (failed) cancelAcquire(node); } } private final boolean parkAndCheckInterrupt() { LockSupport.park(this); return Thread.interrupted(); }这个自旋加park的组合是AQS的灵魂线程先尝试几次CAS抢锁快速路径抢不到就通过shouldParkAfterFailedAcquire检查前驱节点的状态如果前驱已经进入等待状态说明自己也该睡了就调用LockSupport.park(this)把自己挂起。注意park的参数是this也就是AQS同步器的实例LockSupport会把它们记录为当前线程的blocker内容这样thread dump出来你能看到线程是因为哪个同步器对象而阻塞的。3.2 条件队列里的park/unpark舞步如果说acquireQueued展示的是park在互斥锁等待中的用法那么条件队列Condition里展示的就是park在条件等待中的完整套路。Object.wait/notify能干的事Condition都能干但Condition的底层不依赖synchronized而是依赖Lock和LockSupport的配合。当一个线程调用condition.await()时AQS内部会做这么几件事把当前线程封装成条件队列节点Condition Queue从同步队列中移出来释放掉持有的锁然后调用LockSupport.park(this)阻塞自己。等另一个线程调用condition.signal()时AQS会从条件队列里取出队首节点把它重新放回同步队列Sync Queue在signal的过程中事实上并不直接调用unpark——真正的unpark发生在该节点被移回同步队列并且成为合格前驱之后通过LockSupport.unpark(node.thread)来唤醒。代码里对应的方法主要是LockSupport.unpark配合shouldParkAfterFailedAcquire的前驱状态判断。这里有一件微妙的事signal只是完成节点搬移和状态修改真正的唤醒发生在节点有机会参与锁竞争的路上。如果条件队列里的线程被signal之后唤醒动作因为某些原因延迟而另一次signal已经到来那个节点依然保持等待。这个设计保证不丢唤醒正是第2节说的许可机制在起作用。3.3 阻塞队列的put/take另一个taker我们再看一个比AQS更上层的例子java.util.concurrent.ArrayBlockingQueue。它的take()和put()方法在队列空或者满的时候都会调用await系列方法阻塞生产者或消费者线程。你顺着源码一路追下去最终都会落在LockSupport.parkNanos或LockSupport.park上。所以我常跟团队里同学说JUC包里凡是你看到有线程进入阻塞等待的地方十有八九底层都是LockSupport在顶班。ThreadPoolExecutor里的worker线程在没有任务时也是通过getTask()方法里的workQueue.take()也就是LockSupport.park挂起。它和Object.wait最大的区别在于如果任务被放入队列时那个worker线程并没有在take()上等待而是还在处理上一个任务那么等它处理完再去take()时许可已经被消耗掉了——诶不对这里恰恰没必要消耗。我详细解释下队列的put操作实际是唤醒一个等待在take上的消费者如果没人等待这段唤醒就白做。传统wait/notify里这也都差不多。关键是生产者和消费者在锁已释放和信号已发出之间存在竞态窗口。LockSupport的permit机制让先存信号后用信号变成可能所以阻塞队列可以做到性能高、无锁化地唤醒在ConcurrentLinkedQueue LockSupport组合的ForkJoinPool里尤其明显却不会产生lost wakeup。这也是为什么SynchronousQueue和LinkedTransferQueue这些无界/直接交接的队列敢大量依赖park/unpark。它们的transfer方法就是反复tryTransfer不成则park线程等待match线程的到来。3.4 为什么AQS不用wait/notify这个问题面试里被问过无数次其实答案就藏在第2节的通知丢失和锁强依赖里。假设AQS用wait/notify来挂起抢锁失败的线程那么每次park挂起之前都必须持有某个对象的monitor每次唤醒也必须重新进入同一个monitor。可AQS是一个无锁的同步原语它在内部用CAS维护状态和队列试图在没有任何内置锁的前提下完成同步。如果依赖wait/notify就必须额外引入一把全局monitor锁那整个多线程竞争布局就全变味了轻则吞吐大幅下降重则锁顺序错乱导致死锁。另一个横向对比维度是语义表达力。wait/notify的唤醒是无差别广播notify是随机/特定一个notifyAll是一锅端而LockSupport的unpark是点对点定向唤醒目标线程明确不关心其他线程天然适配AQS里的公平队列唤醒。这种精确制导的唤醒方式配合节点前驱状态检查才可能实现公平锁那样排队叫号的效果。4. 实操细节与最佳实践什么时候自己用LockSupport4.1 封装一个可中断的限时等待工具很多人会用Thread.sleep去做等一段时间的逻辑但sleep有个现实问题它不释放任何锁而且响应中断是抛InterruptedException在业务代码中容易打断原有流程。我自己在项目中经常需要等待某个外部条件最多等N毫秒这种诉求用LockSupport就非常顺手。下面给出一个我实际用过的封装思路仅供参考public class ParkWaitUtil { public static boolean awaitReady(final SupplierBoolean readySupplier, final long timeoutMillis) throws InterruptedException { if (readySupplier.get()) return true; final long deadline System.currentTimeMillis() timeoutMillis; while (System.currentTimeMillis() deadline) { if (readySupplier.get()) return true; long remainingNanos (deadline - System.currentTimeMillis()) * 1_000_000L; LockSupport.parkNanos(remainingNanos); if (Thread.interrupted()) throw new InterruptedException(); } return readySupplier.get(); } }这里有几个细节值得说道说道。parkNanos调用之后醒来时线程不会自动清除中断标记注意我刻意用了Thread.interrupted()而不是Thread.isInterrupted()——前者会清除中断状态这样下面的逻辑可以继续执行而不至于带着一个脏标记。如果用后者一旦中断标志被置位后续每次parkNanos都会因为中断状态而立即返回形成忙等待这在实践中非常隐蔽。再说准确的超时策略我在这里先预计算绝对截止时间deadline每次循环用剩余纳秒做相对等待。为什么不用LockSupport.parkUntil(deadlineMillis)一次到位因为parkUntil在携带绝对时间戳的时刻如果系统时钟发生调整NTP同步、手动改时间等待时长会有不可控偏差。相对时间的parkNanos在大多数平台实现上则是基于单调时钟monotonic clock不受墙上时钟跳变影响。这也是并发库代码里频繁看到先取deadline再循环parkNanos的原因。4.2 在线程池里安全地park线程很多使用ExecutorService的同学会下意识地在任务里写LockSupport.park()想着让这个任务等一等。我要提醒你的是线程池里的线程是复用的把任务线程直接阻塞会影响整个池子的吞吐。如果一定要在线程池里使用park等待某个异步结果请务必设置超时而且要保证有兜底的unpark路径否则一旦上游忘了唤醒线程池的线程会一个个被耗尽在等待上。我遇到过一个真实案例某个项目用ForkJoinPool执行一些递归拆分任务子任务通过CompletableFuture去异步获取数据主任务在join的时候底层的ForkJoinPool通过ManagedBlocker机制去park和unpark。结果因为某个任务的异常导致future一直没有complete所有工作线程都在等待最后整个池子饿死。排查中我们看到ForkJoinPool里的worker大量处于WAITING (parking)而问题是异常被某个异步线程吞掉了。这个教训告诉我们使用park/unpark务必在设计阶段就判断清楚谁负责唤醒、超时兜底是什么、唤醒信号是否可能丢失。许可的丢失问题一旦发生在线上往往不是几十秒能定位出来的。4.3 中断响应有一个反直觉的规则这里有一个LockSupport的坑中之坑我重点讲。当LockSupport.park()被调用时如果当前线程已经被设置了中断标志那么park会返回但是中断标志不会被清除。这和Object.wait()的语义完全不同——wait在中断时会抛出InterruptedException并清除中断状态。LockSupport走的是另一条路park一感知到中断状态为true时就会立刻返回退出阻塞但线程的中断状态保持为true需要你主动去处理。Thread t new Thread(() - { LockSupport.park(); System.out.println(park返回了interrupted Thread.interrupted()); }); t.start(); t.interrupt();输出是park返回了interruptedtrue正因为park会对中断倾向性放行AQS的acquireQueued里才会在parkAndCheckInterrupt中用Thread.interrupted()去主动读取并清除中断状态再把它作为返回值等到合适时机acquire成功后再按原请求把interrupted传递出去。这也是为什么很多JUC工具对中断语义的处理显得比普通synchronized更精细它们能区分因为中断而醒来和因为unpark而醒来并在合适的时机分别处理。从使用者的角度如果你想写出可中断的停车等待应该这样写while (!condition !Thread.currentThread().isInterrupted()) { LockSupport.park(); } if (Thread.currentThread().isInterrupted()) { throw new InterruptedException(); }先说循环判断不死等再说事后检查中断状态确保响应中断的同时不丢失唤醒语义。4.4 伪唤醒问题必须用循环来防伪唤醒spurious wakeup是指线程在没有许可、没有超时、没有中断的情况下仍然从park中醒来的现象。它在wait/notify中也被广泛讨论过比如java.util.concurrent.locks.Condition的文档里明确说了虚假唤醒是允许的但park同样受这个问题影响。所以LockSupport官方的使用建议以及AQS内部的实际做法都是把park放进一个循环里醒来后重新检查等待条件不满足就继续park。我在自己的代码里也是遵循这个模式// 正确示范循环检查条件 while (!isReady) { LockSupport.park(); } // 错误示范单次park醒来后假定条件已满足 if (!isReady) { LockSupport.park(); } // 醒来后可能isReady仍然是false后者一旦遇到伪唤醒业务逻辑就会携带一个错误状态继续执行这种bug非常难复现鬼知道它什么时候会冒出来一次。所以请把park永远配合循环当作铁律。4.5 Blocker的巧用让线程dump一眼看出等待原因LockSupport.park(Object blocker)这个方法我强烈推荐在项目里使用。它和park()的区别仅仅在于会记录blocker信息但这在排查问题时有本质差别。线程dump时如果没有blocker你看到的是pool-1-thread-1 WAITING (parking) at java.base/jdk.internal.misc.Unsafe.park(Native Method)完全不知道它在等什么。而如果我们用LockSupport.park(this)或者传一个描述对象dump会变成pool-1-thread-1 WAITING (parking) at java.base/jdk.internal.misc.Unsafe.park(Native Method) at com.example.MyService.lambda$start$0(MyService.java:88) Lock owned by: (nothing) - parking to wait for 0x00000000abcdef (a com.example.MyService)至少你能立刻知道它挂在哪个对象上再结合代码行号定位业务逻辑排查效率完全不一样。我在团队内部还见过一种实践blocker直接传一个包含业务标识的字符串或者小型上下文对象用于快速区分同一行代码多个不同业务意图的等待实测效果非常好。5. 常见问题与排查技巧实录5.1 问题速查表现象可能原因排查方法线程永久WAITING (parking)无任何唤醒者有人在park前提前unpark过但permit被其他逻辑消费或者唤醒条件永远不会满足也可能是业务线漏调unpark检查所有调用unpark的路径确认没有提前消费在park循环里加超时dump对比线程栈park方法调用后立即返回与预期不符当前线程已经被设置过中断标志或先前已有unpark发放的permit未被消费检查Thread.interrupted()状态检查调用链中是否有skip机会的unpark线程明明调用了unpark但目标线程仍然卡住目标线程此时并非处于park状态unpark只把permit置1如果目标线程后续还有一次park它会消费这个许可立即返回——但如果该线程此前已经有一个permit未被消费新的unpark不会叠加确认目标线程只调用一次park之前没有预支过许可打印permit状态诊断可用jstack java.lang.instrument或eclipse mat分析使用Thread.sleep()期间调用unpark无效sleep不感知unpark只有park系列感知用户混淆了等待机制若想sleep也可以被提前叫醒换成LockSupport.parkNanos并配合中断标记检查或用Object.wait(timeout)FutureTask.get(timeout)超时后任务继续执行超时返回不代表任务真正取消取消是用cancel(true)来中断线程除非任务本身通过Thread.interrupted感知并退出否则任务还会跑完对执行中的任务捕获中断标志主动退出不要指望get超时自动干掉线程线程dump显示大量parking且CPU高存在循环parkunpark的忙等待赤热循环典型如park返回后立即再park之间没有真正的等待条件满足堆栈对应位置看循环逻辑统计park/unpark调用频率使用async-profiler查看热点修复条件检查逻辑中断后park在循环中醒不过来中断标志未清除每次park立即返回循环体空转但业务条件未满足循环内检查并清除中断标志明确区分因中断退出和因条件满足退出两种路径5.2 排查实录一次典型的permit泄漏事故上次遇到的那个线程池冻住问题我详细复盘过排查链路。线程dump显示所有worker都在getTask()里的workQueue.take()处WAITING(parking)表面看是队列空了线程在等任务但其实队列非空——因为有大量线程同时park而任务只有少量按理说应该有线程起来消费任务。后来我用jstack连续抓了3次dump发现线程的waiter数量和队列大小之间存在矛盾才注意到代码里的一个特殊写法任务执行器在处理某些高优任务时会手动做一次LockSupport.unpark(workerThread)来提前唤醒一个工人但这个worker可能当前并不在take()上等待而在处理前一个任务。这时候unpark发了一张permit给workerworker处理完当前任务后回到take()permit被立即消费take不阻塞直接拿到了队列里的一个任务——看起来没问题。问题是如果这个worker处理完当前任务后不是因为take()回去而是因为其他逻辑又执行了一次park()等待比如等待一个异步结果那么那一张早到的permit就被错误地消费在这里而不是消费在等待任务上。后续真正应该被唤醒等待任务的线程反而因为那个线程的同学许可证被截胡而少了一次唤醒机会。如果这种截胡频繁发生线程池里的线程就会慢慢都被挂在take()上等任务但队列非空却没人消费——因为所有线程都真正“没票”了。这个排查过程给了我两个很深的认识第一permit是没有背景知识的许可消费它的地方不一定是你预期的地方第二不要在JUC包的锁和队列机制之外擅自使用unpark去给线程池里的线程加速那基本是给自己埋雷。线程池的任务唤醒应该完全交给ThreadPoolExecutor的实现如果你发现它不够快应该调核心线程数、队列策略、拒绝策略而不是去手动unpark内部线程。5.3 快速定位park相关的线程状态最后分享几个实际工作中最有用的排查工具和命令组合。第一件事是抓线程dump用jstack pid或jcmd pid Thread.print关注WAITING (parking)和TIMED_WAITING (parking)状态。如果你用的是LockSupport.park(Object blocker)dump里会直接显示blocker关联的对象定位起来快很多。第二件事是用jhsdb jstack --pid pidJDK 9或jdb去查看线程内部私有状态变化。不过说实话permit这个值光靠jstack看不太出来它属于每个JavaThread内部的_parker状态。要精确判断线程现在有没有许可得用一些更底层的工具比如AsyncGetCallTrace配合自定义agent、或者arthas的thread命令观察线程栈配合watch监控LockSupport.unpark的调用。第三件是GC与unpark的一个冷知识如果线程在park等待中其对象引用还保留在AQS同步队列里那么即使业务线程已经放弃这个Node节点也可能一直存在。若队列设计不当比如任务丢弃但等待节点没被移除就会产生僵尸等待。这个问题在长期运行的服务里会表现为内存缓慢增长线程状态异常。排查方法周期性dump堆内存用MATMemory Analyzer看AQS Node对象的数量是否异常增长。这组工具的组合用法很多需要结合具体问题灵活选。但核心思路是先看线程状态再查唤醒路径最后判断permit流向。三个环节里任何一个判断失误后面的排查都会跑偏。写到这里我自己又把LockSupport的源码按上面走过的路径理了一遍。回头再看那个线程池冻住的夜晚很多东西都清晰了——如果早一点理解permit不是计数器早一点认识到unpark的发放不绑定等待点我当时应该可以少走很多弯路。这也是我为什么愿意把这篇写这么细。老话说纸上得来终觉浅LockSupport的语义你光看文档会觉得简单但真正被它坑过一次才会明白每一个细节背后都对应着实际场景里的一个血泪教训。希望这篇能帮你避开那些我踩过的坑。