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()触发的状态差异
三者都让线程暂停，但状态不同、唤醒机制不同、是否释放锁也不同：
立即学习“Java免费学习笔记（深入）”；
-
wait()→ 进入WAITING（或TIMED_WAITING），必须配合synchronized使用，会释放当前持有的锁 -
join()→ 本质是循环调用wait()，所以也是WAITING/TIMED_WAITING，不释放调用者的锁 -
sleep()→ 进入TIMED_WAITING，不释放任何锁，时间一到自动恢复
错误写法示例：someObject.wait()没加synchronized块，直接抛IllegalMonitorStateException；或者在ReentrantLock保护的代码里误用wait()（该用lock.newCondition().await()）。
状态转换图里最易忽略的细节：从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里的无锁结构。
