【高并发编程必知】：为什么你的线程从RUNNABLE变成BLOCKED？

第一章：线程状态转换的核心机制

在多线程编程中，理解线程在其生命周期内的状态转换是掌握并发控制的关键。操作系统调度器依据资源可用性与程序逻辑，动态管理线程在不同状态之间的迁移。

线程的基本状态

一个线程通常经历以下几种核心状态：

• 新建（New）：线程对象已创建，尚未启动
• 就绪（Runnable）：线程已准备就绪，等待CPU调度
• 运行（Running）：线程正在执行指令
• 阻塞（Blocked）：线程因I/O、锁竞争等原因暂停执行
• 终止（Terminated）：线程执行完毕或被强制中断

状态转换的触发条件

线程状态的变更由特定事件驱动。例如调用阻塞式I/O操作会使线程从运行态转入阻塞态；当I/O完成，线程重新进入就绪队列。

当前状态	触发事件	目标状态
就绪	CPU调度选中	运行
运行	时间片耗尽	就绪
运行	等待锁或I/O	阻塞
阻塞	资源就绪	就绪

代码示例：模拟状态切换

package main

import (
    "fmt"
    "time"
)

func worker() {
    fmt.Println("线程进入运行状态")
    time.Sleep(2 * time.Second) // 模拟阻塞操作
    fmt.Println("线程即将终止")
}

func main() {
    go worker() // 启动协程，进入就绪/运行状态
    fmt.Println("主线程继续执行")
    time.Sleep(3 * time.Second)
}

上述Go语言示例中，通过 go worker()启动新协程，其在调度后进入运行态， time.Sleep模拟了导致阻塞的操作，最终协程自然退出至终止状态。

graph TD A[新建] --> B[就绪] B --> C[运行] C --> D[阻塞] D --> B C --> E[终止]

第二章：RUNNABLE与BLOCKED状态的理论解析

2.1 Java线程状态模型与操作系统调度关系

Java线程的生命周期由JVM定义，包含 New、 Runnable、 Blocked、 Waiting、 Timed Waiting和 Terminated六种状态。这些状态映射到操作系统层面时，依赖于底层线程调度器的实现。

Java线程状态与OS线程的对应关系

尽管Java抽象了线程模型，但其实际执行受操作系统调度控制。例如，JVM中的“Runnable”状态可能包含OS层面的“运行”和“就绪”两种状态。

Java线程状态	对应操作系统行为
Runnable	线程在可运行队列中，等待CPU调度
Blocked/Waiting	线程被挂起，不参与调度

Thread t = new Thread(() -> {
    synchronized (lock) {
        try {
            Thread.sleep(1000); // 进入TIMED_WAITING
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        }
    }
});
t.start(); // 状态：New → Runnable

上述代码中，调用 start()后线程进入Runnable状态，实际是否运行由操作系统决定；执行 sleep()时，JVM将线程置为TIMED_WAITING，OS将其移出调度队列。

2.2 RUNNABLE状态的真实含义：就绪还是运行？

在Java线程模型中， RUNNABLE状态并不等同于“正在运行”，而是表示线程处于**可运行状态**，即已获取CPU资格，等待调度执行。

状态的深层解读

操作系统层面的“运行”仅指当前正在CPU上执行的线程，而JVM中的 RUNNABLE涵盖了“就绪”和“运行”两个阶段。

• 就绪：线程已准备好，等待CPU调度
• 运行：线程正在CPU上执行

代码示例与分析

Thread thread = new Thread(() -> {
    while (true) {
        // 执行任务
    }
});
thread.start(); // 状态变为RUNNABLE

调用 start()后，线程进入 RUNNABLE状态，但具体何时执行由操作系统调度器决定。即使多个线程处于该状态，也仅有少数能真正“运行”。

CPU调度的影响

线程状态	JVM视角	OS视角
RUNNABLE	可运行（就绪 + 运行）	Running / Ready

2.3 BLOCKED状态的触发条件与底层原理

当线程尝试获取已被占用的监视器锁时，JVM会将其置为BLOCKED状态。该状态主要发生在synchronized代码块或方法竞争中。

典型触发场景

• 多个线程争用同一对象的同步方法
• 线程在进入synchronized代码块时发现锁被占用
• 持有锁的线程未释放前，其他线程无法进入临界区

JVM线程状态转换

synchronized (lock) {
    // 其他线程在此处阻塞
    doWork();
}

上述代码中，若线程A已持有lock对象的监视器，线程B将进入BLOCKED状态，直至A释放锁。

底层机制

JVM通过操作系统的互斥量（mutex）实现monitor锁。每个对象的ObjectMonitor维护着_EntryList，存放阻塞的线程队列。当持有线程退出同步块时，JVM从_EntryList中唤醒一个线程尝试获取锁。

2.4 监视器锁（Monitor）与线程阻塞的关联分析

监视器锁的基本机制

在Java虚拟机中，每个对象都关联一个监视器（Monitor），用于实现同步控制。当线程进入synchronized代码块时，必须获取对象的监视器锁。

synchronized (obj) {
    // 线程需先获得obj的监视器
    // 才能执行临界区代码
}

上述代码中，若线程无法立即获取锁，则会被阻塞并进入该对象监视器的阻塞队列。

线程阻塞与唤醒流程

监视器维护了两个重要队列：Entry Set 和 Wait Set。

• Entry Set：存放等待获取锁的线程
• Wait Set：存放调用wait()方法后被释放锁的线程

当持有锁的线程调用notify()或notifyAll()时，Wait Set中的线程将被重新调度竞争锁。

状态	触发动作	结果
尝试进入synchronized	锁已被占用	进入Entry Set阻塞
执行obj.wait()	释放锁	进入Wait Set阻塞

2.5 状态转换图解：从代码到JVM的全过程追踪

在Java程序执行过程中，代码从源码到JVM运行时经历了多个状态转换阶段。理解这些阶段有助于深入掌握类加载机制与字节码执行模型。

编译期到运行时的流转

Java源文件经javac编译为.class文件，随后由类加载器加载至JVM。该过程涉及加载、验证、准备、解析和初始化五个阶段。

public class HelloWorld {
    public static void main(String[] args) {
        System.out.println("Hello, JVM!");
    }
}

上述代码被编译后生成字节码，通过常量池、方法区结构映射至内存模型中，最终由执行引擎解释或即时编译执行。

JVM内部状态转换流程

阶段	主要动作
加载	读取.class文件，生成Class对象
验证	确保字节码安全合规
准备	为静态变量分配内存并设初值
解析	符号引用转为直接引用
初始化	执行clinit()方法完成静态初始化

第三章：导致RUNNABLE→BLOCKED的典型场景

3.1 synchronized竞争导致的线程阻塞实战演示

在多线程并发场景中， synchronized关键字用于保证方法或代码块的原子性。当多个线程竞争同一把锁时，未获取到锁的线程将进入阻塞状态。

示例代码

public class SynchronizedDemo {
    public static synchronized void task() {
        System.out.println(Thread.currentThread().getName() + " 开始执行");
        try {
            Thread.sleep(2000); // 模拟耗时操作
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        System.out.println(Thread.currentThread().getName() + " 执行完毕");
    }

    public static void main(String[] args) {
        Runnable r = SynchronizedDemo::task;
        new Thread(r, "Thread-1").start();
        new Thread(r, "Thread-2").start();
        new Thread(r, "Thread-3").start();
    }
}

上述代码中， task() 方法被 synchronized 修饰，同一时刻只能有一个线程执行。其余线程将因锁竞争而阻塞，直到当前持有锁的线程释放。

执行结果分析

• Thread-1 获取锁并执行，其他线程处于 BLOCKED 状态；
• 每2秒释放一次锁，下一个线程抢到锁后继续执行；
• 体现了串行化访问对并发性能的影响。

3.2 重入锁（ReentrantLock）争用中的状态变化观察

在多线程并发场景下， ReentrantLock 的内部状态变化是理解锁竞争行为的关键。其核心基于 AQS（AbstractQueuedSynchronizer）实现，通过 volatile 变量 state 表示锁的持有状态。

锁状态转换流程

• state = 0：锁空闲，无任何线程持有
• state > 0：锁被占用，值表示重入次数
• 线程获取锁时执行 CAS 操作递增 state
• 释放锁时递减 state，归零后唤醒等待队列中的线程

代码示例：模拟争用场景

ReentrantLock lock = new ReentrantLock();
lock.lock(); // state 从 0 → 1
try {
    // 临界区
} finally {
    lock.unlock(); // state -= 1，若为0则释放锁
}

上述代码中， lock() 调用触发 state 的原子性变更，多个线程竞争时，未获取锁的线程将被封装为 Node 节点加入同步队列，进入阻塞状态，直至前驱节点释放并唤醒后续节点。

3.3 线程等待监视器进入时的JVM行为剖析

当多个线程竞争同一对象的同步代码块时，JVM通过监视器（Monitor）机制保障互斥访问。未获得锁的线程将进入阻塞状态，并被加入该对象监视器的等待集合中。

线程状态转换流程

• 线程尝试获取对象的监视器锁
• 若锁已被占用，线程转入BLOCKED状态
• JVM将其放入该对象的Entry Set队列
• 持有锁的线程释放后，JVM从Entry Set中唤醒一个线程重新竞争

典型代码示例

synchronized (obj) {
    // 线程持有obj的监视器
    while (!condition) {
        obj.wait(); // 释放锁并进入Wait Set
    }
}

上述代码中，调用 wait()的线程会释放监视器并进入 Wait Set，直到其他线程执行 notify()或 notifyAll()。

监视器内部结构简表

组件	作用
Owner	当前持有锁的线程
Entry Set	等待获取锁的线程队列
Wait Set	调用wait()后等待通知的线程队列

第四章：诊断与优化线程阻塞问题

4.1 使用jstack捕获线程堆栈并识别BLOCKED状态

在Java应用运行过程中，线程阻塞问题常导致系统响应变慢甚至停滞。使用`jstack`工具可以导出JVM当前的线程堆栈信息，帮助定位处于`BLOCKED`状态的线程。

获取线程堆栈快照

通过以下命令生成线程转储：

jstack <pid> > thread_dump.log

其中 ` ` 是目标Java进程ID。该命令输出所有线程的调用栈，包括其当前状态。

识别BLOCKED线程

在输出中查找状态为 `java.lang.Thread.State: BLOCKED` 的线程，并关注其等待的锁地址（如 `waiting to lock <0x000000078fcf7a00>`）。多个线程竞争同一锁时，除持有者外其余均进入BLOCKED状态。

• BLOCKED线程无法继续执行，直到获得所需监视器锁
• 结合堆栈信息可定位到具体的同步代码块或方法

4.2 利用JVisualVM进行可视化线程监控

JVisualVM 是 JDK 自带的多功能可视化监控工具，能够实时观察 Java 应用的线程状态、内存使用和方法执行性能。

启动与连接应用

通过命令行启动工具：

jvisualvm

运行后，JVisualVM 会列出本地正在运行的 Java 进程，双击即可建立连接，无需额外配置。

线程监控视图

在“监视”标签页中，可查看应用程序的 CPU、堆内存及线程数变化趋势。点击“线程”子标签，将显示所有线程的实时状态（运行、等待、阻塞等），并以彩色波形图呈现线程活动历史。

• 绿色表示运行态（Runnable）
• 黄色表示等待态（Waiting）
• 红色表示阻塞态（Blocked）

当检测到死锁时，JVisualVM 会在“线程”面板顶部提示“检测到死锁”，并列出涉及的线程及其调用栈，便于快速定位同步问题。

4.3 分析死锁与锁争用对状态转换的影响

在并发系统中，线程或事务的状态转换常因资源竞争而受阻。死锁发生时，多个实体相互等待对方持有的锁，导致所有相关进程停滞在“运行”到“阻塞”的转换路径上。

锁争用的典型表现

• 线程在尝试获取锁时进入等待状态
• 高争用下，大量线程堆积在就绪队列
• 上下文切换频率上升，系统吞吐下降

死锁导致的状态冻结示例

var mu1, mu2 sync.Mutex

func A() {
    mu1.Lock()
    time.Sleep(100 * time.Millisecond)
    mu2.Lock() // 可能死锁
}
func B() {
    mu2.Lock()
    mu1.Lock() // 可能死锁
}

上述代码中，若两个 goroutine 分别执行 A 和 B，可能各自持有不同锁并等待对方释放，造成永久阻塞，中断正常的状态迁移流程。

影响对比表

现象	状态转换影响	性能表现
锁争用	延迟转换	响应变慢
死锁	完全阻断	服务挂起

4.4 减少BLOCKED发生频率的编码最佳实践

在高并发编程中，线程因资源竞争进入BLOCKED状态会显著影响系统吞吐量。通过合理的编码策略可有效降低阻塞概率。

避免长持有锁

将耗时操作移出同步块，缩短临界区执行时间：

synchronized (lock) {
    // 仅保留核心数据更新
    sharedCounter++;
}
// 文件IO、网络调用等耗时操作置于锁外
writeToLog("Updated counter");

上述代码确保锁的持有时间最小化，减少其他线程争用导致的BLOCKED。

使用读写锁优化读多写少场景

• ReentrantReadWriteLock允许多个读线程并发访问
• 写线程独占锁，保障一致性
• 相比独占锁，显著降低读操作的阻塞频率

合理设置线程池大小

过大的并发度会加剧锁竞争。应根据CPU核心数与任务类型调整：

场景	推荐线程数
CPU密集型	核心数 + 1
IO密集型	2 × 核心数

第五章：结语——掌握线程状态，掌控高并发

理解线程生命周期的实际意义

在高并发系统中，线程的创建、阻塞、唤醒和终止直接影响系统的吞吐量与响应时间。例如，在一个电商秒杀系统中，大量请求涌入时，若线程频繁进入 BLOCKED 状态等待锁资源，可能导致请求堆积。通过合理使用 ReentrantLock 配合超时机制，可有效避免无限等待。

ReentrantLock lock = new ReentrantLock();
if (lock.tryLock(500, TimeUnit.MILLISECONDS)) {
    try {
        // 执行关键操作
    } finally {
        lock.unlock();
    }
} else {
    // 超时处理，快速失败
    throw new TimeoutException("获取锁超时");
}

监控线程状态提升系统可观测性

生产环境中，可通过 JMX 或 APM 工具实时采集线程状态分布。以下为常见线程状态统计表示例：

状态	含义	典型场景
RUNNABLE	正在运行或就绪	CPU 密集型任务
WAITING	无限等待通知	调用 object.wait()
TIMED_WAITING	限时等待	sleep(1000)
BLOCKED	等待监视器锁	同步方法竞争

优化策略建议

• 避免使用 synchronized 大范围同步块，改用细粒度锁
• 利用线程池控制并发数，防止线程过度创建
• 结合 Phaser 或 CompletableFuture 实现异步协作

状态流转示意：RUNNABLE ↔ BLOCKED ↔ WAITING/TIMED_WAITING → TERMINATED