Java 虚拟线程调度器并行度怎么单独配置

可以单独配置。JDK 参考实现提供系统属性 jdk.virtualThreadScheduler.parallelism，它控制虚拟线程调度器可用于承载虚拟线程的平台线程数量；默认值通常等于 JVM 可用处理器数量。把它写在 java 命令的 -jar 之前即可，而且不会修改并行流等功能所使用的 commonPool。

官方资料：https://openjdk.org/jeps/444

问题：这个并行度到底限制了什么

虚拟线程采用 M:N 调度：大量虚拟线程在较少的平台线程上运行。这里的“并行度”是调度器的目标承载能力，不是允许创建的虚拟线程总数。即使并行度设为 8，应用仍然可以创建成千上万个虚拟线程；同一时刻真正执行 Java 代码的虚拟线程会受到承载线程和 CPU 的共同约束。

先给结论：用 JVM 系统属性单独设置

例如希望目标并行度为 8，可以这样启动应用：

# 必须把系统属性放在 -jar 之前，让 JVM 启动阶段读取
java -Djdk.virtualThreadScheduler.parallelism=8 -jar app.jar

如果应用运行在容器中，也可以把同一个参数加入容器的 Java 启动命令。不要把它写成应用参数放到 JAR 文件名后面，否则 JVM 不会把它识别为系统属性。

怎么确认启动参数已经传入

下面的示例先读取系统属性，再提交一组短任务。它主要用于确认参数位置和虚拟线程创建方式；任务完成时间不能替代正式压测，因为操作系统调度、JIT 预热和任务类型都会影响结果。

import java.time.Duration;
import java.util.ArrayList;
import java.util.concurrent.Executors;
import java.util.concurrent.Future;

public class VirtualThreadParallelismDemo {
    public static void main(String[] args) throws Exception {
        // 读取 JVM 启动参数；未设置时显示 default，实际默认值由 JDK 决定
        String configured = System.getProperty(
                "jdk.virtualThreadScheduler.parallelism", "default");
        System.out.println("configured parallelism = " + configured);

        var futures = new ArrayList>();
        try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
            for (int i = 0; i  {
                    // 用阻塞等待模拟 I/O；虚拟线程通常会在等待时卸载承载线程
                    Thread.sleep(Duration.ofMillis(200));
                    return "task-" + taskId + " / " + Thread.currentThread();
                }));
            }

            // 显式获取结果，确保演示程序在所有任务完成后再退出
            for (Future future : futures) {
                System.out.println(future.get());
            }
        }
    }
}

编译和运行时仍然把属性放在主类之前：

# 编译示例；JDK 21 起虚拟线程已经正式交付
javac VirtualThreadParallelismDemo.java

# 分别改成 2、4、8 运行，观察配置值并配合业务指标做比较
java -Djdk.virtualThreadScheduler.parallelism=4 VirtualThreadParallelismDemo

常见误区：不要改错 ForkJoinPool

虚拟线程调度器虽然也是一个工作窃取式 ForkJoinPool，但它与并行流使用的 commonPool 是两个不同的池。下面两个参数作用对象不同：

因此，为了调整虚拟线程而修改 commonPool，通常不会得到预期结果，还可能意外改变其他并行任务的行为。

正确做法：按负载性质决定是否调整

CPU 密集任务：不要因为虚拟线程数量多就盲目提高并行度。CPU 核数没有增加，过多承载线程反而可能带来更多调度开销。此类任务先以默认值为基线，再观察 CPU 利用率、吞吐量和延迟。

大量阻塞 I/O：虚拟线程在多数 JDK 阻塞操作中会卸载承载线程，因此默认并行度往往已经足够。只有压测显示队列积压、载体线程长期被占用，且下游资源仍有余量时，才值得尝试逐档提高。

有限下游资源：数据库连接、第三方接口配额或磁盘吞吐才是瓶颈时，应使用连接池、Semaphore 或业务限流控制并发。调度器并行度不是业务并发上限，也不应拿来代替背压。

边界：parallelism 和 maxPoolSize 有什么区别

jdk.virtualThreadScheduler.parallelism 设置目标并行度；jdk.virtualThreadScheduler.maxPoolSize 设置调度器最多可拥有的平台线程数量。某些不能卸载但可补偿的阻塞操作可能促使调度器临时扩展平台线程数量，此时 maxPoolSize 才构成上限。对于固定在承载线程上的情况，JEP 444 明确指出调度器不会通过扩展并行度来补偿，因此简单抬高 maxPoolSize 也不是通用修复方案。

# 同时设置目标并行度与可扩展的平台线程上限；数值必须结合压测决定
java -Djdk.virtualThreadScheduler.parallelism=8 \
     -Djdk.virtualThreadScheduler.maxPoolSize=64 \
     -jar app.jar

JDK 24 以后能不能运行时修改

可以，但要区分版本能力。Oracle JDK 24 API 提供 VirtualThreadSchedulerMXBean，可读取并动态修改目标并行度。若应用需要兼容 JDK 21 至 23，仍应把启动属性作为通用方案；如果明确部署在 JDK 24 及以上，再考虑通过 JMX 管理接口做运行时调整，并为变更设置监控和回退策略。

一张表记住配置判断

延伸问题

并行度设得越大，吞吐量一定越高吗？

不一定。CPU 密集任务可能因上下文切换增加而变慢，I/O 密集任务也可能先撞上数据库连接数、远端限流或带宽瓶颈。应以默认值为基线，用相同流量模型逐档测试。

配置后需要重启吗？

使用系统属性时需要在 JVM 启动阶段传入，因此修改后要重启进程。JDK 24+ 的 MXBean 属于另一条动态管理路径。

这个参数会限制虚拟线程的创建数量吗？

不会。它限制的是调度器目标承载并行度，而不是虚拟线程实例数量。需要限制业务并发时应单独使用并发控制工具。