Project Reactor中Parallel Flux与Flux的优势对比及适用场景分析

你给出的两个示例之所以看起来效果相似，是因为场景属于纯非阻塞IO调用（WebClient请求），这种场景下两种实现的性能差异极小，ParallelFlux的核心优势主要体现在非IO密集的处理场景下，具体差异和适用规则如下：

ParallelFlux的核心优势 #

• 更直观可控的并行度与执行顺序保证：普通Flux的flatMap要控制并发数需要手动传入第二个并发参数，且无法保证同批次元素的执行顺序。ParallelFlux调用parallel(int parallelism)方法即可直接指定并行轨道数，每条轨道内的元素会严格按顺序执行，轨道之间完全并行，非常适合需要对同特征元素做顺序保证、不同特征元素并行处理的场景，无需额外编写分组逻辑。
• CPU密集场景下的性能优化：ParallelFlux默认并行度与CPU核心数对齐，处理CPU密集型任务（如数据加密、复杂计算、序列化/反序列化）时，刚好可以打满CPU资源，避免多余的线程上下文切换开销。普通Flux如果不手动控制flatMap并发量，很容易创建超出CPU核心数的处理线程，额外的上下文切换反而会拖慢整体性能。
• 轨道级别的隔离能力：ParallelFlux的每条运行轨道是完全隔离的，你可以为每条轨道单独初始化非线程安全的处理对象（如重型解析器、状态计算器），不需要额外维护线程本地变量或者手动做分组隔离，大幅降低复杂并行流的代码复杂度。

选择ParallelFlux的典型场景 #

• 流处理链路中CPU计算占比高，IO等待占比低的场景，ParallelFlux的性能表现远优于普通Flux的flatMap实现
• 需要同时满足「并行处理」和「部分元素按顺序执行」的需求，比如按用户ID分组，同一个用户的请求按顺序处理，不同用户的请求并行处理的场景
• 需要做并行任务的隔离配置，比如不同轨道使用独立的调度器、独立的状态统计、独立的异常处理逻辑的场景

不推荐使用ParallelFlux的场景 #

纯IO密集型的非阻塞调用场景，比如WebClient请求、非阻塞Redis/数据库调用，这类场景IO等待占比极高，ParallelFlux的优势无法发挥，反而会增加轨道拆分的额外开销，直接使用普通Flux的flatMap控制并发数即可满足需求。

你示例中的两段代码具体写法参考：

WebClient调用方法定义 #

Mono<Response> = webClientCallAPi(..) // 返回Mono的webclient调用方法

普通Flux实现 #

Flux.range(0,100)
    .subscribeOn(Schedulers.boundedElastic())
    .flatMap(i -> webClientCallApi(i))
    .collectToList(); // 或者自行实现订阅逻辑

ParallelFlux实现 #

Flux.range(0,100)
    .parallel()
    .runOn(Schedulers.boundedElastic())
    .flatMap(i -> webClientCallApi(i))
    .sequential()
    .collectToList();

内容的提问来源于stack exchange，提问作者Deekshith Anand