探索虚拟线程：原理与实现

测试智商的网站 1天前阅读数 4648 #性能测试

探索虚拟线程：原理与实现

介绍 (Introduction)

Java 虚拟线程 (Virtual Threads) 是 Java 平台在 JDK 21 中正式发布的一项革命性新特性 (经过 JDK 19 和 20 的预览)。它们是一种轻量级的、由 JVM 管理的线程，旨在极大地简化编写高吞吐量并发应用，特别是那些涉及大量等待（如网络 I/O 或数据库查询）的应用。与传统的平台线程（即操作系统线程）不同，虚拟线程数量可以极其庞大（可能数百万甚至更多），且创建和切换的开销非常低。它们保留了直观的“每请求一线程”的编程模型，避免了回调地狱或复杂的异步框架，同时提供了接近异步非阻塞编程的扩展能力。

引言 (Foreword/Motivation)

长期以来，Java 在处理高并发 I/O 密集型任务时面临一个挑战。传统的 Java 线程是平台线程，它们与操作系统线程一对一映射 (1:1)。虽然 OS 线程功能强大，但也相对“重量级”：每个线程需要固定的内存栈空间（通常是 1MB 或更多），创建和上下文切换的开销较高。

在构建需要同时处理数千甚至数万个并发连接（如现代 Web 服务器）的应用时，如果采用传统的“每请求一线程”模型，很快就会耗尽系统资源（主要是内存和 OS 调度开销），导致吞吐量下降甚至系统崩溃。为了解决这个问题，开发者们转向了复杂的异步编程模型，如回调、Future、CompletableFuture 或响应式框架（如 Reactor, RxJava），虽然这些模型能提高扩展性，但它们往往改变了编程范式，降低了代码的可读性和可维护性，增加了调试难度。

虚拟线程的目标是两全其美：既提供平台线程的简单直观的编程模型，又能达到接近异步编程的扩展能力。它们让你可以继续以同步、阻塞的方式编写 I/O 密集型代码，但在运行时却能高效地利用系统资源。

技术背景 (Technical Background)

平台线程 (Platform Threads): Java 诞生以来就有的线程模型。JVM 创建一个 java.lang.Thread 对象时，默认情况下会向操作系统请求创建一个对应的 OS 线程。JVM 调度器负责在这些 OS 线程上运行 Java 代码，而 OS 调度器负责在 CPU 核心上调度 OS 线程。阻塞一个平台线程会阻塞底层的 OS 线程，使其在等待期间无法执行任何计算任务，白白占用 OS 资源。
阻塞 I/O (Blocking I/O): 大多数传统的 Java I/O 操作（如 java.io 包中的流操作，或 java.net.Socket 的读写）默认是阻塞的。当一个线程执行阻塞 I/O 操作时，它会暂停执行，直到操作完成。在平台线程模型下，这意味着一个宝贵的 OS 线程被挂起，无法服务其他请求。
非阻塞 I/O (Non-blocking I/O) 和 NIO: Java 提供了 NIO (New I/O) 框架（java.nio 包），支持非阻塞 I/O 和多路复用（如 Selector）。这允许一个线程管理多个 I/O 通道，提高单个线程的效率。但使用 NIO 需要采用事件驱动或反应式编程风格，代码复杂度通常更高。

原理解释 (Principle Explanation)

虚拟线程的核心原理是实现了 Java 线程的 N:M 映射，即将大量（N）虚拟线程映射到少量（M）平台线程上运行，而不是传统的 1:1 映射。

载体线程 (Carrier Threads): 虚拟线程不是直接由操作系统调度的。它们运行在传统的平台线程之上，这些平台线程充当虚拟线程的“载体”。JVM 使用一个小的、通常是固定的平台线程池作为载体线程池（默认是 ForkJoinPool，但你也可以指定）。
挂载 (Mounting): 当一个虚拟线程需要执行计算任务时（即运行 CPU 密集型代码），它会被“挂载”到一个空闲的载体线程上执行。此时，虚拟线程暂时“借用”了载体线程的 OS 资源。
卸载 (Unmounting): 当虚拟线程遇到阻塞的 I/O 操作时（例如，从 Socket 读取数据但数据尚未到达），它不会阻塞其载体线程。相反，JVM 会识别出这个阻塞操作，并“卸载”该虚拟线程，将虚拟线程的执行状态（包括程序计数器、堆栈等）存储在 JVM 内存中的堆上。此时，载体线程被释放，可以立即去挂载和运行另一个等待执行的虚拟线程。
泊入/泊出 (Parking/Unparking): 卸载的虚拟线程进入“泊入”（Parked）状态，等待它阻塞的 I/O 操作完成。当 I/O 操作完成时，相关的通知机制（例如，基于 epoll 或 kqueue 等 OS 事件通知机制，通常由 JVM 或其网络库处理）会触发 JVM 将该虚拟线程标记为可运行（Ready）。此时，虚拟线程进入“泊出”（Unparked）状态，可以再次被调度到任何空闲的载体线程上继续执行，从它上次阻塞的地方恢复。
JVM 调度: JVM 的调度器负责在载体线程池中管理虚拟线程的挂载和卸载。它比 OS 调度器更轻量、更高效，因为它不需要涉及 OS 级别的上下文切换。

关键点:

虚拟线程的堆栈保存在 JVM 内存中（通常是堆上的一个轻量级对象），而不是昂贵的 OS 线程栈。
创建虚拟线程的开销主要是在堆上分配一个对象，远小于创建 OS 线程。
虚拟线程特别适合 I/O 密集型 任务，因为它们在等待 I/O 时能够释放载体线程。
对于 CPU 密集型 任务，虚拟线程的优势不明显，因为它们会一直占用载体线程直到计算完成。如果所有虚拟线程都是 CPU 密集型的，它们仍然会被少数载体线程串行执行，性能不会比少量平台线程高，甚至可能因为额外的调度层而略有下降。
Pinning (钉住): 在某些特定情况下，虚拟线程无法被卸载，会“钉住”其载体线程。常见情况包括在虚拟线程中执行 native 方法，或在虚拟线程中进入一个 synchronized 方法或代码块，并且该锁是通过对象监视器实现的（而不是 java.util.concurrent 包中的锁）。钉住会阻止载体线程服务其他虚拟线程，可能导致载体线程池饥饿，降低扩展性。应尽量避免在虚拟线程中执行长时间的 native 调用或使用对象监视器锁。

核心特性 (Core Features)

轻量级: 极低的内存开销和创建/销毁开销。
高并发性: 能够轻松支持数万到数百万并发线程。
易用性: 沿用标准的 java.lang.Thread API 和 java.util.concurrent.ExecutorService 接口，编程模型不变。
高效利用资源: 在 I/O 等待时释放底层 OS 线程。
JVM 管理: 由 JVM 负责调度和生命周期管理。
提升吞吐量: 显著提高 I/O 密集型应用的并发处理能力。

实现方式 (Implementation - How to Create/Use)

Java 提供了几种创建和使用虚拟线程的方式：

直接创建并启动单个虚拟线程:

Thread.ofVirtual().start(() -> {
    // 虚拟线程执行的任务
    System.out.println("Hello from virtual thread!");
});

创建未启动的虚拟线程 (不常用):

Thread virtualThread = Thread.ofVirtual().unstarted(() -> {
     // 任务
});
// ... 执行一些操作 ...
virtualThread.start();

使用 ExecutorService (推荐用于管理大量任务):
Java 提供了专门的 ExecutorService 实现来方便地为每个提交的任务创建一个新的虚拟线程。

import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;

// 创建一个 ExecutorService，每个任务都由一个新的虚拟线程执行
try (ExecutorService executor = Executors.newVirtualThreadPerTaskExecutor()) {
    executor.submit(() -> {
        // 任务 1
    });
    executor.submit(() -> {
        // 任务 2
    });
    // ... 提交更多任务 ...
} // try-with-resources 会在退出时关闭 executor 并等待所有虚拟线程完成

这是处理大量并发 I/O 任务时最推荐的方式。

完整代码实现 (Complete Code Example)

以下是一个完整的 Java 代码示例，演示如何使用虚拟线程处理大量模拟的阻塞任务，并与平台线程进行对比，展示其在时间上的优势。

import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.TimeUnit;
import java.util.stream.IntStream;

public class VirtualThreadDemo {

    private static final int NUMBER_OF_TASKS = 10_000; // 模拟的任务数量
    private static final int SIMULATED_IO_LATENCY_MS = 100; // 模拟的 I/O 延迟 (毫秒)

    // 模拟一个 I/O 密集型任务
    private static void performIOTask(int taskId) {
        try {
            // System.out.println(Thread.currentThread().getName() + " - Task " + taskId + " starting I/O...");
            // 模拟阻塞 I/O 操作
            Thread.sleep(SIMULATED_IO_LATENCY_MS);
            // System.out.println(Thread.currentThread().getName() + " - Task " + taskId + " finishing I/O.");
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt(); // 恢复中断状态
            System.err.println("Task " + taskId + " interrupted.");
        }
    }

    public static void main(String[] args) throws InterruptedException {

        System.out.println("Starting demonstration with " + NUMBER_OF_TASKS + " tasks, each simulating " + SIMULATED_IO_LATENCY_MS + "ms latency.");

        // --- 使用平台线程池 ---
        System.out.println("\n--- Running with Platform Threads (Fixed Thread Pool) ---");
        // 通常，对于大量并发连接，使用固定大小的线程池（例如，CPU核心数 * 2）
        // 这里为了更明显对比开销，我们使用一个稍大但仍有限制的池
        // 或者使用 newCachedThreadPool 来模拟无限多的平台线程，但很快会耗尽资源
        // 这里使用固定大小的线程池来展示资源限制
        int numberOfPlatformThreads = 200; // 假设我们只能负担得起这么多平台线程
        long startTimePlatform = System.currentTimeMillis();

        try (ExecutorService platformExecutor = Executors.newFixedThreadPool(numberOfPlatformThreads)) {
             IntStream.range(0, NUMBER_OF_TASKS).forEach(taskId ->
                platformExecutor.submit(() -> performIOTask(taskId))
             );
        } // try-with-resources ensures shutdown and awaitTermination

        long endTimePlatform = System.currentTimeMillis();
        System.out.println("Platform Threads Total Time: " + (endTimePlatform - startTimePlatform) + " ms");
        // 预期结果: 时间接近 NUMBER_OF_TASKS * SIMULATED_IO_LATENCY_MS / numberOfPlatformThreads
        // 因为线程数有限，任务会排队等待执行


        // --- 使用虚拟线程 ---
        System.out.println("\n--- Running with Virtual Threads ---");
        long startTimeVirtual = System.currentTimeMillis();

        // 使用 newVirtualThreadPerTaskExecutor，每个任务都创建一个新的虚拟线程
        try (ExecutorService virtualExecutor = Executors.newVirtualThreadPerTaskExecutor()) {
             IntStream.range(0, NUMBER_OF_TASKS).forEach(taskId ->
                virtualExecutor.submit(() -> performIOTask(taskId))
             );
        } // try-with-resources ensures shutdown and awaitTermination

        long endTimeVirtual = System.currentTimeMillis();
        System.out.println("Virtual Threads Total Time: " + (endTimeVirtual - startTimeVirtual) + " ms");
        // 预期结果: 时间接近 SIMULATED_IO_LATENCY_MS (如果载体线程足够)
        // 因为虚拟线程在阻塞时会释放载体线程，大量任务可以并发执行
        // 实际时间可能会略长于 SIMULATED_IO_LATENCY_MS，取决于载体线程数量和调度开销

        System.out.println("\nDemonstration finished.");

        // 注意：为了更清晰地展示，上面的 System.out.println 在任务内部被注释掉了。
        // 如果取消注释，输出会非常多且混乱，但能看到大量虚拟线程的名字 (VirtualThread[...]/run)
        // 而平台线程的名字通常是 pool-x-thread-y。
    }
}

运行结果 (Execution Results)

运行上述代码，你将在控制台看到类似以下的输出（具体时间取决于你的机器性能和当前负载）：

Starting demonstration with 10000 tasks, each simulating 100ms latency.

--- Running with Platform Threads (Fixed Thread Pool) ---
Platform Threads Total Time: 50xx ms  // 预期接近 10000 * 100 / 200 = 5000 ms

--- Running with Virtual Threads ---
Virtual Threads Total Time: 1xx ms   // 预期接近 100 ms

Demonstration finished.

结果解释:

平台线程: 由于平台线程池大小固定为 200，10000 个任务无法同时执行。它们需要排队等待空闲线程。粗略估计，完成所有任务所需时间是 (任务总数 / 线程池大小) * 单个任务 I/O 延迟，即 (10000 / 200) * 100ms = 50 * 100ms = 5000ms。运行结果与此预期大致相符。这体现了平台线程在面对大量并发阻塞任务时的扩展瓶颈。
虚拟线程: 尽管只有少量载体线程在运行，但由于虚拟线程在 Thread.sleep() 模拟阻塞时会立即释放载体线程，使得其他虚拟线程有机会被调度。因此，10000 个虚拟线程几乎可以“同时”进行它们的 100ms 阻塞等待。总的完成时间主要取决于最长的等待时间加上极低的虚拟线程创建、调度开销，预期接近单个任务的 I/O 延迟本身（100ms）。运行结果的显著提升（从几秒到一百多毫秒）直观地展示了虚拟线程在 I/O 密集型场景下的强大扩展能力。

测试步骤以及详细代码 (Testing Steps and Detailed Code)

上面的“完整代码实现”部分的代码本身就是一个用于测试和演示虚拟线程优势的详细示例。以下是运行和修改该示例进行测试的步骤：

环境准备: 确保你的机器安装了 JDK 21 或更高版本。
保存代码: 将上面的 Java 代码保存为名为 VirtualThreadDemo.java 的文件。
编译代码: 打开终端或命令行界面，进入文件所在的目录，使用 JDK 21+ 的 javac 编译器进行编译：
```
javac VirtualThreadDemo.java
```
运行代码: 编译成功后，使用 JDK 21+ 的 java 命令运行编译后的类：
```
java VirtualThreadDemo
```
观察结果: 查看控制台输出，比较平台线程和虚拟线程的总运行时间。
修改参数进行测试:
- 修改 NUMBER_OF_TASKS 的值（例如，1000, 10000, 100000），重新编译并运行，观察时间变化。你会发现随着任务数量增加，平台线程的总时间几乎呈线性增长（受到线程池大小限制），而虚拟线程的总时间增长缓慢，基本维持在单次模拟延迟附近。
- 修改 SIMULATED_IO_LATENCY_MS 的值。如果延迟变大，两种方式的总时间都会增加，但虚拟线程的优势依然明显。
- 修改平台线程池的大小 (numberOfPlatformThreads)，观察平台线程的总时间如何受线程池大小影响。

进阶测试 (使用 JDK 监控工具):

你可以使用 JDK 自带的监控工具（如 JConsole 或 VisualVM）来观察运行时的线程数量。

运行代码，保持程序运行: 在 main 方法末尾添加 Thread.currentThread().join(); (或者一个无限循环 Thread.sleep(Long.MAX_VALUE);)，防止程序立即退出。
启动监控工具: 打开 JConsole 或 VisualVM。
连接到 VirtualThreadDemo 进程。
观察线程数量: 在 JConsole 的“线程”标签页或 VisualVM 的“线程”视图中，观察线程数量。
- 运行平台线程部分时，你会看到线程数量接近 numberOfPlatformThreads（加上一些 JVM 内部线程）。
- 运行虚拟线程部分时，你会看到平台线程数量非常少（即载体线程数量），但如果你能看到虚拟线程的列表，会发现有大量的虚拟线程存在。VisualVM 通常能更好地显示虚拟线程信息。

部署场景 (Deployment Scenarios)

虚拟线程特别适用于以下部署场景：

高并发网络服务器 (如 Web 服务器、API Gateway): 传统服务器在处理大量连接时，每个连接分配一个平台线程会导致资源耗尽。使用虚拟线程，每个连接或请求可以拥有自己的虚拟线程，大大提高服务器的并发处理能力，同时保持同步编程风格。许多现代基于 Java 的 Web 框架（如 Spring Boot 3.2+）已经内置了对虚拟线程的支持，可以轻松配置 Web 服务器（如 Tomcat, Jetty, Undertow）使用虚拟线程来处理请求。
后端微服务: 大多数微服务需要频繁进行数据库访问、调用其他微服务（HTTP 调用）、访问缓存或消息队列。这些都是 I/O 密集型操作。使用虚拟线程可以提高微服务的吞吐量和响应速度。
异步任务处理系统: 从消息队列（如 Kafka, RabbitMQ）读取消息进行处理时，每个消息的处理逻辑通常涉及 I/O 操作。使用虚拟线程可以高效地处理大量并发消息。
数据抓取或爬虫: 并发抓取多个网页通常是 I/O 密集型任务。虚拟线程使得编写高效的并发抓取程序更加简单。
替代传统线程池: 在现有应用中，如果大量使用了固定大小或缓存的平台线程池来处理 I/O 密集型任务，可以考虑替换为使用 Executors.newVirtualThreadPerTaskExecutor() 创建的虚拟线程池，以提升扩展性。

疑难解答 (Troubleshooting)

PVC 长时间 Pending 或卷挂载失败:
- 原因: 虚拟线程在某些情况下无法被卸载，会“钉住”其载体线程。
- 场景:
  - 在虚拟线程中执行长时间运行的本地 (native) 代码。
  - 在虚拟线程中同步等待一个 Mutex 或条件变量，并且该锁是基于对象监视器（即使用 synchronized 关键字）而不是 java.util.concurrent.locks 包中的锁。
- 影响: 如果大量虚拟线程被钉住，它们会长时间占用载体线程，导致载体线程池耗尽，新的虚拟线程无法挂载执行，整体吞吐量下降。
- 识别: 使用 JDK 监控工具（如 JConsole 或 VisualVM）可以观察到钉住的虚拟线程（通常有特定的标记或状态）。
- 解决方法:
  - 避免在虚拟线程中执行长时间的 native 调用。如果必须，考虑将其移至一个专门的平台线程池处理。
  - 优先使用 java.util.concurrent.locks 包中的锁（如 ReentrantLock）代替 synchronized 关键字，因为它们是虚拟线程友好的，不会导致钉住。
  - 审查代码中是否有其他可能导致虚拟线程无法卸载的阻塞操作（JVM 可能会识别大部分标准库 I/O，但自定义的阻塞操作可能需要注意）。
CPU 密集型任务性能不佳:
- 原因: 虚拟线程不提升 CPU 密集型任务的性能，它们的设计目标是解决 I/O 阻塞问题。
- 解决方法: 对于 CPU 密集型任务，继续使用平台线程池（通常大小设置为 CPU 核心数附近）是更合适的选择。不要将虚拟线程用于纯粹的计算任务。
内存使用意外增长:
- 原因: 尽管虚拟线程轻量，但创建过多、生命周期过长的虚拟线程仍然会消耗内存。同时，如果在虚拟线程中引用了大量对象，这些对象也会占用内存。
- 解决方法: 确保虚拟线程执行的任务能够正常结束，避免创建无限量的虚拟线程。优化任务逻辑，减少不必要的对象创建和引用。
与旧有库的兼容性问题:
- 原因: 某些老旧的 Java 库可能使用了导致钉住的模式（例如广泛使用 synchronized 或底层 native I/O 而非 NIO）。
- 解决方法: 更新到支持虚拟线程的库版本。如果无法更新，可能需要隔离这些库的使用，或者为其使用单独的平台线程池。

未来展望 (Future Outlook)

虚拟线程是 Java 平台向更高效、更易用的并发模型迈出的重要一步。未来，我们可以期待：

更广泛的应用场景: 虚拟线程将成为构建各种高并发应用的默认选择，取代传统基于回调或响应式的复杂模型。
库和框架的全面支持: 更多的 Java 库和框架将优化其内部实现，使其对虚拟线程友好，避免钉住等问题。Spring、Jakarta EE 等主流框架已开始全面支持。
与结构化并发 (Structured Concurrency) 的结合: 结构化并发 (JEP 428, JEP 462) 提供了更好的并发任务管理和错误处理机制，与虚拟线程结合可以构建更健壮的应用。
调试和监控工具的增强: JVM 和开发工具将提供更强大的功能来监控和调试运行在虚拟线程上的应用，更容易发现钉住等问题。
对更多阻塞操作的支持: 未来可能会有更多类型的阻塞操作能够被 JVM 识别和卸载。

技术趋势与挑战 (Technology Trends and Challenges)

技术趋势:

并发模型回归简单: 从复杂的异步模型回归到直观的同步阻塞模型，但底层通过虚拟线程获得高扩展性。
声明式并发: 结构化并发和虚拟线程结合，使并发代码更具结构和可读性。
更高效的资源利用: 减少线程开销，提高服务器密度。
云原生亲和性: 虚拟线程有助于在弹性伸缩的云环境中更好地利用资源。

挑战:

开发者观念转变: 开发者需要理解虚拟线程的工作原理，特别是钉住等概念，避免误用。
遗留代码和库的兼容性: 改造旧应用或使用不兼容的库可能面临挑战。
性能调优: 虽然虚拟线程简化了编程，但在极端性能场景下，识别和解决钉住等性能瓶颈仍然需要深入理解。
资源管理: 尽管单个虚拟线程开销低，但无限制地创建虚拟线程仍然可能耗尽内存或其他资源。需要合理的任务管理策略。
调试复杂性: 调试数百万个线程的环境可能需要更强大的工具和技术。

总结 (Conclusion)

Java 虚拟线程是 Java 平台在应对现代高并发 I/O 挑战方面迈出的重要一步。它们通过实现轻量级的 N:M 线程映射，使得开发者能够继续沿用简单直观的“每请求一线程”编程模型，同时获得传统异步非阻塞编程所提供的可扩展性。虚拟线程极大地提高了 I/O 密集型应用的开发效率和运行时吞吐量。虽然在使用时需要注意钉住等问题，但随着生态系统的完善和开发者对其原理的深入理解，虚拟线程必将成为 Java 并发编程的基石，推动 Java 应用在云原生时代更好地发展。

随机文章
热门文章
热评文章

上一篇：前端对话框项目——调用字节 Coze API 下一篇：Python在GUI界面开发中的应用与可视化技术