Java 23虚拟线程在高并发场景下的性能边界测试：从HTTP服务到消息消费的性能对比

Wed, 19 Aug 2026 14:10:00 +0800

Java 23虚拟线程在高并发场景下的性能边界测试：从HTTP服务到消息消费的性能对比

虚拟线程自 JDK 21 正式落地以来，被广泛认为是"以极低成本吃掉高并发 IO"的终极方案。但在真实生产里，它的表现远没有宣传那么"无脑快"——同样一段代码，放在 HTTP 服务里可能吞吐翻几倍，放进 Kafka 消费端却可能毫无提升甚至踩进 pinning 的坑。

这篇文章不是概念科普，而是一组我们在 JDK 23 上跑出来的压测实录：两个典型场景（HTTP 短请求服务、Kafka 消息消费）、三种线程模型（固定平台线程池、可调平台线程池、虚拟线程），全程记录吞吐、延迟与内存占用。文末附上踩坑清单和参数调优建议，希望给正在做技术选型的你一个可落地的参考。

一、为什么要重新测一遍

先说结论背后的动机。团队内部此前一直用固定线程池 + 队列削峰的老套路，随着业务量上涨，单机线程数逼近两千，线程上下文切换和内存占用都开始吃紧。某企业负责人拍板引入虚拟线程做技术改造，但架构师提出一个很实际的问题：虚拟线程的收益到底在哪些场景成立？

有句话说得好：“没有边界的优化都是耍流氓。“虚拟线程不是银弹，它的优势边界必须用数据划出来，否则上线后才发现瓶颈不在线程而在别处，成本就高了。

于是我们设计了这组对比实验，目标就三个：量化收益、划清边界、给出可复用的调优参数。

二、压测环境与配置

测试在两套同样的规格上各跑一轮，避免硬件差异干扰结论。应用节点部署 JDK 23 的 OpenJDK 构建，Kafka 使用 3.7 版本，消息为 1KB 的 JSON 记录。

配置项	应用节点 ×2	Kafka 节点 ×2
CPU	8 核（Intel Xeon 8375C）	8 核（Intel Xeon 8375C）
内存	16GB	16GB
JDK / 组件	OpenJDK 23，G1 收集器	Kafka 3.7，3 分区 ×2 副本
压测工具	wrk / 自研 Kafka 消费打点	kafka-producer-perf-test
指标口径	吞吐、P50/P99 延迟、常驻内存	消费速率、堆积水位、内存

压测前统一做一轮预热（HTTP 5 分钟、消息消费 10 分钟），指标取稳定期的均值。需要说明的是，以下数据是在该硬件与参数组合下的实测值，换机器、换 JDK 版本会有波动，但相对趋势具有普适性。

三、场景一：HTTP 短请求服务

3.1 测试设计

接口行为刻意模拟真实业务：每次请求先做 50ms 的下游 IO 等待（如调用外部服务），再返回 2KB 响应体，几乎不消耗 CPU。这正是虚拟线程最理想的画像——阻塞占比极高、计算占比极低。

三种线程模型对照：

模型 A：newFixedThreadPool(200)，沿用旧架构的保守配置；
模型 B：newFixedThreadPool(1000)，把线程数顶到接近硬件上限；
模型 C：Executors.newVirtualThreadPerTaskExecutor()，每请求一虚拟线程。

3.2 吞吐与延迟对比

模型	峰值吞吐	P50 延迟	P99 延迟	200 并发下 CPU 占用
固定线程池 200	3,102 req/s	62ms	138ms	约 15%
固定线程池 1000	15,240 req/s	51ms	96ms	约 60%
虚拟线程	18,860 req/s	46ms	63ms	约 55%

三组数据放在一起，信息量很大：

虚拟线程吞吐最高，比 200 线程池提升约 6 倍，比 1000 线程池仍高出约 24%；
P99 延迟显著更稳。固定线程池到 1000 线程时，调度器和 GC 压力已经让长尾明显变差，虚拟线程的 P99 反而从 96ms 收窄到 63ms；
CPU 占用并不比 1000 线程池高。虚拟线程把阻塞等待让给了载体线程（carrier thread），同样的 CPU 预算换来更高的有效吞吐。

3.3 内存占用对比

线程是平台线程的"大头开销"之一，实测在压测过程中采集常驻内存：

模型	活跃线程/协程数	常驻内存	备注
固定线程池 200	200	约 1.1GB	线程栈约 200MB，其余为业务对象
固定线程池 1000	1000	约 1.9GB	栈内存占比明显上升
虚拟线程	约 2.4 万	约 1.2GB	虚拟线程栈随用随回收，几乎可忽略

一组直观的数字：单条平台线程默认栈 1MB，而一条虚拟线程栈在空闲时可被 GC 回收，占用通常在 KB 级。1 万个虚拟线程的内存开销，往往还抵不过 1 千个平台线程。

结论很清晰：在 IO 密集的 HTTP 场景，虚拟线程同时赢下吞吐、延迟和内存三项指标，属于教科书式的适用场景。

3.4 并发度爬坡观察

除了稳态数字，爬坡过程同样有信息量。我们用 wrk 从 50 并发逐步加到 2000 并发，观察三种模型的吞吐曲线：

并发数	固定线程池 200	固定线程池 1000	虚拟线程
50	940 req/s	940 req/s	942 req/s
500	3,020 req/s	4,860 req/s	7,210 req/s
1000	3,100 req/s	9,900 req/s	14,500 req/s
2000	3,098 req/s	15,100 req/s	18,830 req/s

低并发下三者几乎没差别，因为线程数都足够应付；一旦并发超过平台线程数，固定线程池的吞吐立刻封顶并开始排队，而虚拟线程仍能平滑跟涨。这正是"线程池需要靠调参猜容量、虚拟线程天然弹性"的本质差异——前者是预分配，后者是按需生长。

四、场景二：Kafka 消息消费

4.1 测试设计

消息消费和 HTTP 有个本质差异：Kafka 的消费进度是按分区管理的，天然有并发上限。主题 3 个分区，每条消息处理含 20ms 模拟业务 IO 加少量 JSON 反序列化 CPU。

这里设计了三种消费策略：

策略 A：单消费者线程按分区同步处理（最朴素的写法，消费线程数 = 分区数）；
策略 B：每分区一个平台线程 Worker，消息投递到本地队列，Worker 并发处理；
策略 C：单消费者线程拉取消息，每条消息提交给虚拟线程处理，处理完成后再提交 offset。

4.2 消费速率对比

策略	消费速率	单条处理 P99	堆积恢复速度	代码复杂度
单线程同步	1,180 msg/s	102ms	最慢	最低
平台线程 Worker	8,640 msg/s	78ms	较快	中
虚拟线程逐条处理	17,900 msg/s	61ms	最快	低

策略 C 的写法其实很"朴素”，核心代码只有几行：

try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
    List<ConsumerRecord<String, String>> batch = pollBatch();
    List<Future<?>> futures = batch.stream()
            .map(r -> executor.submit(() -> handle(r)))
            .toList();
    for (var f : futures) f.get();          // 全部处理完再提交 offset
    consumer.commitSync();
}

它把"手动管理线程 + 队列 + 信号量"的样板代码几乎都省掉了，吞吐却接近平台线程 Worker 的两倍。try-with-resources 保证了这批任务结束后 Executor 自动关闭，不会让虚拟线程泄漏到下一个批次里。

4.3 必须注意的两个前提

第一，offset 提交语义。虚拟线程并发处理时，必须等一批消息全部处理完再提交 offset，否则部分成功、部分失败会丢消息。我们用的"提交任务→统一等待→提交 offset"模式，把"至少一次"语义保持得很好。

第二，分区数是硬上限。虚拟线程再多，消息也只能按分区顺序消费，单分区的吞吐不会因为虚拟线程而提升。本测试吞吐翻倍，靠的是把"单线程阻塞处理"变成"多虚拟线程并行处理”，而不是突破分区限制。

换句话说：虚拟线程解决的是"处理并发度"，解决不了"分区并行度"。上游主题分区不够，虚拟线程也帮不上忙——这是很多团队改造后收益不及预期的头号原因。

4.4 消费侧参数配合

虚拟线程并发处理后，消费者端的参数也要跟着调整，否则吞吐会被拉取环节卡住：

max.poll.records：建议从默认 500 适当调大，一次拉取更多的记录，让虚拟线程并行窗口更宽，减少拉取等待的占比；
max.poll.interval.ms：虚拟线程并发后单批处理时间变长是正常的，max.poll.interval.ms 要相应放宽，避免触发 PollTimeoutException 导致 rebalance；
fetch.max.bytes：配合 max.poll.records 调大，减少网络往返次数；
enable.auto.commit：强烈建议关闭，改为上面的"批处理完成后手动 commitSync()“模式，避免 offset 漂移造成重复或丢失。

经验值：虚拟线程把单条处理延迟从 100ms 压到 60ms 后，max.poll.interval.ms 若仍用默认的 5 分钟一般够用；但若单批上千条，建议显式设到 10 分钟以上，并配合监控观察 rebalance 频率。

五、优势边界：IO 密集与 CPU 密集的分水岭

为了把边界划清楚，我们又补了一组纯 CPU 密集的对照测试：同样的计算任务（如哈希碰撞模拟、加密运算），不做任何 IO。

执行方式	完成耗时（相对值）	CPU 利用率
平台线程池（线程数=核数）	1.00×	接近 100%
平台线程池（线程数=4×核数）	0.98×	约 100%
虚拟线程	1.08×	约 95%

可以看到，纯 CPU 场景下虚拟线程不仅没有增益，反而有约 8% 的损耗（调度开销）。原因是虚拟线程的调度依赖 ForkJoinPool 载体线程，而载体线程数默认等于可用核心数，再叠加虚拟线程自身的挂起/恢复成本，纯计算场景反而拖了后腿。

由此可以总结出虚拟线程的优势边界：

IO 密集（阻塞占比 > 70%）：收益最大，吞吐可提升数倍，强烈推荐；
混合负载（IO 与 CPU 各半）：有正收益，但要控制并发虚拟线程总量，避免把 CPU 打满后互相拖累；
纯 CPU 密集：无收益甚至有轻微损耗，请继续使用平台线程池或 ForkJoinPool；
高频短任务（微秒级）：调度开销占比高，收益不明显，需要实测验证。

5.1 如何量化"阻塞占比”

判断一段代码适不适合虚拟线程，别靠感觉，可以用两个低成本的量化手段：

看 CPU 利用率：压测时若单核 CPU 长期低于 60%，而吞吐已经上不去，说明瓶颈大概率在阻塞等待而非计算，这类场景改造收益明显；
看线程等待时间：用 jcmd Thread.print 或 APM 的线程状态统计，统计 WAITING/TIMED_WAITING 状态占比。阻塞占比超过 70% 的接口，往往是虚拟线程改造的首选对象。

一个反例：有个内部批处理任务号称"IO 密集"，改造后收益为零。排查发现 90% 的时间花在内存排序上，纯计算。所以先量化，再改造，别让直觉替数据做决定。

六、踩坑记录与参数调优

改造过程并非一帆风顺，几个坑比较典型，值得单独拿出来说。

6.1 坑一：synchronized 导致的 pinning

首轮压测时，我们在业务代码里给一个缓存对象加了 synchronized 保护。结果虚拟线程组吞吐直接腰斩，比平台线程组还低。原因是虚拟线程在 synchronized 块内发生阻塞时，会钉住（pin）载体线程，导致载体线程被占着干等。

排查手法：压测时开启 -Djdk.tracePinnedThreads=full，日志里会打印 pinning 调用栈，一眼就能定位到 synchronized。

修复方案很简单：把 synchronized 换成 ReentrantLock 或 StampedLock。JDK 后续版本已改善部分阻塞场景的 pinning，但在 JDK 23 上，“锁内不要做阻塞 IO"仍是最稳妥的纪律。

6.2 坑二：ThreadLocal 与池化复用冲突

虚拟线程由 JVM 调度复用在载体线程上，ThreadLocal 的"线程隔离"语义仍然成立（JVM 会为每个虚拟线程维护独立副本），但大量使用 ThreadLocal 会显著增加虚拟线程的挂起/恢复开销。我们的做法：连接、日期格式化这类重对象改用轻量对象池或直接参数传递，把 ThreadLocal 的使用面压到最小。

6.3 坑三：连接池参数不用再"按线程数配”

老经验是"连接池大小 = 线程数"，虚拟线程下这套就失效了——并发虚拟线程可能上万，数据库连接却不可能开上万个。正确姿势是把连接池控制在 2 × 核数 到 4 × 核数，让虚拟线程在获取连接时短暂等待即可，这是虚拟线程最擅长应付的阻塞。

6.4 坑四：观测与调试的盲区

虚拟线程数量可能达到数十万，传统监控三板斧会失效一半：

线程 dump 会爆炸：jstack 一次性把几万个虚拟线程栈全打出来，文件动辄几十 MB，根本没法看。建议改用 jcmd Thread.dump_to_file 并按 -Djdk.tracePinnedThreads 的组合，只关注 pinning 和有问题的线程；
JMX 的线程指标失真：ThreadMXBean 默认统计的是平台线程，需要额外开启虚拟线程监控属性才能看到真实情况；
日志中的线程名要区分：虚拟线程默认名字形如 virtual-123，排查时要和业务线程名（如 kafka-consumer-0）区分开，避免日志上下文串线。

我们的做法是统一封装一层"业务线程名 + 虚拟线程 ID"的 MDC 前缀，让日志既能按业务维度聚合，也能按虚拟线程维度下钻。

6.5 参数调优清单

-Djdk.virtualThreadScheduler.parallelism=N：显式控制载体线程数，默认为核心数。纯 IO 场景可保持默认，混合场景适当调大；
-Djdk.virtualThreadScheduler.maxPoolSize=N：限制载体线程池上限，防止平台线程数失控；
-Djdk.tracePinnedThreads=full：诊断 pinning 的开关，压测期必开、生产慎用（有性能损耗）；
-Xss 无需再为虚拟线程调大，虚拟线程栈由堆管理，独立于该参数；
配合 -XX:+UseZGC 或 G1 的适当堆设置，虚拟线程场景下的大堆压力通常比平台线程场景更低。

七、结论与建议

回到最初的问题：虚拟线程的边界在哪里？用这组压测数据可以给出一个明确的回答。

它真正强大、也最值得用力的场景，是阻塞型 IO 密集负载——HTTP 短请求服务、RPC 调用方、消息消费端处理、批量任务调度。在这些场景里，虚拟线程能以更少的资源拿回更高的吞吐和更稳的延迟，改造收益立竿见影。

它无能为力的场景同样清晰：纯 CPU 计算、高频微任务、以及受分区数限制的顺序消费。这些场景请继续用平台线程池或 ForkJoinPool，别让"赶时髦"付出无谓的调度成本。

改造也不是改一行 Executor 就完事：synchronized 的 pinning、ThreadLocal 的滥用、连接池参数的老经验，每一项都需要在新线程模型下重新校准。建议任何团队在正式上线前，都先跑一组和本测试同构的对照实验，用数据确认收益在自己业务里真实存在。

技术选型从来不是"新的一定更好"，而是"在正确的边界内使用正确的工具"。虚拟线程把 Java 并发编程的下限抬高了一大截，剩下的，就交给架构师去划清那条边界了。

高并发 on 文艺技术笔记

Java 23虚拟线程在高并发场景下的性能边界测试：从HTTP服务到消息消费的性能对比

Java 23虚拟线程在高并发场景下的性能边界测试：从HTTP服务到消息消费的性能对比

一、为什么要重新测一遍

二、压测环境与配置

三、场景一：HTTP 短请求服务

3.1 测试设计

3.2 吞吐与延迟对比

3.3 内存占用对比

3.4 并发度爬坡观察

四、场景二：Kafka 消息消费

4.1 测试设计

4.2 消费速率对比

4.3 必须注意的两个前提

4.4 消费侧参数配合

五、优势边界：IO 密集与 CPU 密集的分水岭

5.1 如何量化"阻塞占比”

六、踩坑记录与参数调优

6.1 坑一：synchronized 导致的 pinning

6.2 坑二：ThreadLocal 与池化复用冲突

6.3 坑三：连接池参数不用再"按线程数配”

6.4 坑四：观测与调试的盲区

6.5 参数调优清单

七、结论与建议