Reactor Core中VirtualThread并行度限制问题解析

在Java 21引入VirtualThread（虚拟线程）后，开发者期望能够利用其轻量级特性实现大规模并发操作。然而，在使用Reactor Core框架时，开发者可能会遇到一个有趣的性能瓶颈现象：当使用基于VirtualThread的Schedulers.boundedElastic()调度器时，并行度似乎被限制在100个虚拟线程。

问题现象

测试代码创建了一个Flux流，通过flatMap操作并行执行多个包含Thread.sleep(1秒)的Mono任务。当任务数量设置为100时，所有任务能在约1秒内完成，符合预期。但当任务数量增加到200时，前100个任务仍能在1秒内完成，而后100个任务却需要约100秒，总耗时约101秒。

根本原因分析

这个问题源于两个关键因素：

1. 默认线程池大小限制：Reactor Core的boundedElastic调度器默认线程池大小为10倍CPU核心数。在大多数现代机器上，这通常意味着100个线程（10核心×10）。这个限制适用于传统线程池和VirtualThread实现。

2. Worker分配策略缺陷：在原始实现中，所有Mono任务被错误地分配到同一个Worker上执行。由于Worker内部采用顺序执行策略（虽然使用VirtualThread，但需要保证任务顺序），导致超出默认线程数的任务无法真正并行执行。

技术细节

VirtualThread虽然轻量，但Reactor Core的调度器实现仍然遵循以下原则：

1. Worker模型：每个Worker负责一组任务的顺序执行，保证任务间的有序性。
2. 线程分配：VirtualThread采用"thread-per-task"模型，但Worker会等待前一个VirtualThread完成后才启动下一个。
3. 配置参数：可以通过系统属性reactor.schedulers.defaultBoundedElasticSize调整默认线程池大小。

解决方案

Reactor Core团队已经修复了Worker分配策略的问题。新版本中：

1. 每个Mono任务会被正确分配到不同的Worker上执行
2. 真正实现了VirtualThread的大规模并发能力
3. 开发者仍需要注意默认线程池大小的配置

最佳实践建议

1. 根据实际需求调整reactor.schedulers.defaultBoundedElasticSize参数
2. 对于IO密集型任务，VirtualThread能显著提升性能
3. 监控实际并发量，避免无限制地创建任务
4. 理解Reactor调度模型与原生VirtualThread特性的交互方式

这个问题展示了即使使用现代并发特性，框架实现细节仍然可能影响最终性能表现。理解底层机制对于充分发挥技术潜力至关重要。