Java 虚拟线程运行 CPU 密集任务为什么不会自动提速

不会。Java 虚拟线程解决的是“很多任务同时等待时，如何少占用平台线程”，不是“让每个任务获得更多 CPU”。如果任务一直在压缩、加密、排序或计算哈希，虚拟线程仍要和其他线程争用有限的处理器核心；把线程数量继续加大，通常只会增加调度和上下文切换压力。真正适合虚拟线程的是高并发、每个任务大部分时间在等待 I/O 的场景。

把虚拟线程理解成更便宜的并发容器，而不是更快的计算引擎：等待型工作可以交给它，长时间 CPU 计算要放进有界的计算执行器。

先把 CPU 密集和阻塞等待分开

判断是否适合虚拟线程，先看任务的时间花在哪里。调用数据库、HTTP 服务、文件或消息队列时，线程可能长时间等待；这类等待如果能让虚拟线程卸载，少量载体就能承接更多并发。相反，图片编码、密码运算、批量排序和大规模 JSON 计算会持续占用 CPU，虚拟线程不会把一颗核心变成两颗。

因此，“创建一万个虚拟线程”与“同时让一万个计算任务变快”是两件事。前者可以增加在途任务数量，后者仍由处理器核心、算法复杂度和内存带宽决定。

载体线程与调度器决定的是并发容量

虚拟线程由 Java 运行时调度到平台线程上执行，承载它的那条平台线程通常称为 carrier。虚拟线程在阻塞 I/O 时可以从 carrier 上卸载，等 I/O 就绪后再被调度；但正在运行的 CPU 代码仍需要 carrier 和处理器时间。调度器默认并行度与可用处理器数量相关，这就是“线程很多”不等于“计算资源很多”的原因。

用小型任务模型验证并发策略

下面的示例故意把等待和计算写成两类任务。它不是性能基准，而是帮助你确认执行器边界：等待任务可以使用虚拟线程；计算任务仍要限制并发量。

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

public class WorkloadSplit {
    static long cpuWork(int rounds) {
        long value = 1;
        // 计算循环持续占用 CPU，不会因为换成虚拟线程就少算这些轮次。
        for (int i = 0; i  {
                // 模拟外部 I/O；真实项目中这里应放 HTTP、JDBC 等阻塞调用。
                Thread.sleep(Duration.ofMillis(100));
                return "I/O finished";
            });
        }

        int cores = Runtime.getRuntime().availableProcessors();
        try (ExecutorService compute = Executors.newFixedThreadPool(cores)) {
            compute.submit(() -> cpuWork(10_000_000));
        }
    }
}

代码里的关键不是把 `cores` 当成永远正确的调优值，而是保留一个有界计算入口。生产环境还要根据任务耗时、内存占用和下游容量设置队列或信号量，避免请求入口把计算任务无限堆积。

为混合业务选择执行器

如果一个请求先访问数据库，再做短暂计算，通常可以让请求本身运行在虚拟线程；进入 CPU 密集阶段时，把计算提交给独立且有界的平台线程池，完成后再回到请求流程。这样等待资源和计算资源各自有清晰的上限，也便于分别观察排队时间。

排查“虚拟线程没有提速”时，可以按三个问题走：任务是否真的在等待？计算阶段是否超过核心数可承受的并发？是否因为锁、同步代码或下游连接池把等待重新变成了资源争用？先回答这三个问题，再考虑调大线程数。

Java 虚拟线程常见问题

虚拟线程适合 CPU 密集任务吗？

它可以执行这类任务，但不适合作为提速手段。长时间计算仍受核心数限制，通常应使用有界的平台线程池。

把平台线程池改成虚拟线程池就一定更快吗？

不一定。若瓶颈是 CPU、锁、数据库连接数或远端限流，替换执行器不会消除瓶颈，甚至可能增加排队压力。

虚拟线程数量应该设置成 CPU 核心数吗？

不需要。虚拟线程的价值正是承载大量等待型任务；需要接近核心数上限的是 CPU 计算阶段，而不是所有请求线程。

混合任务最容易犯什么错？

把 I/O 并发和 CPU 并发共用一个无限入口。更稳妥的做法是分开执行器，并在计算边界设置队列、信号量或拒绝策略。