Java线程的6种状态不是并列关系，而是有明确进入/退出条件

Java线程状态（Thread.State）共6种：NEW、RUNNABLE、BLOCKED、WAITING、TIMED_WAITING、TERMINATED。它们不是靠“设置”切换的，而是JVM根据线程实际执行行为自动变更——你调用wait()，线程就进WAITING；锁被占着又想进同步块，就卡在BLOCKED；线程跑完run()方法，自然变成TERMINATED。

常见误解是以为能用代码“强制设为RUNNABLE”，其实没有thread.setState(...)这种API。状态只是观测结果，不是控制接口。

为什么Thread.getState()返回RUNNABLE却没在跑CPU？

RUNNABLE不等于“正在执行”，它包含“就绪”和“运行中”两个操作系统层面的状态。JVM规范里明确说：只要线程没被阻塞、没等待、没终止，就归为RUNNABLE。

• 线程刚调用start()后，可能还在OS调度队列里排队——状态已是RUNNABLE，但还没拿到CPU
• 线程正在IO（比如System.in.read()）、或调用sleep(1000)，实际处于系统级休眠，但JVM仍报告TIMED_WAITING
• Thread.getState()是快照，多线程下取到的状态可能瞬间就变了，不能用来做逻辑分支判断

wait()、join()、sleep()触发的状态差异

三者都让线程暂停，但状态不同、唤醒机制不同、是否释放锁也不同：

• wait() → 进入WAITING（或TIMED_WAITING），必须配合synchronized使用，会释放当前持有的锁
• join() → 本质是循环调用wait()，所以也是WAITING/TIMED_WAITING，不释放调用者的锁
• sleep() → 进入TIMED_WAITING，不释放任何锁，时间一到自动恢复

错误写法示例：someObject.wait()没加synchronized块，直接抛IllegalMonitorStateException；或者在ReentrantLock保护的代码里误用wait()（该用lock.newCondition().await()）。

Java调试

通过 JDWP 实现 Java 远程调试：连接远程 JVM、设置断点、单步执行代码、查看变量值、获取调用栈。适用于需要调试远程 Java 应用、排查运行时状态、追踪代码执行流程的场景。 术语注解 JDWP：Java Debug Wire Protocol，Java 调试有线协议（Java 远程调试底层通信协议） remote JVM：远程 Java 虚拟机 step through code：代码单步调试（步入 / 步过 / 步出调试） inspect variables：变量查看 / 变量检视 stac

下载

状态转换图里最易忽略的细节：从BLOCKED到RUNNABLE不保证立即执行

线程在等锁时是BLOCKED，一旦锁释放，它会进入“就绪队列”，但能否立刻运行取决于OS调度器——可能被更高优先级线程抢占，也可能因时间片未分配而继续等待。

这意味着：

• 监控发现大量线程卡在BLOCKED，说明锁竞争严重，不是线程“卡死”，而是资源争抢激烈
• 用jstack看到一堆java.lang.Thread.State: BLOCKED (on object monitor)，重点查那个被争抢的Locked ownable synchronizers对象
• Thread.isAlive()返回true只代表没到TERMINATED，无法区分它此刻是RUNNABLE还是BLOCKED

线程状态本身不提供性能线索，它只是表象。真正要调的是锁粒度、同步范围、是否该用java.util.concurrent里的无锁结构。

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南