JDK 21（JEP 444）落地虚拟线程后，Java 并发编程迎来历史性变革。长期以来，平台线程的固有瓶颈制约了高并发 IO 场景的性能，而虚拟线程以轻量级、用户态调度的核心设计，解决了传统线程模型的痛点，同时保持与现有生态的无缝兼容。

平台线程的固有瓶颈

JDK 21 之前，Java 仅支持平台线程（Platform Thread），它是操作系统原生内核线程的直接封装，Java 线程与 OS 线程一一绑定，线程的创建、销毁、调度均由操作系统全权管控。

平台线程的设计特性，是高并发场景的天生短板，使其在高并发场景存在三大核心局限：

资源开销高昂：默认栈大小较大（64 位 JVM 通常为 1MB，可通过 -Xss 调整），但创建时即固定分配、无法动态伸缩；数千个线程即可引发内存压力；操作系统对内核线程总数有硬性限制，难以支撑十万、百万级并发。
调度成本巨大：线程创建、销毁及上下文切换需从用户态陷入内核态，开销为纯用户态操作的数倍，高并发下成为性能瓶颈。
扩展性不足：线程数远超 CPU 核心数时，内核频繁切换线程，大量吞噬 CPU 资源，导致吞吐量下降、系统卡顿。

以 Tomcat 为例：HTTP 请求属典型 IO 密集型（90%+ 时间等待 DB、Redis、第三方接口），CPU 长期空闲。Tomcat 默认线程池大小为 200，是权衡结果——线程过少浪费 CPU，过多引发频繁内核切换。这种基于线程池的并发管理，本质是用有限线程模拟并发，未高效利用硬件资源，成为高并发瓶颈。

Java 虚拟线程

JDK 21 引入虚拟线程（Virtual Thread） —— JVM 自主管理的用户态线程，不直接绑定操作系统线程，依托少量平台线程（载体线程 / Carrier Thread）运行，专为 IO 密集型高并发场景设计。

虚拟线程与平台线程设计差异显著，其特性为：

极致轻量：栈内存基于堆动态伸缩（初始仅数百字节），单机轻松创建百万级实例，突破内存与线程数限制。
载体线程复用：大量虚拟线程分时复用少量载体线程；阻塞时 JVM 自动卸载，载体线程立即调度其他就绪虚拟线程，最大化 CPU 利用率。
阻塞自动挂起：调用 sleep、网络/文件 IO、JDK 适配的锁等阻塞 API 时，JVM 在用户态完成挂起与恢复，规避内核调度开销。
API 完全兼容：实现 Thread 接口，与现有线程、锁、并发工具兼容，仅需调整线程创建方式即可迁移。

虚拟线程采用隐式协作式调度（阻塞点驱动）：

操作系统内核一般是抢占式调度，Java 平台线程直接由 OS 内核调度，也采用抢占式调度；传统协作式调度要求线程主动调用 API 让出 CPU；
Java 虚拟线程属于隐式协作式调度，核心是阻塞点驱动调度，由 JVM 基于预设阻塞点自动触发调度切换，无需开发者手动干预。

虚拟线程默认使用 JVM 专属独立 ForkJoinPool 调度器，默认并行度等于 CPU 核心数，采用工作窃取算法实现负载均衡。执行至阻塞点时，JVM 挂起虚拟线程并释放载体线程回池；阻塞完成后，虚拟线程重新进入就绪队列，等待分配空闲载体线程恢复执行。

关键边界：若任务无阻塞点（如纯 CPU 死循环），将独占载体线程，导致调度停滞 ——虚拟线程适用于有阻塞点的场景。

阻塞点决定虚拟线程调度行为

阻塞操作是虚拟线程调度切换的核心前提。

示例 1：含阻塞点的虚拟线程。线程中调用 Thread.sleep(1)（JDK 适配的阻塞 API），虚拟线程会主动卸载载体线程，新任务可正常调度执行。

示例 2：无阻塞点的虚拟线程。移除所有阻塞操作，虚拟线程会永久占用载体线程，新任务永远无法获得执行资源。

适用场景与边界警示

虚拟线程是 IO 密集型任务专用方案，并非通用并发工具，仅匹配对应场景才能发挥优势，误用会导致性能退化，推荐使用场景如下：

业务场景	核心优势
Spring Boot/Tomcat Web 服务	单机支撑 10 万 + 并发 HTTP 请求，抛弃线程池大小限制
微服务 RPC 调用链	每个远程调用可分配独立虚拟线程，无池化瓶颈，避免线程池耗尽导致服务降级
数据库/Redis 批量操作	IO 等待时自动释放载体线程，提升资源利用率
消息队列消费者	高吞吐消费消息，降低硬件成本
文件/网络流读写	适配阻塞 IO 模型，简化并发编程逻辑

不推荐场景：

纯 CPU 密集型计算：加密、图像处理、科学计算等，无阻塞点，虚拟线程无法发挥优势，推荐使用 ForkJoinPool。
无阻塞长时循环：持续数值计算、无阻塞监听等，会独占载体线程，阻塞调度池。
虚拟线程池化：创建销毁成本极低，Oracle 强烈不推荐池化，否则违背轻量级设计，增加管理开销。
挂起时持有 synchronized 锁：核心风险为 Pinning（钉住），虚拟线程无法从载体线程卸载，大幅降低并发能力；推荐替换为 ReentrantLock（支持中断与超时，完整适配虚拟线程）。
未适配的 Native 方法阻塞：第三方 Native 方法未适配时，虚拟线程阻塞无法卸载，独占载体线程。

最佳实践

任务类型判断

使用前先确认任务类型：仅对 IO 等待占比高的任务使用虚拟线程，CPU 密集型任务坚决使用平台线程池。

创建启动方式

静态快捷方法，仅支持 Runnable 无返回值任务，适用于轻量级、无需统一管理的异步场景。

public class VirtualThreadQuickStart {
    public static void main(String[] args) {
        // 最简用法：启动虚拟线程执行异步逻辑
        Thread.startVirtualThread(() -> {
            System.out.println("虚拟线程执行任务，线程名称：" + Thread.currentThread().getName());
        });

        // 主线程休眠，等待虚拟线程执行完成（演示用）
        try {
            Thread.sleep(1000);
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        }
    }
}

手动获取 Thread 对象，实现线程命名、中断等精细化控制：

public class ManualVirtualThreadDemo {
    public static void main(String[] args) throws InterruptedException {
        // 1. 构建虚拟线程构建器，创建未启动的线程对象，手动持有Thread实例
        Thread virtualThread = Thread.ofVirtual()
		        .name("combine-vt")
                .unstarted(() -> {
                    System.out.println("手动虚拟线程执行中，线程名：" + Thread.currentThread().getName());
                    try {
                        Thread.sleep(1000);
                    } catch (InterruptedException e) {
                        Thread.currentThread().interrupt();
                        System.out.println("虚拟线程被中断，退出执行");
                    }
                });

        // 2. 手动调用start()方法启动线程
        virtualThread.start();
        System.out.println("主线程已启动虚拟线程，线程ID：" + virtualThread.threadId());

        // 主线程等待子线程执行完毕
        virtualThread.join();
        System.out.println("虚拟线程执行完成，程序退出");
    }
}

使用 Executors.newVirtualThreadPerTaskExecutor()，支持任务管理、返回值、批量操作、优雅关闭，基础用法：

public class ExecutorBasicUse {
    public static void main(String[] args) throws InterruptedException {
        // 提交Runnable任务，无返回值
        VirtualThreadExecutor.EXECUTOR.execute(() -> {
            System.out.println("execute提交无返回值任务，线程：" + Thread.currentThread().getName());
        });

        Thread.sleep(1000);
    }
}

结构化并发

单一阻塞任务可直接使用虚拟线程；若存在并发子任务，推荐使用结构化并发。
StructuredTaskScope 提供了线程生命周期的统一管理能力，支持异常自动传播、任务批量控制，解决传统线程泄漏、异常丢失问题，是虚拟线程的最佳搭档。

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

/**
 * 全局虚拟线程执行器（生产单例使用）
 */
public class VirtualThreadExecutor {
    public static final ExecutorService EXECUTOR = Executors.newVirtualThreadPerTaskExecutor();
}

业务代码：

@Override
public void channelRead0(ChannelHandlerContext ctx, TextWebSocketFrame frame) {
    String content = frame.text();
    MessageDTO message = JSON.parseObject(content, MessageDTO.class);

    // 关键：将结构化作用域整体提交到虚拟线程，不阻塞Netty IO线程
    VirtualThreadExecutor.EXECUTOR.execute(() -> {
        // ShutdownOnFailure：任一子任务失败，自动取消所有子任务
        try (var scope = new StructuredTaskScope.ShutdownOnFailure()) {

            // 1. fork 并发子任务：多DB操作并行执行，提升吞吐量
            var saveMsgTask = scope.fork(() -> messageMapper.insert(message));
            var updateSessionTask = scope.fork(() -> sessionMapper.updateLastMsg(message));
            var incrUnreadTask = scope.fork(() -> unreadMapper.incrementCount(message.getToId()));

            // 2. 等待所有任务执行/取消，此阻塞仅在虚拟线程内，不影响Netty
            scope.join();
            // 3. 任一任务失败，直接抛出异常，中断业务流程
            scope.throwIfFailed();

            // 4. 所有任务成功，异步推送响应
            ctx.writeAndFlush(new TextWebSocketFrame("消息处理完成"));

        } catch (Exception e) {
            log.error("消息批量处理失败", e);
            ctx.writeAndFlush(new TextWebSocketFrame("服务异常，消息处理失败"));
        }
    });
}

规避 ThreadLocal 滥用

虚拟线程可创建百万级实例，ThreadLocal 会为每个线程绑定独立数据，极易引发内存泄漏。优先使用 ScopedValue（JDK 21+）替代，适用于作用域内不可变数据传递；兼容旧代码时可谨慎使用 ThreadLocal，避免大规模实例绑定。

监控载体线程池

虚拟线程使用独立调度池，生产环境需监控线程池饱和度、任务排队情况、Pinning 事件，及时发现载体线程独占等问题。

专属调度池核心配置与 JVM 参数：

参数项	默认值	说明
并行度（parallelism）	CPU 核心数	池内活跃载体线程的最大数量，决定并发执行虚拟线程的平台线程上限
线程工厂	JDK 内置默认工厂	创建守护线程 / 非守护线程，托管载体线程生命周期
拒绝策略	采用内部静默处理	极端情况下的任务溢出处理，虚拟线程场景下极少触发
异步模式（AsyncMode）	`true`	适配事件驱动、IO 型任务，符合虚拟线程调度模型
线程空闲回收	支持	空闲载体线程会自动回收，节约资源

Pinning 是虚拟线程核心性能隐患，指虚拟线程阻塞时无法卸载载体线程的现象：

触发场景：synchronized 同步块、未适配的阻塞 Native 代码、部分反射调用
检测工具：JFR 飞行记录器（jdk.VirtualThreadPinned 事件）、jstack
解决方案：替换 synchronized 为 ReentrantLock、升级第三方库适配虚拟线程

载体线程池的工作策略（补充）

工作窃取算法（Work-Stealing）

工作窃取算法是 ForkJoinPool 载体线程池的任务分配策略：

每个载体线程维护一个双端本地队列，优先消费自己队列的任务；
当自身队列空时，线程会窃取其他线程队列末尾的任务执行，避免 CPU 空闲；
无全局锁竞争：相比 ThreadPoolExecutor 的单队列锁竞争，并发调度效率更高。

该策略完美适配虚拟线程场景：百万级虚拟线程任务可以被均匀分配到所有载体线程，无热点瓶颈。

虚拟线程调度逻辑（挂载 / 卸载）

载体线程池不直接执行业务代码，而是作为虚拟线程的调度载体，配合 JVM 完成用户态调度：

挂载运行：JVM 将就绪的虚拟线程，分配到 commonPool 的空闲载体线程上执行；
阻塞卸载（核心特性）：当虚拟线程执行到 JDK 适配的阻塞点（sleep、JDBC 查询、Netty IO、锁等待等），JVM 会自动将虚拟线程从载体线程卸载；
线程复用：载体线程立刻释放，回到线程池，调度其他就绪的虚拟线程；
恢复执行：阻塞操作完成后，虚拟线程重新进入任务队列，等待分配载体线程继续运行。

任务队列机制

本地双端队列：每个载体线程私有，无多线程竞争，写入 / 读取效率极高；
共享队列：全局备用队列，用于承载无法分配到本地队列的虚拟线程任务；
任务提交模式：虚拟线程的调度任务采用异步提交，不阻塞提交方。

线程生命周期策略

惰性创建：载体线程不会提前全部创建，按需启动，降低启动开销；
空闲销毁：载体线程空闲一段时间后，会被 JVM 自动回收，仅保留基础并行度数量的线程；
无核心线程 / 非核心线程区分：统一由并行度参数控制上限。

总结

虚拟线程核心：JVM 自主管理的用户态轻量级线程，依托少量载体线程运行，栈动态伸缩、支持百万级实例，采用隐式协作式（阻塞点驱动）调度，API 与现有生态兼容；
调度关键：依赖阻塞点触发调度切换，无阻塞点（如纯 CPU 死循环）会独占载体线程，无法发挥优势；
适用边界：专为 IO 密集型场景设计，避开 CPU 密集、无阻塞长循环、虚拟线程池化等场景，警惕 synchronized 引发的 Pinning 问题；
核心实践：区分任务类型（IO 密集用虚拟线程），巧用结构化并发，规避 ThreadLocal 滥用，监控专属调度池与 Pinning 事件。