1. 从一次线上事故说起线程状态不是八股文凌晨两点半手机震动把我从床上拽起来。群里已经开始刷屏订单服务超时率飙升接口P99从80ms涨到3s。登录这台机器看看线程。我在命令行敲下jstack 12345 /tmp/jstack.log下载下来一翻立刻看到一大片java.lang.Thread.State: BLOCKED (on object monitor)后面的堆栈齐刷刷地指向同一个RedisDistributedLock.lock()方法。那一刻你就能明白理解线程状态不是为了应付面试官那句说说线程有哪些状态而是为了在线上出问题时能一眼从jstack日志里看出系统现在到底卡在哪、线程们正在干什么、为什么要等。这份能力就是靠把线程状态的每个细节真正吃透撑起来的。这篇博客我把整个线程状态话题重新拆了一遍不背课本而是从原理、代码、实战排查三个维度重新过一遍。无论你是刚接触并发的初中级开发者还是已经在生产环境踩过坑的工程师都应该能从里面找到一些有价值的东西。2. 六种状态逐一定义先搞清楚名字背后到底在说什么2.1 线程状态不是线程自己的属性Java里查看线程状态最直接的方式是Thread.getState()返回的是一个Thread.State枚举。很多教程会把这六种状态当成一张表让人背但我想先说个更底层的概念线程状态本质上是在回答一个问题——这个线程此刻有没有资格使用CPU如果没资格是被谁拦下来的这个视角非常重要。因为无论是synchronized锁竞争、Object.wait()、Thread.sleep()还是LockSupport.park()最终落到线程层面都是让出CPU的某种实现方式只是让出的姿势和唤醒条件各有不同。把这层想清楚六种状态就不再是六个孤立名词了。2.2 六种状态速览状态英文名含义进入方式退出方式新建NEW线程对象已创建但还没调用start()new Thread()调用start()可运行RUNNABLE线程正在执行或准备好执行等待CPU调度start()后、yield()、sleep()结束状态迁移到其他阻塞态或正常结束阻塞BLOCKED等待进入synchronized代码块/方法拿不到监视器锁竞争synchronized锁失败拿到锁自动回到RUNNABLE等待WAITING等待被其他线程显式唤醒Object.wait()、Thread.join()、LockSupport.park()被notify()/notifyAll()/unpark()等唤醒定时等待TIMED_WAITING在WAITING基础上加了超时时间Thread.sleep(ms)、Object.wait(timeout)、Thread.join(ms)、LockSupport.parkNanos()超时或被唤醒终止TERMINATED线程执行完或异常退出run()方法返回或抛出未捕获异常无注意这张表只是速览。真正的坑往往藏在那些容易被忽略的细节里。2.3 重点RUNNABLE其实是个大杂烩这是最容易被人忽视的一点。Java把操作系统里的就绪态和运行态合并成了RUNNABLE。也就是说只要这个线程没有在等待锁、没有在sleep、没有在wait哪怕它已经被操作系统剥夺了CPU、排在调度队列里排队Java里看到的依然是RUNNABLE。为什么这么设计因为JVM层面的状态不关心是不是正占用物理CPU只关心线程是不是有资格运行。这一点符合Java的跨平台设计取向不同的操作系统Windows、Linux、macOS对线程调度的实现方式不同强行区分运行中和就绪反而没法统一。代价就是你看到RUNNABLE时不能断言这个线程正在跑——它可能正在等待CPU时间片甚至可能出现一种看起来在RUNNABLE但持续不了进展的诡异情况比如while(true){}死循环状态永远是RUNNABLE但系统已经卡死了。2.4 NEW和TERMINATED容易被忽略的细节NEW状态的生命周期很短一般来说线程对象刚new出来、还没调start()时才处于这个状态。很多人在这个状态上出的问题其实是设计问题在start()之前就调用线程的一些方法比如join()会直接抛出IllegalThreadStateException。因为join()的语义是等这个线程跑完可它压根还没启动逻辑上说不通。TERMINATED看起来更无趣但其实它有一个实际用途判断线程是否还活着。Thread.isAlive()只有在NEW和TERMINATED状态下返回false其他四种状态都返回true。我在排查线程池问题时有时候需要确认任务线程是彻底退出了、还是卡在等待里就会结合isAlive()和getState()一起看否则很容易误判线程要死了。3. 状态转换的真正逻辑谁把线程推进了下一个状态3.1 一张转换关系网要说清楚状态绕不开转换。我把主要转换关系整理成一张表格转换路径触发条件线程做什么NEW → RUNNABLE调用Thread.start()创建真正的操作系统线程等待被调度RUNNABLE → BLOCKED尝试进入synchronized块/方法但锁被占用进入该锁的等待集合不消耗CPUBLOCKED → RUNNABLE持锁线程释放锁JVM唤醒该线程重新竞争锁拿到后继续执行RUNNABLE → WAITING调用Object.wait()无线程参数、LockSupport.park()、Thread.join()主动让出CPU等待被通知/唤醒WAITING → RUNNABLE被notify()/notifyAll()唤醒或被unpark()或join的线程结束回到可运行状态RUNNABLE → TIMED_WAITING调用Thread.sleep(ms)、Object.wait(timeout)、Thread.join(ms)、LockSupport.parkNanos()让出CPU并带超时TIMED_WAITING → RUNNABLE计时到期、被唤醒、join线程结束重新可运行RUNNABLE → TERMINATEDrun()正常返回或抛异常线程资源开始回收3.2 核心误区一sleep()并不会进入BLOCKED我见过很多人把睡眠和阻塞混为一谈以为Thread.sleep()会让线程进入BLOCKED。这完全错了sleep()进入的是TIMED_WAITING。两者的本质区别在于BLOCKED意味着线程在等待一个自己控制不了的资源锁释放权在别人手上它只能被动等。TIMED_WAITING意味着线程主动睡一觉时间一到它自然醒不依赖任何其他线程的动作。这区别不是文字游戏。比如你要排查一个接口变慢的问题看到线程状态是TIMED_WAITING (sleeping)基本可以判断是业务逻辑里有固定等待看到BLOCKED (on object monitor)则可以断定有锁竞争。这两种问题的修复思路完全不同。3.3 核心误区二wait()与sleep()的区别不只是要不要锁Object.wait()和Thread.sleep()的另一个微妙差异在于wait()必须在持有监视器锁的前提下调用并且调用后会释放这把锁sleep()不要求持有锁也绝不会释放锁。这意味着什么我举一个典型的死锁场景 线程A持有锁L然后调用L.wait()此时锁L被释放线程B才能进入并调用L.notify()唤醒A。如果误用了sleep()线程A会一直死握着锁L睡觉线程B永远进不来。这种Bug在真实项目中特别容易出现排查起来也特别耗时间——因为从状态上看一个在TIMED_WAITING一个在BLOCKED情境非常典型但你要是没理解透wait释放锁、sleep不释放锁根本不会往这个方向想。3.4 状态转换的代码实证与其背状态图不如自己写代码验证一遍。下面这个Demo可以把每个状态都打印出来public class ThreadStateDemo { private static final Object LOCK new Object(); public static void main(String[] args) throws Exception { Thread waitingThread new Thread(() - { synchronized (LOCK) { try { LOCK.wait(); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } } }, waiting-thread); Thread blockedThread new Thread(() - { synchronized (LOCK) { // do nothing } }, blocked-thread); Thread sleepingThread new Thread(() - { try { Thread.sleep(5000); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } }, sleeping-thread); Thread runningThread new Thread(() - { while (true) { // 死循环维持RUNNABLE if (Thread.currentThread().isInterrupted()) { break; } } }, running-thread); waitingThread.start(); Thread.sleep(200); // 确保wait先执行 synchronized (LOCK) { blockedThread.start(); Thread.sleep(200); System.out.println(waiting-thread state: waitingThread.getState()); // WAITING System.out.println(blocked-thread state: blockedThread.getState()); // BLOCKED } sleepingThread.start(); runningThread.start(); Thread.sleep(200); System.out.println(sleeping-thread state: sleepingThread.getState()); // TIMED_WAITING System.out.println(running-thread state: runningThread.getState()); // RUNNABLE waitingThread.interrupt(); runningThread.interrupt(); System.exit(0); } }这段代码有个值得细品的点为了让blockedThread稳定地在BLOCKED状态被观测到我先让waitingThread拿到LOCK并调用wait()释放锁然后主线程再抢到LOCK再启动blockedThread。此时blockedThread尝试进入synchronized块会阻塞在主线程持有的LOCK上状态自然就是BLOCKED。我自己一开始写Demo时偷懒没让主线程抢锁结果blockedThread的状态时而是RUNNABLE时而是BLOCKED完全取决于调度时机。这个教训说明理解状态转换必须把谁持有锁谁在等待哪个资源这些前置条件一并考虑进去。4. 实战用jstack诊断一次线程卡顿的完整链路4.1 先构造一个故障现场理论讲完直接上实战。假设线上出现了一个偶发超时变多的问题我们需要复现并抓取现场。为了演示我写个模拟程序public class FakeProductionIssue { private static final Object DB_LOCK new Object(); public static void main(String[] args) throws Exception { // 线程A模拟持有数据库连接锁后做超长耗时操作 Thread threadA new Thread(() - { synchronized (DB_LOCK) { try { Thread.sleep(10_000); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } } }, db-conn-holder); // 线程B模拟等待数据库连接锁 Thread threadB new Thread(() - { synchronized (DB_LOCK) { System.out.println(got the lock); } }, db-conn-waiter); // 线程C模拟业务线程在等待一个永远等不到的notify Thread threadC new Thread(() - { synchronized (DB_LOCK) { try { DB_LOCK.wait(); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } } }, business-waiter); threadA.start(); Thread.sleep(200); threadB.start(); threadC.start(); // 将线程状态打印出来模拟jstack效果 Thread.sleep(500); System.out.println(threadA: threadA.getState()); System.out.println(threadB: threadB.getState()); System.out.println(threadC: threadC.getState()); System.out.println(threadC stack:); for (StackTraceElement element : threadC.getStackTrace()) { System.out.println( at element); } System.exit(0); } }输出类似threadA: TIMED_WAITING (sleeping) threadB: BLOCKED (on object monitor) threadC: WAITING (on object monitor) // 或 WAITING (parking) threadC stack: at java.base/java.lang.Object.wait(Native Method) at FakeProductionIssue.lambda$main$2(FakeProductionIssue.java:31) at java.base/java.lang.Thread.run(Thread.java:834)4.2 jstack输出该怎么读生产环境里你大概率是用jstack或jcmd Thread.print拿到线程快照。一个典型的线程堆栈长这样db-conn-waiter #24 prio5 os_prio0 cpu0.32ms elapsed4120.25s tid0x00007f9c9826d000 nid0x1f4b waiting for monitor entry [0x00007f9c89fff000] java.lang.Thread.State: BLOCKED (on object monitor) at FakeProductionIssue.lambda$main$1(FakeProductionIssue.java:22) - waiting to lock 0x0000000712345678 (a java.lang.Object) at FakeProductionIssue.lambda$main$1(FakeProductionIssue.java:21) at java.base/java.lang.Thread.run(Thread.java:834)这里有关键信息Thread.State: BLOCKED (on object monitor)线程因synchronized锁竞争被阻塞。waiting to lock 0x...明确指出它在等哪把锁。elapsed线程已经存活了多久如果这个值很大说明问题已经持续很久了。cpu0.32ms如果cpu时间极低但elapsed很大说明线程大部分时间都在等待而不是在计算。读jstack的核心心法就是先看状态再看堆栈最后结合锁地址定位谁持锁不撒手。4.3 从状态分布推断问题类型jstack抓下来以后大量线程堆在一起看经验就派上用场了状态分布特征大概率问题排查方向大量线程BLOCKED且都waiting to lock同一个地址锁竞争过热/持锁线程卡住找持有该锁的线程分析它为何不释放大量线程WAITING (parking)线程池饱和任务都在等队列或信号量看线程池配置、队列长度、拒绝策略大量线程TIMED_WAITING (sleeping)业务里有固定sleep/等待或者连接池等待检查是否引入了不必要的延迟大量线程RUNNABLE但cpu时间很低线程在空转或等待IO比如网络阻塞用top -H看线程CPU结合堆栈分析两个以上的线程互相持有对方需要的锁死锁看Found one Java-level deadlock提示顺带提一个实用工具jstack结尾如果有Found one Java-level deadlock那是HotSpot帮你做了死锁检测。但生产环境很多类似死锁的情况并不是标准的死锁而是线程被某个外部资源卡住比如等待数据库连接、第三方接口没设超时这时jstack不会提示deadlock需要靠状态分布自己判断。我在一次排查中就遇到一堆线程WAITING (parking)在FutureTask.get()上表面看像死锁实际是上游HTTP接口读超时时间设置得太长。5. 生产环境最容易翻车的线程状态陷阱5.1 线程池中的隐形状态在Java里跑线程绝大多数时候是交给ThreadPoolExecutor。这里有一个很多人忽略的点池里的空闲工作线程状态通常不是不做任何事而是WAITING (parking)。因为它们阻塞在workQueue.take()上等待新任务。这个现象带来一个实际问题你jstack看到大量WAITING (parking)线程时第一反应不应该是系统卡死而要看它们是否都阻塞在ThreadPoolExecutor.getTask()上。如果是说明线程池只是空闲很正常。之前有位朋友看到线上jstack有300多个parking线程吓得以为出问题了结果只是核心线程数配多了。线程池的这个状态也解释了为什么核心线程回收在默认情况下不会发生——它们一直在take()上阻塞着不会退出。5.2 死锁从状态一眼识破标准的死锁场景jstack的形态非常固定。比如下面这段class DeadLockDemo { static final Object A new Object(); static final Object B new Object(); public static void main(String[] args) { Thread t1 new Thread(() - { synchronized (A) { System.out.println(t1: hold A); try { Thread.sleep(100); } catch (InterruptedException e) {} synchronized (B) { System.out.println(t1: hold B); } } }); Thread t2 new Thread(() - { synchronized (B) { System.out.println(t2: hold B); try { Thread.sleep(100); } catch (InterruptedException e) {} synchronized (A) { System.out.println(t2: hold A); } } }); t1.start(); t2.start(); } }运行后两个线程一个在BLOCKED等着对方的锁一个也BLOCKED等着对方的锁互相不撒手。jstack的输出里会直接有Found one Java-level deadlock提示并且会列出死锁线程的锁持有关系。但我想强调一个更隐蔽的现象死锁不一定非要synchronized嵌套。CountDownLatch.await()和countDown()顺序颠倒、Thread.join()结合锁、乃至线程池中父子任务互相submit().get()都可能让线程进入WAITING然后大家互相等状态上是WAITING而不是BLOCKEDjstack也不会提示deadlock但你一眼看过去会看到多条线程长期处于WAITING且堆栈指向的等待对象互相有关联。这种用jstack多抓几次对比才能确认是业务上互相等待而不是真的锁死。5.3 虚假唤醒wait()为什么必须放在while里这是个经典知识点但因为它和线程状态的转换直接相关必须再强调一次。Object.wait()被唤醒的方式有三种notify()、notifyAll()、虚假唤醒。后者是指线程在没有收到任何通知的情况下被唤醒这是底层实现允许的行为。如果用if判断条件再wait一旦发生虚假唤醒线程就会在条件不满足的情况下继续执行可能造成数据错误。正确的写法必须这样synchronized (lock) { while (!condition) { lock.wait(); } // 条件满足后的业务逻辑 }从状态转换的视角来理解线程从WAITING被唤醒后最终会回到RUNNABLE但这不意味着条件已经就绪只是线程有资格重新检查而已。所以while循环不是代码风格问题而是并发正确性的硬要求。5.4 用Interrupt唤醒等待中的线程还有一个非常常见的操作就是通过Thread.interrupt()去打断一个处在WAITING或TIMED_WAITING状态下的线程。我记得很多人在处理这个问题时默认以为一调用interrupt()线程就会立刻醒来抛异常、结束运行。其实完全不是这样。如果线程正在WAITINGinterrupt()会使它从wait中醒来在wait()调用处抛出InterruptedException。 如果线程正在TIMED_WAITING (sleeping)同理从sleep中醒来抛InterruptedException。 如果线程正在RUNNABLEinterrupt()只会设置中断标志位线程本身完全不会停下来。也就是说interrupt()对阻塞中的线程是有效的打断但对正在计算的线程只是提个醒。这也是我在编程时高频踩过的坑之一——想用interrupt停掉一个死循环线程结果标志位是设了可那个循环压根没检查isInterrupted()停了半天停不下来。线程状态没变依然RUNNABLECPU照转。6. 我把这些状态映射到真实场景之后的理解6.1 所有并发问题本质都是状态转换条件问题写并发程序绕不开协调多个线程的执行节奏。当你把线程状态理解透彻之后很多并发设计其实是在回答同一个问题我要让线程停留在哪个状态用什么方式让它离开这个状态比如用CountDownLatch.await()让多个工作线程在WAITING状态等一个发令枪等的是信号。用BlockingQueue.take()让消费者线程无限期阻塞在WAITING直到生产者放入数据。用synchronized让线程进入BLOCKED等的是锁资源的释放。用Semaphore.acquire()让线程停在WAITING等的是许可证。这四种等待从jstack上看全都是WAITING或BLOCKED但它们的语义和排查方式各不相同。理解了这一层你在设计时就更容易选择合适的并发原语排查时也更能准确推断这个WAITING是不是符合预期。6.2 线程Dump的多次采样比单次抓取更有说服力我见过许多人在线上排查时只抓一次jstack就试图下结论结果经常误判。因为在某个瞬间某条线程是BLOCKED可能是偶发现象不代表系统有问题。更可靠的做法是连续抓几次线程快照间隔10~30秒然后对比线程状态的变化趋势。如果线程永远停留在某个状态、堆栈完全不变大概率是死锁或长期等待。如果线程状态在RUNNABLE、BLOCKED之间快速切换说明存在锁竞争但要结合QPS和耗时才能判断是否过热。如果每次抓到的阻塞点都不一样可能是偶发资源等待比如数据库连接池瞬间耗尽。有一次我排查一个每天下午3点必出现超时的问题单次抓jstack看到的是大量线程BLOCKED在同一个锁上看起来像锁竞争但多次采样后发现持锁线程每次都在处理同一个大型报表导出任务。顺着堆栈找下去发现那项任务在凌晨的定时批处理里对账表做了全表扫描锁持有的时间瞬间暴涨把其他业务线程全部堵住了。如果只看一次jstack我可能就陷入优化锁粒度的方向了实际问题是慢查询。6.3 不要把状态当成锁和并发的全部但它是最快的诊断入口线程状态是JVM曝露给我们的一扇窗口但它不是全貌。我现在的习惯是出问题时第一波动作永远是jstack抓状态快速判断线程们卡在哪类操作上然后顺着堆栈往下挖。状态告诉你线程在等待但等待的原因、资源是否健康、锁的持有者是谁还需要结合数据库慢查询日志、网络监控、GC日志去综合判断。最后分享一个小习惯排查线程问题前先在代码里给业务线程起有含义的名字比如order-service-pool-1、mq-consumer-2。线程池里如果都用默认的pool-1-thread-1jstack拿到手你会哭的几秒钟内根本定位不到业务入口。这个名字随手一写就是一行代码但它在凌晨两点半救过我好几次命了。