并行化提速失败的根源：伪共享与调度优化实战

算法并行化这几年的热度降了不少，原因很现实：多数团队试过 OpenMP 或线程池之后都会想不通，为什么明明每个核都在跑、CPU 占用率看着也高，整体耗时反而比串行版本还难看。我踩过这个坑，后来仔细排查发现，真正拖后腿的往往不是 CPU 的计算能力，而是内存访问冲突和调度优化没做到位。

这篇东西原本是我自己技术整理里的第四部分，所以保留了比较重的实操色彩，内容会围绕算法并行化中的内存访问冲突怎么排查、数据布局怎么调整、线程调度策略怎么选这几个方向展开。适合正在做多线程算法改造的开发者，也适合准备把粒子群、归并排序、动态规划这类逻辑写成并行版本的工程师参考。下面我先从一个最典型的现象说起。

1. 并行化没提速时，先搞清楚卡点藏在哪一层

很多并行代码的改动思路非常统一：把可以拆开的循环加上 #pragma omp parallel for，或者手动丢进线程池，然后觉得任务已经"均匀分发"了。可一旦测出来反而不如单线程，第一反应就是机器核数不够、任务不够大，或者干脆怀疑语言运行时有问题。实际上大部分问题都出在任务被拆开之后，数据依然在共享。

我自己的经验是，并行提速失败的场景可以归为三个方向：

• 数据关联性导致的真竞争：不同线程写同一个地址，或者一个线程写、另一个线程读同一地址。这种问题最容易被发现，因为结果经常是错的，或者会有工具直接报 race。
• 伪共享引发的假竞争：线程写的是不同地址，但这些地址恰好落在同一个缓存行里，导致所有相关核心的缓存反复失效。这种问题结果不会错，程序却慢得很怪异。
• 任务调度本身不匹配：拆分颗粒太碎、线程分配不均、屏障过于频繁，导致大部分时间花在线程同步而不是做计算。

先把这个判断框架摆出来，是因为很多人一上来就陷入"优化锁"或"优化原子操作"的细节里，反而忽略了整体瓶颈。当并行结果莫名其妙变慢时，正确的顺序应该是：先想办法确定读写模式，再分析缓存行级别的冲突，然后才轮到调度参数。

1.1 一次"线程越多反而越慢"的真实测速

前几年做文本统计实验，需要对几百 MB 的字符数组计算每个字符出现次数。最初版本很直白：

cpp复制std::array<uint64_t, 256> freq{0};

#pragma omp parallel for num_threads(8)
for (int64_t i = 0; i < dataSize; ++i) {
    #pragma omp atomic
    ++freq[data[i]];
}

测试机器是常见的 6 核 12 线程桌面 CPU，数据量 512 MB 的随机字节流。单线程跑大约 850 ms，我以为 8 线程至少能跑到 300 ms 左右，结果实测花了 1.4 秒，比单线程慢了 60% 以上。代码逻辑很简单，没有死锁，结果也完全正确，就是慢。

后来我用 perf c2c 和 TSAN 逐步查，才意识到问题有两层：第一层是 freq[data[i]] 这个数组只有 256 个计数器，所有线程都在高频更新同一组内存地址。只要某些字符出现频率高，就会有很多线程同时操作同一个桶，原子操作在内存控制器层面大量重试。第二层更隐蔽，即使线程刚好更新不同的桶，桶与桶之间在内存里连续排列，往往落在同一条 64 字节缓存行里，改一个桶会让别的核心上整条缓存行失效。

这两种因素叠加在一起，多线程不但没有把计算分摊掉，反而制造了大量缓存一致性消息和原子重试流量，慢是很自然的。

1.2 用表格区分三类冲突的典型表现

很多代码问题之所以难排查，是因为现象长得很像：都是 CPU 跑不满，或者加速比很低。我习惯用下面这张表做初筛：

看了这张表，排查思路会清晰很多。先确认结果对不对，再判断是不是性能损失来自缓存协议，最后看任务分配本身是否合理。伪共享这个问题比较特别，代码明明正确，但会让所有后续的并行优化都白做，所以单独拿出来展开。

2. 伪共享：两个线程写不同地址也可能互相拖垮

要理解伪共享，得先明确缓存机制里的一个基本前提：CPU 和内存交换数据不是按单个字节进行的，而是以缓存行为单位。常见 x86 平台缓存行大小是 64 字节。也就是说，即使程序里只修改一个 4 字节 int，CPU 也会把包含这个 int 的整条缓存行加载到本地核心，并最终以缓存行为单位维护一致性。

当两个核心分别持有同一条缓存行的副本，并且其中一方修改了缓存行里的某个字节，缓存一致性协议会让另一个核心里的副本失效。另一个核心再读自己关心的那个字节时，发现缓存行已经失效，只能重新从内存或共享缓存获取。如果双方都在高频写入自己关心的变量，并且这些变量恰好位于同一条缓存行，两个核心就会反复触发对方的失效消息。

我和同事做过一个比喻：这相当于你和室友住在同一个房间，彼此桌子上的东西完全不同，但房间只有一扇需要刷卡才能进出的门。你每次开门拿东西，室友那边的状态就作废，他需要重新刷卡进来。门本身没问题，问题在于两个人被绑定在同一扇门上了。

2.1 一个肉眼很难看出来的伪共享示例

假设想用 4 个线程分别统计 4 个区域的某种特征值，最终结果需要追加到公共数组里：

cpp复制struct Result {
    uint64_t value;
};

std::vector<Result> res(4);

#pragma omp parallel num_threads(4)
{
    int tid = omp_get_thread_num();
    for (int64_t i = tid * chunkSize; i < (tid + 1) * chunkSize; ++i) {
        res[tid].value += compute(data[i]);
    }
}

看起来线程 0 只写 res[0].value，线程 1 只写 res[1].value，完全不存在逻辑层面的竞争。但问题是 std::vector<Result> 会把 4 个 Result 连续排列，每个 Result 只占 8 字节，4 个加起来 32 字节。线程 0 和线程 1 操作的目标很可能落在同一条 64 字节缓存行里，于是线程 0 每更新一次自己的字段，线程 1 所在核心的缓存行副本就被标记失效。

修复这类问题最直接的方法是让每个线程的结构体按缓存行对齐，并且占满至少一个缓存行：

cpp复制struct alignas(64) Result {
    uint64_t value;
    uint8_t padding[56]; // 把结构体撑到 64 字节
};

std::vector<Result> res(4);

C++17 标准库提供了 std::hardware_destructive_interference_size 来获取当前平台的破坏性干扰大小，比自己写死 64 更稳。老项目不方便升级标准时，直接 alignas(64) 也是可以接受的方案。

不过对齐只是治标思路。更彻底的做法是让每个线程维护自己私有的结果对象，最后再做一次归并。这样不仅可以规避伪共享，还能减少一次公共结构体的整体失效风险。

2.2 真共享数据的正确处理：归约优先于加锁

伪共享是隐藏的慢，数据竞争是显性的乱。有些代码干脆给公共数组的每次写入都加锁，结果当然正确，但性能比伪共享还差。因为锁操作会引入内核态或用户态的同步原语，频繁加解锁的代价远超实际计算本身。

处理真正需要共享的数据，常见优先级是这样：能用归约就别用锁，能用原子就别用锁，非用锁不可就尽量缩短临界区。

粒子群算法、模拟退火这类基于种群迭代的算法非常典型。粒子群每一轮都要计算每个粒子的适应度，并更新全局最优解。刚接触并行化的人通常会直接在更新全局最优时加锁：

cpp复制#pragma omp parallel for
for (int i = 0; i < populationSize; ++i) {
    double fit = calcFitness(particles[i]);
    if (fit > globalBestFit) {
        #pragma omp critical
        {
            if (fit > globalBestFit) {
                globalBestFit = fit;
                for (int d = 0; d < dim; ++d) {
                    globalBest[d] = particles[i].pos[d];
                }
            }
        }
    }
}

这段代码能跑，但适应度计算和 critical 区域交错在一起，多线程常常全部堵在入口。而且每次更新最优值时还要拷贝整个维度的数组，临界区很长。

更好的做法是让每个线程只记录自己的局部最优，等本线程负责的所有粒子都算完后，再统一做一次归并扫描：

cpp复制double localBestFit = -inf;
thread_local double localBest[dim];

#pragma omp parallel
{
    // 每个线程独立执行自己的粒子区间
    for (int i = 0; i < populationSize; ++i) {
        double fit = calcFitness(particles[i]);
        if (fit > localBestFit) {
            localBestFit = fit;
            copyPieceOfParticle(localBest, particles[i]);
        }
    }
    
    #pragma omp critical
    {
        if (localBestFit > globalBestFit) {
            globalBestFit = localBestFit;
            copyArray(localBest, globalBest);
        }
    }
}

这个版本把"计算更新"和"共享写入"彻底剥离开。共享写入只发生一轮，一个线程最多进一次临界区，整体性能会好很多。对于需要反复迭代的智能优化算法，这种延迟合并的思路几乎可以通用。

3. 数据布局和访存顺序是触发内存冲突的前置条件

很多人讨论并行化时默认"内存访问冲突"只发生在多线程之间。但从我的实际经验来看，单线程内部糟糕的访存顺序同样会让内存总线高度紧张，等真正多线程并行之后，所有问题会叠加放大。所以并行化改造不能只看线程间关系，还要回头审视每个工作线程访问数据的方式。

3.1 遍历方向决定缓存命中率

二维数组在内存里按行优先存储，这是 C/C++ 的常识。但业务代码里经常出现按列处理的情况：

cpp复制for (int col = 0; col < cols; ++col) {
    for (int row = 0; row < rows; ++row) {
        sum += matrix[row * cols + col];
    }
}

内层循环每次访问的行跨度是整个矩阵的列数，相当于每隔很远才碰一次数据，缓存局部性非常差。如果对这段代码做并行化，每个线程被分配到不同列段，线程之间访问的内存区域重叠交错，情况更糟。

改成行优先遍历，让内层连续访问同一行里的相邻元素，是提升缓存命中率最基础的手段。处理图像数据时，按行切块往往比按列切块容易获得更高加速比，也是这个原因。

另一个常见问题是结构体数组（Array of Structures, AoS）和数组结构体（Structure of Arrays, SoA）的选择。比如三维空间中的粒子更新：

cpp复制struct Particle {
    float x, y, z;
    float vx, vy, vz;
};

std::vector<Particle> particles;

如果循环只是更新每个粒子的位置，AoS 的布局也能经过编译优化获得不错的性能。但如果算法需要频繁遍历所有粒子的 x 坐标，或者需要对某个属性做并行归约，AoS 会导致缓存行里混入大量当前用不到的数据。改成 SoA 后：

cpp复制std::vector<float> px, py, pz;
std::vector<float> vx, vy, vz;

所有粒子的 x 坐标连续存放在一段内存里，遍历时缓存命中率更高。需要注意这不是一个在任何情况下都能胜出的方案，但当你发现并行代码的加速比远低于预期，并且每个线程都在大规模扫描同一组结构体数组时，值得试一下 SoA 改造。

3.2 分块是减少总线冲突的有效策略

对大规模矩阵或多维数据做并行计算时，很多项目直接用一维展开的下标硬切任务。这样做的坏处是：如果每个线程处理的数据块在内存里高度分散，会让整个内存总线上同时存在大量互相穿插的访存请求。

更好的做法是参考矩阵分块乘法里的思路，先把数据按空间邻近性切成若干连续区域，再把连续区域分配给线程。线程 A 只访问地址 1MB 到 2MB 区间，线程 B 只访问地址 2MB 到 3MB 区间，这样至少能降低 CPU 预取器的压力。多数现代内存系统对顺序访问比较友好，对随机跳跃访问则很容易出现带宽利用率下降。

具体切分的时候，可以按以下步骤检查：

• 确认每个线程的任务边界对应的内存地址是否连续。
• 尽量让一个线程顺序处理一个连续的大块，而不是每隔固定大小取一段。
• 检查线程数是否为 2 的倍数以及数据量是否能整除，如果不能整除，要把剩余尾部明确分配给某个线程，避免越界和漏算。
• 如果数据量太大不可能全部放内存，优先考虑按文件或按页面分块流式读入。

3.3 不要在循环内部反复做归约和同步

很多数值算法都需要求全局和、最大值、最小值。如果直接把同步放进内层循环，每算一个元素就尝试更新一次公共变量，即使操作本身是原子的，性能也会被拖垮。正确做法是在每个线程内部先维护局部结果，等整个区间处理完后再统一合并。

cpp复制double localSum = 0.0;

#pragma omp parallel for reduction(+:localSum)
for (int64_t i = 0; i < n; ++i) {
    localSum += compute(data[i]);
}

OpenMP 的 reduction 子句背后做的事情本质上就是给每个线程一个局部副本，最后再按规则合并。自己手动实现时，逻辑也是一样：能晚合并就晚合并，能少碰公共内存就少碰。

4. 调度优化真正的权衡点：任务粒度、分配策略与同步屏障

内存访问冲突解决掉之后，加速比不一定能立刻达到理想状态，因为调度策略本身也会成为瓶颈。不少算法并行化项目把任务等同于"循环拆分"，这是最简单但未必最优的思路。

4.1 最小任务粒度要设下限

关于任务拆得多碎才合适，我的经验判断是：单个任务的实际计算量至少要明显大于创建、调度、同步该线程的平均开销。线程池和 OpenMP 的动态调度都会引入额外的任务获取成本。如果最小任务只包含几十次整数加法，那调度本身的开销可能比执行任务还高，最后并行化带来的是纯负收益。

举个容易理解的例子。某算法核心是一个高频迭代，每次迭代计算量不超过几微秒，而且迭代之间有严格顺序依赖。这种情况下不要强行并行。比较常见的做法是每次迭代内部继续拆成多个计算阶段，然后对不同样本做批量流水线，或者干脆保持串行，只把不相干的多条独立任务流分给不同线程。

判断依据可以简化成这个公式感：串行执行时间 = 实际计算时间；并行执行时间 ≈ 实际计算时间 / 并行度 + 调度开销 + 同步开销 + 负载不均造成的等待。当调度开销和同步开销接近计算时间时，加速比自然趋近于 1 甚至更低。

4.2 静态调度、动态调度和 guided 调度的选择依据

OpenMP 里常见的调度策略有 static、dynamic 和 guided，这类机制在线程池任务队列里也有对应策略，理解背后的决策逻辑比记住 API 更重要。

• static：把循环均匀切块，每个线程固定拿到若干块。优点是启动阶段一次性分配完，执行过程中没有额外的任务搬运和队列争抢，数据缓存局部性最好。缺点是一旦不同块的计算量差异很大，会有明显的长尾问题。
• dynamic：把任务分成较小块，线程空闲时就到公共队列取下一块。优点是天然负载均衡。缺点是队列本身是共享数据结构，如果任务块太小，所有线程会频繁争抢队列，反而制造内存访问冲突。
• guided：一开始分配较大的块，随着执行进度不断减小块大小。它介于 static 和 dynamic 之间，适合任务时间不均匀但有规律可循的场景。

我处理过多段大小不同的日志文件统计，文件数不少于 50，每个文件的行数从几千到几千万不等。所有文件的数据需要合并统计某种模式。如果我用 static 把文件列表平均分配给线程，小文件多的线程会提前结束，大文件多的线程还在处理，整体时间被最大文件所在线程拖住。改成 dynamic，chunk 设为 1 个文件之后，完成时间显著下降，但线程又多了一步任务队列的读写，所以我最终选择了 guided，让队首任务先取较大的文件块，后面剩小文件时负载也比较均匀。

4.3 尽量减少同步屏障的频次

很多迭代算法的经典结构是：并行计算 -> 同步 -> 合并结果 -> 进入下一轮。同步必不可少，但同步的频率和规模可以优化。粒子群、遗传算法里每轮迭代之间的同步看起来无法避免，但其实可以进一步把"全局同步"换成"局部同步"。

比如每个线程负责多个粒子，线程只需要在完成自己负责的所有粒子评估后，跟一个代表节点交流局部最优。整个算法在每一轮可以只做一次跨线程归约，而不是每算完一个粒子就做一次全局同步。这样既能保证下一轮开始时大家都能拿到最新的状态，又能减少大量中间阶段的空转。

当任务之间还存在依赖关系时，更值得注意。A* 算法或基于 DAG 的调度算法里，某些任务必须在某些任务完成后才能开始。如果直接把整张图多层并行展开，经常出现大量线程等待前面层次完成的现象。这种场景下，与其增加线程数，不如先计算出图的关键路径，把关键路径之外可提前执行的任务调度到空闲线程上，并且只对存在数据依赖的部分做点对点同步，而不是每一层都设置全局屏障。

5. 完整实战复盘：文本统计从 1.4 秒优化到接近 4 倍加速

前面把理论和底层机制讲了不少，这一章回到最开始那个失败案例，把完整的排查和调优过程走一遍，方便搭建算法并行化项目时参考。

5.1 第一版的问题分析

原始版本代码如下：

cpp复制std::array<uint64_t, 256> freq{0};

#pragma omp parallel for num_threads(8)
for (int64_t i = 0; i < dataSize; ++i) {
    #pragma omp atomic
    ++freq[data[i]];
}

我在 512 MB 随机 byte 数据上测出来约 1.4 秒，慢于单线程的 850 ms，这本身就能说明问题。通过 perf c2c 观察，缓存行冲突主要发生在 freq 数组的前 64 字节范围内。因为随机字符的频次相对平均，线程之间并不存在特别严重的单桶竞争，真正的性能杀手是伪共享：线程 0 在改 freq[97] 的同时，线程 1 极有可能在改 freq[98]，它们都落在同一条缓存行上，整条缓存行反复失效。

5.2 第二版：私有计数器加统一合并

针对上一版的问题，让每个线程使用自己的私有数组：

cpp复制#pragma omp parallel
{
    uint64_t localFreq[256] = {0};
    int tid = omp_get_thread_num();
    int64_t start = tid * (dataSize / omp_get_num_threads());
    int64_t end = (tid + 1) * (dataSize / omp_get_num_threads());

    for (int64_t i = start; i < end; ++i) {
        ++localFreq[data[i]];
    }

    #pragma omp critical
    {
        for (int c = 0; c < 256; ++c) {
            freq[c] += localFreq[c];
        }
    }
}

这个版本有几个关键点：首先，localFreq 是定义在并行区域内部的局部数组，每个线程都会获得独立副本，并且它们会落在各自线程栈上，不会出现多个线程共享同一条缓存行的伪共享问题。其次，合并 256 个计数器这步放在循环结束后统一做，而且通过 critical 串行完成，避免两个线程同时写同一处 freq[c]。

实测 8 线程版本大约跑到 420 ms 左右。由于单线程是 850 ms，加速比大约是 2 倍，远低于 8 倍，但相比第一版已经有质的提升。为什么没有达到线性加速？主要是内存带宽开销。512 MB 数据需要反复从内存读入，多线程并行读取时内存带宽很快成为瓶颈。这提醒我：当算法整体已经接近内存带宽上限时，加再多线程也不会继续变快。

5.3 第三版：根据负载选择调度方式

为了继续优化调度层，我换了一批测试数据：多个文本文件的总量同样约 512 MB，但各文件大小差异从几百 KB 到 300 MB 不等。此时如果把文件内容追加进同一个大数组再按均匀块切分，会多一次巨大的拷贝开销。我把任务改为按文件名分块，每个任务对应一个文件。

处理每个文件时内部按行解析，文件越大耗时越长。使用 static 调度时，最慢线程可能需处理一个 300MB 的大文件，其他线程处理完小文件后只能干等，总时间明显偏长。改用 schedule(dynamic) 后，每个线程处理完一个文件就去取下一个任务，大文件和小文件之间的负载差异得到缓解，但频繁取任务的队列同步也带来一定开销。

最终我选用 schedule(guided)，效果最理想，整体执行时间约 680 ms。这个场景下的结论是：如果只需要对比调度方式，可以先把本地私有的计数器方案保留不变，单纯改变外层 #pragma omp for schedule(...) 的参数，然后记录每一组耗时。多试几组数据之后，能明显感受到 static 对极端任务分布非常敏感，dynamic 能均衡但任务块不能太小，guided 适合非均匀但可控的任务列表。

5.4 把这些经验迁移到其他算法上

同样的思路不局限于文本统计。在排序算法的并行化里，比如并行归并排序，第一阶段把数据切成多段，各线程分别对段内元素做排序，这个阶段几乎不冲突。但归并阶段如果仍然只有一个线程负责所有归并，瓶颈会非常明显。正确做法是让每个线程先归并自己负责的两个邻接段，然后再做层次化归并。切段时需要注意不要让多个线程同时从同一个输入区域读取并且写入重叠的输出区域，否则内存访问冲突会重新出现。

在图像算法或卷积之类的场景中，边界像素往往需要读取相邻块的数据。如果切块太大，每个线程还要处理边界重叠区，不同线程会读到同一份共享像素。这种读取类型的冲突不会引发数据竞争，但会造成内存带宽浪费。实践中可以先为每个线程分配独立的重叠缓存，或者采用输入端重叠复制的方式，尽量让线程不直接访问别的线程负责的边界数据。

在 A* 这类图搜索算法中，共享 open list 往往是最大瓶颈。线程频繁地从 open list 取出节点、更新路径代价，全局优先队列会成为天然热点。常见优化思路是让每个线程有自己的本地队列，先处理本地任务，当本地队列空时才到全局队列里"偷"一批任务。这样降低了全局队列的争夺频率，但需要注意偷取时任务量的控制，避免某些线程因为任务过大而长期独占全局锁。

6. 以后写并行算法我会先过一遍的检查表

面对新的并行化任务，直接把上面所有方法铺开反而容易乱。我自己总结了一个压缩版检查流程，分享出来供参考。

第一，先检查串行版本是不是已经被内存带宽卡死。如果只是很简单的拷贝操作，开多线程大概率没有收益，这不是代码写得差，而是物理带宽到了上限。这时候不如优化访存密度，比如不再重复读同一份数据。

第二，确认没有隐藏的原子竞争和锁竞争。把高频共享更新的代码改成局部副本加最终归约，是很多算法改造的第一步。若确定必须共享，优先用原子操作，但注意原子操作大量竞争同一个地址时也会有性能损失。

第三，检查数据结构有没有伪共享风险。线程独自维护的计数器、状态标记、中间结果对象，最好用 alignas(64) 对齐或直接分配到线程私有空间。不要在并行区域里让多个线程写一个紧凑的小数组。

第四，用 perf c2c 或 VTune 这类工具看缓存行冲突的分布，而不是靠猜。缓存行冲突和负载不均有时表现类似，都是 CPU 时间被拉长，但工具给出的热点地址能直接告诉你该改结构体布局还是改调度参数。

第五，调度策略不要一上来就动态化。如果任务计算量均匀，static 通常会有更好的缓存局部性。只有确认任务负载差异明显时，才逐步试 dynamic 或 guided。每次调整都记录耗时，最好保留不同版本的性能基线，而不是只靠一次测试下结论。

做并行化优化时，最容易忽略的并不是某个高深的算法理论，而是这些穿插在数据布局、缓存行为和调度