NEW 状态仅存在于 new Thread() 后、start() 前，不可调度、不可中断；RUNNABLE 包含就绪、运行及部分I/O等待；WAITING 为无限期等待，TIMED_WAITING 含超时；BLOCKED 仅由 synchronized 锁竞争引发。
NEW 状态只在 new Thread() 之后、start() 之前存在
刚用 new Thread(runnable) 创建出来的线程对象，还没调用 start()，它就处于 NEW 状态。这个状态非常短暂，且不可被调度执行。一旦调用 start()，JVM 就会为其分配资源并尝试进入就绪队列——此时状态立刻变为 RUNNABLE（注意不是 “RUNNING”）。
-
NEW线程无法通过Thread.getState()被外部观察到正在运行，甚至不能被中断（interrupt()无效） - 重复调用
start()会抛出IllegalThreadStateException，这是唯一能明确感知该线程已离开NEW的信号 - 不要依赖
getState() == NEW来判断线程是否“还没开始”，因为从 new 到 start 的间隙极短，且无内存屏障保证可见性
RUNNABLE 并不等于“正在 CPU 上执行”
RUNNABLE 是 Java 线程状态中覆盖范围最广的一个：它包含操作系统层面的 “ready”（就绪）、“running”（运行中），也包括 I/O 阻塞但未进入 WAITING 或 BLOCKED 的情况（比如调用 FileInputStream.read() 时内核态等待磁盘数据，JVM 仍认为它是 RUNNABLE）。
- 线程池中的空闲工作线程，只要没被
park或wait，就始终是RUNNABLE（在ThreadPoolExecutor的runWorker循环里阻塞在getTask()，但该方法内部用的是LockSupport.parkNanos，所以实际状态是WAITING—— 这是个常见误解点） -
Thread.getState()返回RUNNABLE时，不能推断出 CPU 使用率高；同样，CPU 占用低也不代表状态不是RUNNABLE - Java 10+ 引入了
Thread.getState()的 JVM TI 支持增强，但底层仍是 OS 调度视角和 JVM 抽象层的混合映射，别把它当精确的运行时快照用
WAITING 和 TIMED_WAITING 的触发方式完全不同
WAITING 是无限期等待，必须靠其他线程显式唤醒；TIMED_WAITING 是带超时的等待，时间一到自动返回。两者都常见于同步工具类内部，但触发路径差异明显：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
-
WAITING：由Object.wait()（无参）、Thread.join()（无参）、LockSupport.park()触发 -
TIMED_WAITING：由Object.wait(timeout)、Thread.sleep(millis)、Thread.join(timeout)、LockSupport.parkNanos(ns)、Condition.awaitNanos()触发 - 特别注意：
Thread.sleep(0)是合法的，它会让出当前时间片，状态为TIMED_WAITING，但不会真正休眠 —— 这在自旋退避逻辑里有时被误用 - JVM 线程 dump 中看到大量
TIMED_WAITING (parking)，大概率是java.util.concurrent类（如LinkedBlockingQueue）在用LockSupport.parkNanos实现超时等待，属正常行为
BLOCKED 只发生在进入 synchronized 同步块/方法时竞争 monitor 锁
BLOCKED 是唯一与 synchronized 关键字强绑定的状态。它表示线程已准备好运行，但正等待获取某个对象的 monitor 锁（即进入 synchronized(obj) { ... } 或调用 synchronized 方法时，发现锁被别的线程持有）。
立即学习“Java免费学习笔记（深入）”；
-
ReentrantLock.lock()不会导致BLOCKED，而是让线程进入WAITING或TIMED_WAITING（取决于是否用tryLock(long, TimeUnit)） - 一个线程可以在持有某对象锁的同时，因等待另一个对象锁而变成
BLOCKED，这就是死锁链的起点 - 线程 dump 中若出现多个线程相互
BLOCKED on，基本可判定发生锁竞争或死锁；但要注意，BLOCKED时间极短（纳秒级）时，dump 可能抓不到，需结合jstack -l和Unsafe.park堆栈综合判断
RUNNABLE ↔ TIMED_WAITING 切换频繁，BLOCKED 可能一闪而过，而 WAITING 一旦卡住往往意味着业务逻辑或资源泄漏。看状态不如看堆栈，查问题先看 jstack 输出里最顶上的 native 方法和锁地址。 
