以下是一篇尽量通俗、结构清晰的文章，帮助你真正搞懂：
Java 线程的 6 种状态 + 状态转换图
以及 Java 内存模型（JMM）最核心的几件事
一、线程的 6 种状态（Java Thread.State 枚举）
Java 线程在 JVM 层面一共有这 6 种状态：
| 状态（英文） | 中文名称 | 是否占用 CPU | 是否持有锁 | 通俗解释 |
|---|---|---|---|---|
| NEW | 新建 | 否 | 否 | 刚 new Thread() 出来，还没调用 start()，相当于一张还没发出去的简历 |
| RUNNABLE | 可运行 | 是（有可能） | 可能 | 线程正在 JVM 里“活着”，要么正在 CPU 上跑，要么在就绪队列排队等 CPU |
| BLOCKED | 阻塞（锁等待） | 否 | 否 | 想进 synchronized 代码块，但锁被别人拿着，像在银行排队等叫号 |
| WAITING | 无限等待 | 否 | 否 | 调用了 wait()、join()、LockSupport.park() 后进入，像睡着了等别人叫醒 |
| TIMED_WAITING | 限时等待 | 否 | 否 | 带时间的 wait(long)、sleep(long)、join(long)、parkNanos/parkUntil |
| TERMINATED | 终止 | 否 | 否 | run() 方法执行完毕（正常结束或异常抛出未捕获），线程彻底死亡 |
最容易混淆的三个状态对比
| 状态对比 | BLOCKED | WAITING | TIMED_WAITING |
|---|---|---|---|
| 等待什么 | 等待 monitor 锁 | 等待别人主动唤醒 | 等待别人唤醒 或 超时自动醒 |
| 典型方法 | synchronized 块入口 | wait() / join() / park() | sleep() / wait(时间) / join(时间) |
| 持有锁情况 | 不持有（没抢到） | 不持有（已经释放） | 不持有（已经释放） |
| 被唤醒方式 | 锁释放后自动竞争 | notify / notifyAll / unpark | notify / 超时 / unpark |
二、线程状态转换图（最经典的 7 条转换路径）
new Thread()
↓
NEW
↓ start()
RUNNABLE ←──────────────┐
/ ↑ \ │
/ │ \ │ CPU 时间片用完 / yield()
运行中 ←───── 就绪 等待锁 │
\ │ / │
\ ↓ / │
BLOCKED ←──── WAITING ←── TIMED_WAITING
↑ ↑ ↑
│ │ │
notify/notifyAll wait() sleep(时间)/wait(时间)
│ │ │
└────────┴─────────────┘
↓
TERMINATED最常考的几条路径解释（通俗版）
- NEW → RUNNABLE
调用start()，线程进入就绪队列排队等 CPU（不是立刻执行） - RUNNABLE → TERMINATED
run() 方法正常结束 或 抛出未捕获异常 - RUNNABLE → BLOCKED
线程想进synchronized同步块，但发现锁被别人拿着 → 进入阻塞队列 - RUNNABLE → WAITING
obj.wait()（必须先持有锁）thread.join()（等待目标线程结束）LockSupport.park()
- RUNNABLE → TIMED_WAITING
Thread.sleep(毫秒)（最常见，不释放锁）obj.wait(毫秒)thread.join(毫秒)LockSupport.parkNanos()/parkUntil()
- WAITING / TIMED_WAITING → RUNNABLE
- 被
notify/notifyAll唤醒（但不一定马上拿到锁） - 被
unpark唤醒 - 等待时间到（自动唤醒）
- BLOCKED → RUNNABLE
锁被释放后，JVM 从阻塞队列里挑一个线程去竞争锁（不保证公平）
三、Java 内存模型（JMM）最核心的几件事（通俗版）
JMM 主要解决两个问题：
- 可见性（一个线程改了变量，另一个线程看不看得见）
- 有序性（代码写的顺序和实际执行顺序是否一致）
最核心的三个概念 + 一张图
1. 主内存 vs 工作内存
每个线程都有自己的工作内存（本地内存），里面放的是主内存变量的副本。
主内存（共享）
age = 18 money = 1000
↑ ↑
┌───────────────┬───────────────┐
│ 线程A工作内存 │ 线程B工作内存 │
│ age副本=18 │ age副本=18 │
│ money副本=1000│ money副本=1000│
└───────────────┴───────────────┘2. 八大原子操作（决定变量什么时候从主内存同步到工作内存）
| 操作 | 含义 | 谁发起 |
|---|---|---|
| lock | 把主内存变量标记为线程独占 | 线程 |
| unlock | 把锁释放 | 线程 |
| read | 从主内存读取变量值 | 线程 |
| load | 把 read 的值放入工作内存副本 | 线程 |
| use | 线程使用工作内存中的变量副本 | 线程 |
| assign | 线程把值赋给工作内存中的变量副本 | 线程 |
| store | 把工作内存副本的值传回主内存 | 线程 |
| write | 把 store 的值写入主内存的变量 | 线程 |
3. happens-before 规则（最重要！决定“能不能看到修改”）
只要满足下面任意一条，前面的写操作对后面的读操作可见：
- 程序顺序规则：单线程内，按代码顺序执行
- 监视器锁规则：解锁 → 同一个锁的加锁
- volatile 变量规则：对 volatile 变量的写 → 后面的读
- 线程启动规则：Thread.start() → 线程内的任意操作
- 线程终止规则：线程内任意操作 → Thread.isAlive()=false / join()返回
- 线程中断规则：interrupt() → 检测到中断（抛异常或 isInterrupted=true）
- 对象终结规则：构造方法结束 → finalize() 开始
- 传递性：A 先于 B，B 先于 C → A 先于 C
最常考的几条通俗解释
- 我对 volatile x 写了 100 → 后面任何线程读 x 都必须是 100
- 我 synchronized 块里改了 age → 出块后别的线程进同一个锁的 synchronized 块一定能看到
- 我调用 t.start() → t 线程里面的代码一定能看到 start() 之前的变量值
总结一句话口诀
线程状态：NEW → start → RUNNABLE ↔ BLOCKED / WAITING / TIMED_WAITING → TERMINATED
内存模型：每个线程有自己的工作内存 + 主内存，要想让别人看到修改，必须走 happens-before 桥梁（volatile、synchronized、start/join 等）
如果你现在能画出线程状态转换图 + 说出 volatile 为什么能保证可见性 + 举例 happens-before 的 3 个最常用规则，
那么这篇内容你就已经掌握 80% 了。
需要我再深入讲解哪一块？
比如：
- volatile 底层实现（内存屏障 + Lock 前缀）
- synchronized 升级过程（偏向锁→轻量级锁→重量级锁）
- JMM 对 double/long 的非原子性处理
- ThreadLocal 与内存泄漏
告诉我，我继续给你展开～
