1. Java线程状态全景图第一次接触Java线程状态时我盯着那六种状态名称发呆了半小时。直到在电商系统压测时遇到线程阻塞问题才真正理解这些状态背后的故事。想象线程就像快递小哥NEW状态是他刚入职还没接单RUNNABLE是骑着电动车在路上跑BLOCKED是等红绿灯WAITING是在小区门口等客户取件。Java官方定义的六种线程状态都封装在Thread.State枚举中。用个实际案例来说明假设我们有个外卖订单处理系统当用户下单后会创建新线程处理订单Thread deliveryThread new Thread(() - { synchronized (lock) { // 处理订单逻辑 } }); System.out.println(deliveryThread.getState()); // 输出NEW**新建状态NEW**就像刚打印出来的空白快递单此时JVM已分配内存但还没启动线程。这时候调用isAlive()返回false就像未激活的SIM卡。2. 状态转换核心机制2.1 从NEW到RUNNABLE的跃迁调用start()方法时有个坑多次调用会抛IllegalThreadStateException。这就像给快递小哥派单后不能再重复派单。来看个典型错误示例Thread t new Thread(()-System.out.println(配送中)); t.start(); t.start(); // 抛出异常RUNNABLE状态包含两个子状态Ready线程在就绪队列等待CPU时间片就像快递小哥在站点待命Running正在执行run()方法对应配送途中状态通过jstack工具可以看到这两种子状态都显示为RUNNABLE。2.2 阻塞状态的三种面孔BLOCKED状态最容易引发性能问题。去年双十一我们的支付系统就因此卡顿。当多个线程竞争synchronized锁时没抢到锁的线程就会进入这种状态// 线程A synchronized(lock) { Thread.sleep(1000); // 持有锁1秒 } // 线程B synchronized(lock) { // 这里会阻塞 System.out.println(获取到锁); }WAITING状态常见于生产者-消费者场景。比如快递小哥到达后打电话等客户lock.wait(); // 释放锁进入等待TIMED_WAITING则是设置了超时的等待实测发现sleep()和wait(timeout)在这个状态下表现不同方法是否释放锁唤醒方式Object.wait()是notify/notifyAllThread.sleep()否超时自动唤醒LockSupport.park()否unpark或中断3. 实战中的状态管理3.1 线程池中的状态流转在订单处理线程池中线程状态变化特别频繁。通过ThreadPoolExecutor的源码可以看到worker线程的状态流转新建Worker时状态为NEW执行任务时变为RUNNABLE从队列取任务时可能进入WAITING线程销毁时变为TERMINATED这里有个性能优化点合理设置keepAliveTime可以避免线程频繁创建销毁。我们通过压测发现设置为任务平均耗时的3倍最合适。3.2 死锁检测实战去年排查过一个经典死锁案例订单服务锁定了订单ID物流服务锁定了物流单ID双方互相等待对方的锁。用jstack检测时看到Thread-1 #12 prio5 os_prio0 tid0x00007f48740f7000 nid0x1e03 waiting for monitor entry [0x00007f486b7fe000] java.lang.Thread.State: BLOCKED (on object monitor) Thread-2 #13 prio5 os_prio0 tid0x00007f48740f8800 nid0x1e04 waiting for monitor entry [0x00007f486b6fd000] java.lang.Thread.State: BLOCKED (on object monitor)解决方案是统一锁获取顺序按照订单ID和物流ID的字典序加锁。4. 状态监控与调试技巧4.1 诊断工具三剑客jstack最常用的线程快照工具jstack -l pid thread_dump.log输出示例main #1 prio5 os_prio0 tid0x00007f79b4009000 nid0x1a03 waiting on condition [0x00007f79b8a4a000] java.lang.Thread.State: TIMED_WAITING (sleeping)VisualVM图形化查看线程状态变化Arthas阿里开源的实时诊断工具4.2 生产环境问题定位遇到过最棘手的问题是线程卡在WAITING状态。后来发现是忘记调用notify()。现在我们都用Condition替代wait/notifyLock lock new ReentrantLock(); Condition condition lock.newCondition(); // 等待方 lock.lock(); try { condition.await(5, TimeUnit.SECONDS); } finally { lock.unlock(); } // 通知方 lock.lock(); try { condition.signal(); } finally { lock.unlock(); }5. 最佳实践与避坑指南状态转换陷阱不要依赖线程优先级不同OS实现不同yield()方法不保证让出CPU只是给调度器提示资源清理Thread t new NetworkThread(); t.setUncaughtExceptionHandler((thread, ex) - { // 关闭网络连接 System.out.println(thread.getState()); // 仍为RUNNABLE });线程中断的正确姿势while (!Thread.currentThread().isInterrupted()) { try { Thread.sleep(1000); } catch (InterruptedException e) { // 重置中断状态 Thread.currentThread().interrupt(); break; } }在微服务架构下我习惯用状态机模式来管理复杂线程流转。比如订单状态和线程状态的映射enum OrderState { NEW, PROCESSING, WAITING_PAYMENT, COMPLETED; public Thread.State toThreadState() { switch(this) { case NEW: return Thread.State.NEW; case PROCESSING: return Thread.State.RUNNABLE; case WAITING_PAYMENT: return Thread.State.TIMED_WAITING; default: return Thread.State.TERMINATED; } } }记得有次系统出现大量BLOCKED线程最终发现是数据库连接池配置过小。调整后吞吐量提升了3倍。线程状态就像系统健康的晴雨表需要持续监控和分析。