乐于分享
好东西不私藏
当前位置：夜雨聆风 > 技术教程 > 软件教程 > 深入虚拟线程源码:Spring Boot 4.0原生支持的底层逻辑,线程调度原理全拆解

深入虚拟线程源码:Spring Boot 4.0原生支持的底层逻辑,线程调度原理全拆解

当前时间： 2026-04-16 10:06:23 更新时间： 2026-04-16 分类：软件教程 评论(0)

深入虚拟线程源码:Spring Boot 4.0原生支持的底层逻辑,线程调度原理全拆解

上一篇文章我们聊了虚拟线程的基础用法，很多小伙伴留言追问：「为什么Spring Boot 4.0能直接原生支持虚拟线程？」「虚拟线程的底层调度到底和传统线程有啥区别？」「源码里藏着哪些关键逻辑？」

今天就带着这些问题，我们再往深挖一层——不堆砌概念，不绕弯子，直接拆解JDK虚拟线程核心源码，讲清Spring Boot 4.0原生支持的底层逻辑，把线程调度的底层原理讲透，让你不仅会用，还能懂其本质。

先划重点：Spring Boot 4.0的原生支持，本质是「对JDK虚拟线程的深度适配+容器级别的调度优化」，而虚拟线程的高性能，核心在于「M:N调度模型+轻量级栈管理」，源码里的关键类（VirtualThread、Continuation、Scheduler）就是解开所有疑问的钥匙。

一、先回顾：为什么虚拟线程能替代传统线程？

在拆解源码前，先快速回顾核心差异——传统Java线程（Platform Thread）是「1:1映射」，一个Java线程绑定一个操作系统内核线程，创建销毁成本高、栈内存占用大（默认1MB），并发量一旦突破几千就容易出现OOM或性能瓶颈[superscript:1]。

而虚拟线程（Virtual Thread）是「M:N映射」，大量虚拟线程（M）映射到少量平台线程（N，也叫载体线程Carrier Thread），初始栈仅几KB且按需扩展，创建销毁几乎无成本，能轻松支撑百万级并发[superscript:5]。

这也是Spring Boot 4.0选择原生支持它的核心原因：无需修改业务代码，就能让高并发场景（比如接口调用、数据库查询、HTTP请求）的吞吐量大幅提升，还能避免异步编程带来的代码复杂度。

二、核心源码拆解：虚拟线程的底层实现（JDK 21+）

虚拟线程的核心源码集中在java.lang.VirtualThread 类（JDK 21正式稳定），以及其依赖的 Continuation（续体）、Scheduler（调度器），我们逐一看关键逻辑，只挑核心代码，不搞冗余解读。

2.1 核心类1：VirtualThread——虚拟线程的入口

VirtualThread是虚拟线程的实现类，继承自BaseVirtualThread，核心是封装任务、续体和调度器，没有传统线程的nativeThread（内核线程指针），这是它轻量的关键[superscript:1]。

关键源码（简化版，保留核心逻辑）：

// 虚拟线程核心实现，final修饰，不可继承
final class VirtualThread extends BaseVirtualThread {
    // 虚拟线程要执行的任务
    private final Runnable task;
    // 续体：用于保存/恢复虚拟线程的执行状态（栈帧、局部变量等）
    private final Continuation continuation;
    // 调度器：负责将虚拟线程分配给载体线程执行
    private final Scheduler scheduler;

    // 构造器：初始化虚拟线程，绑定任务、续体和调度器
    VirtualThread(ThreadGroup group, Runnable task, Scheduler scheduler) {
        super(group, generateThreadName()); // 生成虚拟线程名称
        this.task = task;
        // 绑定续体，指定续体执行逻辑（runContinuation方法）
        this.continuation = new Continuation(this::runContinuation);
        this.scheduler = scheduler;
    }

    // 虚拟线程执行入口：本质是执行续体
    @Override
    public void run() {
        continuation.run();
    }

    // 续体的执行逻辑：执行任务，完成后清理资源
    private void runContinuation() {
        try {
            task.run(); // 执行用户提交的任务
        } finally {
            afterTask(); // 任务执行完毕后的清理（如标记线程终止）
        }
    }

    // 虚拟线程启动：提交给调度器，而非直接创建内核线程
    @Override
    public void start() {
        if (isAlive()) {
            throw new IllegalThreadStateException("Thread already started");
        }
        scheduler.submit(this); // 交给调度器分配载体线程
    }

    // 虚拟线程挂起：调用续体的yield方法，保存执行状态
    void park() {
        continuation.yield();
    }
}

关键解读（通俗版）：

  • 虚拟线程没有nativeThread字段，不会直接绑定内核线程，所以创建时不涉及系统调用，成本极低；

  • Continuation是核心：相当于“线程状态快照”，能保存虚拟线程的栈帧、局部变量，实现“挂起-恢复”的轻量级切换[superscript:4]；

  • 启动虚拟线程时，不是直接执行，而是提交给Scheduler（调度器），由调度器分配载体线程执行，这是M:N调度的核心。

2.2 核心类2：Continuation——虚拟线程的“状态容器”

Continuation（续体）是虚拟线程实现轻量级挂起/恢复的基石，本质是可暂停、可恢复的计算单元，负责将虚拟线程的执行状态（栈帧）保存到堆内存，而非内核线程栈[superscript:3]。

关键源码（简化版）：

// 续体核心类（JDK内部实现，简化后）
final class Continuation {
    // 续体的执行逻辑（由虚拟线程传入）
    private final Runnable runnable;
    // 续体状态：未执行、运行中、已挂起、已完成
    private volatile State state;
    // 保存虚拟线程的栈帧数据（堆内存中）
    private StackChunk stackChunk;

    // 构造器：绑定执行逻辑
    Continuation(Runnable runnable) {
        this.runnable = runnable;
        this.state = State.NEW;
    }

    // 执行续体：如果是首次执行，直接运行；如果已挂起，恢复执行
    public void run() {
        switch (state) {
            case NEW:
                state = State.RUNNING;
                runnable.run(); // 首次执行，调用虚拟线程的runContinuation
                state = State.DONE;
                break;
            case SUSPENDED:
                state = State.RUNNING;
                restoreStack(); // 恢复之前保存的栈帧状态
                runnable.run(); // 从挂起的地方继续执行
                state = State.DONE;
                break;
            default:
                throw new IllegalStateException("Invalid state: " + state);
        }
    }

    // 挂起续体：保存当前栈帧到堆内存，切换状态
    public void yield() {
        if (state != State.RUNNING) {
            throw new IllegalStateException("Not running");
        }
        saveStack(); // 保存当前栈帧到stackChunk（堆内存）
        state = State.SUSPENDED;
        // 释放载体线程：让载体线程去执行其他虚拟线程
        UnmountedContinuation.unmount(this);
    }

    // 保存栈帧：将载体线程的栈帧复制到堆内存的StackChunk
    private void saveStack() {
        // 核心逻辑：复制当前栈帧数据到堆，细节由JVM底层实现
        this.stackChunk = StackChunk.copyFromCurrentThread();
    }

    // 恢复栈帧：将堆内存中的StackChunk复制回载体线程的栈
    private void restoreStack() {
        StackChunk.copyToCurrentThread(this.stackChunk);
    }

    // 续体状态枚举
    private enum State {
        NEW, RUNNING, SUSPENDED, DONE
    }
}

关键解读：

当虚拟线程执行阻塞操作（比如IO、sleep）时，会调用Continuation.yield()：

  1. 调用saveStack()，将当前虚拟线程的栈帧（方法调用、局部变量）复制到堆内存的StackChunk；

  2. 将续体状态设为SUSPENDED（已挂起）；

  3. 调用UnmountedContinuation.unmount()，将虚拟线程从载体线程上“卸载”，释放载体线程；

  4. 载体线程可以立即去执行其他就绪的虚拟线程，实现资源复用[superscript:5]。

而当阻塞操作完成（比如IO数据到达），续体会被重新提交给调度器，调用restoreStack()恢复栈帧，从挂起的地方继续执行，整个过程完全在JVM用户空间完成，没有内核态切换，开销极低[superscript:4]。

2.3 核心类3：Scheduler——虚拟线程的“调度大脑”

调度器（Scheduler）是实现M:N调度的核心，负责将虚拟线程分配给载体线程（平台线程）执行，JDK默认的调度器是基于ForkJoinPool实现的，支持工作窃取机制[superscript:5]。

关键源码（简化版）：

// 虚拟线程默认调度器（基于ForkJoinPool）
public class VirtualThreadScheduler {
    // 单例调度器，默认并行度=CPU核心数
    private static final ForkJoinPool DEFAULT_SCHEDULER = new ForkJoinPool(
        Runtime.getRuntime().availableProcessors(),
        new CarrierThreadFactory(), // 载体线程工厂，创建载体线程
        null,
        true // 启用异步模式，适配虚拟线程调度
    );

    // 提交虚拟线程到调度器
    public static void submit(VirtualThread virtualThread) {
        DEFAULT_SCHEDULER.execute(() -> {
            // 将虚拟线程挂载到当前载体线程
            MountedContinuation.mount(virtualThread);
            try {
                virtualThread.run(); // 执行虚拟线程
            } finally {
                // 执行完毕，卸载虚拟线程
                MountedContinuation.unmount(virtualThread);
            }
        });
    }

    // 载体线程工厂：创建载体线程（继承自ForkJoinWorkerThread）
    private static class CarrierThreadFactory implements ForkJoinPool.ForkJoinWorkerThreadFactory {
        @Override
        public ForkJoinWorkerThread newThread(ForkJoinPool pool) {
            ForkJoinWorkerThread thread = ForkJoinPool.defaultForkJoinWorkerThreadFactory.newThread(pool);
            thread.setName("carrier-thread-" + thread.getId()); // 载体线程命名
            return thread;
        }
    }
}

关键解读：

  • 默认调度器的并行度=CPU核心数，意味着载体线程的数量默认等于CPU核心数，避免过多载体线程导致的内核切换开销[superscript:4]；

  • 载体线程（CarrierThread）是特殊的ForkJoinWorkerThread，负责执行虚拟线程任务；

  • 调度流程：虚拟线程提交→调度器分配载体线程→虚拟线程挂载到载体线程执行→执行完毕/挂起时卸载→载体线程复用。

三、关键原理：虚拟线程的调度流程（完整梳理）

结合上面的源码，我们用通俗的步骤，梳理虚拟线程从启动到执行、挂起、恢复的完整调度流程，彻底搞懂M:N调度的底层逻辑：

  1. 创建虚拟线程：通过Thread.ofVirtual().start(Runnable task)，本质是创建VirtualThread实例，绑定任务、续体和默认调度器；

  2. 提交任务：调用VirtualThread.start()，将虚拟线程提交给Scheduler（默认ForkJoinPool）；

  3. 挂载执行：调度器从载体线程池中选择一个空闲载体线程，通过MountedContinuation.mount()，将虚拟线程挂载到载体线程，执行虚拟线程的run()方法（本质是执行续体）；

  4. 正常执行/挂起：

    1. 若任务无阻塞，执行完毕，虚拟线程终止，载体线程被释放，继续接收其他虚拟线程；

    2. 若遇到阻塞操作（IO、sleep等），虚拟线程调用Continuation.yield()，保存栈帧到堆，从载体线程卸载，载体线程去执行其他虚拟线程；

  5. 恢复执行：阻塞操作完成后，续体被重新提交到调度器，调度器分配空闲载体线程，恢复栈帧，虚拟线程从挂起处继续执行；

  6. 任务结束：虚拟线程执行完毕，续体状态设为DONE，清理资源，载体线程继续复用。

补充：虚拟线程的“固定（Pinned）”问题——如果虚拟线程在执行synchronized同步块或JNI方法时阻塞，会被固定到载体线程，无法卸载，此时载体线程会被阻塞，暂时失去复用优势，推荐用ReentrantLock替代synchronized[superscript:4]。

四、重点解答：Spring Boot 4.0为什么能原生支持虚拟线程？

搞懂了虚拟线程的源码和调度原理，这个问题就迎刃而解了——Spring Boot 4.0的原生支持，不是“重新实现虚拟线程”，而是「对JDK虚拟线程的深度适配+容器级别的自动化配置」，核心做了3件事，我们结合源码片段来看。

4.1 1. 自动配置：全局启用虚拟线程，无需手动配置

Spring Boot 4.0新增了虚拟线程的自动配置类，通过配置项spring.threads.virtual.enabled=true（默认可自动开启），全局启用虚拟线程，无需手动编写配置类[superscript:2]。

核心自动配置源码（简化版）：

// Spring Boot 4.0 虚拟线程自动配置类
@Configuration
@ConditionalOnClass(VirtualThread.class) // 仅当JDK支持虚拟线程（JDK21+）时生效
@EnableConfigurationProperties(VirtualThreadProperties.class)
public class VirtualThreadAutoConfiguration {

    // 配置虚拟线程调度器（复用JDK默认调度器，可自定义）
    @Bean
    @ConditionalOnMissingBean
    public Scheduler virtualThreadScheduler(VirtualThreadProperties properties) {
        return new VirtualThreadScheduler(
            properties.getNamePrefix(), // 虚拟线程名称前缀，方便日志排查
            properties.getStackSize(), // 虚拟线程初始栈大小，默认4KB
            properties.getParallelism() // 调度器并行度，默认CPU核心数
        );
    }

    // 替换默认的任务执行器，使用虚拟线程
    @Bean
    public TaskExecutor applicationTaskExecutor(Scheduler scheduler) {
        return new VirtualThreadTaskExecutor(scheduler);
    }

    // Web服务器适配：Tomcat、Jetty等自动使用虚拟线程处理请求
    @Bean
    public TomcatProtocolHandlerCustomizer<?> tomcatVirtualThreadCustomizer() {
        return protocolHandler -> {
            // 为Tomcat设置虚拟线程执行器，每个请求对应一个虚拟线程
            protocolHandler.setExecutor(Executors.newVirtualThreadPerTaskExecutor());
        };
    }
}

4.2 2. 容器组件适配：Web请求、异步任务自动用虚拟线程

Spring Boot 4.0对核心组件做了全面适配，无需修改业务代码，就能让虚拟线程落地：

  • Web请求：Tomcat、Jetty等Web服务器，自动使用虚拟线程处理每个HTTP请求，替代传统的线程池（如Tomcat的bio线程池），支持百万级请求并发[superscript:3]；

  • 异步任务：@Async注解自动适配虚拟线程，无需配置TaskExecutor，异步任务会由虚拟线程执行[superscript:2]；

  • 定时任务：@Scheduled注解也支持虚拟线程，定时任务的执行不再占用传统线程池资源。

示例：Spring Boot 4.0中使用虚拟线程（无需额外配置）

// 1. 配置文件开启虚拟线程（可选，默认开启）
# application.yml
spring:
  threads:
    virtual:
      enabled: true
      name-prefix: "biz-virtual-thread-" # 自定义虚拟线程名称
      stack-size: 128k # 按需调整栈大小

// 2. 业务代码：@Async自动使用虚拟线程
@Service
public class OrderService {
    // 无需配置TaskExecutor，自动使用虚拟线程执行
    @Async
    public CompletableFuture<OrderDTO> createOrder(OrderRequest request) {
        // 执行IO密集型任务（如数据库查询、接口调用）
        UserDTO user = userFeignClient.getUser(request.getUserId());
        InventoryDTO inventory = inventoryService.checkStock(request.getProductId());
        return CompletableFuture.completedFuture(buildOrder(user, inventory));
    }
}

4.3 3. 无侵入设计：兼容传统线程，平滑迁移

Spring Boot 4.0的虚拟线程支持，采用“兼容式设计”：

  • 如果JDK版本低于21（不支持虚拟线程），自动降级为传统线程池，不影响应用运行；

  • 如果需要部分任务使用传统线程，可通过@Qualifier指定传统线程池，灵活切换；

  • 业务代码完全无需修改，只需升级Spring Boot 4.0+JDK 21，就能享受虚拟线程的高性能。

五、总结：核心逻辑一句话讲透

1. 虚拟线程的底层：用Continuation保存状态，用Scheduler实现M:N调度，通过“挂载-卸载”机制复用载体线程，避免内核切换，实现轻量级高并发；

2. Spring Boot 4.0的原生支持：通过自动配置，将虚拟线程集成到容器的任务执行、Web请求、定时任务等组件中，实现“零代码侵入”，让开发者无需关注底层调度，直接享受高性能；

3. 适用场景：虚拟线程更适合IO密集型场景（接口调用、数据库、HTTP请求），能最大化利用CPU资源；CPU密集型场景，建议还是用传统线程池（避免虚拟线程频繁挂起恢复的开销）[superscript:5]。

下篇文章，我们将实战Spring Boot 4.0+虚拟线程，结合压测数据，看看虚拟线程到底能提升多少吞吐量，以及避坑指南，记得关注！