Tokio异步环境中Rayon spawn嵌套并行迭代器性能异常排查

问题根源 #

• Rayon全局线程池嵌套抢占：外层通过rayon::spawn提交的多组数据任务、内层par_bridge生成的并行子任务，都会抢占同一个Rayon全局线程池的计算资源，大量的线程上下文切换开销直接抵消了并行计算的收益，导致所有任务整体耗时翻倍。
• par_bridge额外开销过高：par_bridge本质是对串行迭代器的并行封装，需要额外做元素收集、分块调度，本身开销远高于Rayon原生并行迭代器；同时它的工作窃取效率很低，很容易出现线程负载不均的问题。
• 调度粒度失衡：移除par_bridge后，每个rayon::spawn提交的任务都是单线程运行，数据量大的任务无法拆分到多线程并行计算，自然会出现小任务速度正常、大任务耗时飙升的情况。

优化方案 #

1. 取消两层并行嵌套，统一并行粒度
   放弃外层rayon::spawn+内层par_bridge的两层并行结构，把所有计算单元合并为一层并行任务，避免线程资源抢占，示例伪代码如下：

vec![data1, data2, data3]
    .into_par_iter()
    // 可根据计算单元粒度调整最小分块大小，避免小任务空占线程
    .with_min_len(1024)
    .flat_map(|data| iproduct!(...).map(move |item| (data, item)))
    .for_each(|(data, item)| process(data, item));

2. 优先使用原生并行迭代器，替换par_bridge
   如果iproduct!生成的迭代器可以直接适配Rayon并行迭代器特性，直接移除par_bridge调用；如果确实需要转换串行迭代器为并行，提前对迭代器做固定大小分块后再调用par_bridge，大幅降低调度开销。

3. 适配Tokio异步环境调度规则
   CPU密集型计算任务不要直接运行在Tokio的异步Worker线程上，使用tokio::task::spawn_blocking包裹整个Rayon计算逻辑，避免阻塞Tokio的异步事件循环：

// Tokio异步上下文内提交CPU密集任务
let result = tokio::task::spawn_blocking(move || {
    // 所有Rayon并行计算逻辑放在此处执行
    vec![data1, data2, data3]
        .into_par_iter()
        .for_each(|data| {
            iproduct!(...)
                .for_each(|item| process(data, item))
        });
    result
}).await?;

内容的提问来源于stack exchange，提问作者Daniel Nunes