提到多核并行计算优化，我第一反应不是“开线程”，而是“先别开线程”。很多开发者拿到一个计算慢的程序，第一件事就是给循环加并行，结果跑出来反而更慢。我自己接手过不少类似任务，踩过一堆坑之后总结出一条经验：多核并行优化不是把代码拆给多个核就完事，而是一个从定位瓶颈、选型、调度、缓存到排查的完整链路。这篇文章就把这条链路从头到尾讲一遍，包含可以直接抄的OpenMP用法、线程数量经验值、矩阵乘法优化案例，以及常见的并行问题排查方式。适合正在用多线程、OpenMP做CPU密集型开发的工程师。
1. 多核并行计算优化前，先搞清楚瓶颈在哪
1.1 不是所有任务都适合并行
并行优化的前提是任务里真的存在可并行的计算量。一个任务能否并行，核心看两点：一是每一步操作之间有没有强依赖，二是计算过程中有没有足够的“独立工作”分给多个核心。
先看依赖关系。串行代码里很常见的是“上一步的输出是下一步的输入”，最典型的就是迭代递推：x[i] = f(x[i-1])，每一步都依赖前一步结果，这种链条无法直接拆分给多个线程。反过来，如果是对一个数组里的每个元素做相同变换，那天然就是并行任务，因为每个元素的计算互不相关。
还有一个非常关键的约束，可以用一个加速比上限公式说明：假设一个任务里串行部分占比为 s，并行部分占比为 1-s，使用 P 个核心时理论加速比上限是1 / (s + (1-s)/P)。当核心数趋于无限时，加速比趋近于1/s。换句话说，就算你有 100 个核，只要串行部分占了 10%，整体加速最多 10 倍。
所以真正做优化前，我习惯先画一张简单的数据依赖图，哪怕只在纸上画，也能看出哪些部分能拆、哪些部分必须串着走。生活里做饭也是这个道理：洗菜、切菜、炒菜可以各找一个人，但“先烧开水再煮面条”这个顺序改不了。画依赖图不是走形式，是为了让你不被“看起来能并行”骗了。
1.2 用Profiler量化瓶颈，别靠猜
明确了可并行性后，第二步是用工具量化热点。我在实际工程里见过太多人凭感觉猜瓶颈，猜得准的很少。优化之前，一定要先跑一遍性能剖析，找到真正花时间的函数和循环。
Linux 下比较顺手的是perf和gprof。perf record直接采集性能事件，能告诉你 CPU 周期花在哪些函数、哪些指令上；gprof更简单，编译时加-pg选项，跑完后会生成每个函数的调用次数和耗时占比。对于并行程序，还可以留意perf stat里的cache-misses、instructions、context-switches等指标。
我举个之前的例子，一个模拟项目里最耗时的函数占了 82% 的运行时间，里面是一个双层循环，外层可以并行，内层是累加操作。看到这个结果后，优化方向一下就明确了：把外层循环拆给多个线程，内层通过归约合并结果。如果不跑 profiler，可能会去优化一个只占 2% 时间的 IO 函数，那纯属浪费时间。
这里有个我的习惯：优化前先记录一个完整的基线，包括耗时、CPU 占用率、cache miss 率。后续每做一次改动，都跑同一个数据集、记录同一组指标，再判断改动是否有效。没有基线的优化，最后往往变成“感觉快了”，而不是“确实快了”。
2. 并行方案怎么选：多进程、多线程还是OpenMP
2.1 进程、线程和线程池的取舍
确定任务可并行后，就要选并行实现方式。我在不同场景下用过多进程、多线程和线程池，它们的适用场景差别非常大。
多进程最大的优点是隔离性强，一个进程崩溃不会把整个任务带崩，比较适合大规模分布式计算中那种“一个任务包跑挂了，重跑一个就行”的场景。缺点是开销大，进程间通信需要序列化或者消息传递，数据量大的时候，通信成本可能直接抵消并行收益。
多线程是 CPU 密集型计算最常用的方式。多个线程共享同一个进程的内存空间，传递数据几乎没有额外序列化成本，特别适合处理大数组、大矩阵这类共享内存数据。缺点是共享内存会带来同步问题，两个线程同时写同一块数据就可能出现数据竞争，这也是并行程序最难调试的地方之一。
线程池是另一种思路。如果任务被拆成成千上万个细小任务，频繁创建销毁线程的开销非常可观。线程池的做法是提前创建固定数量的线程，让它们反复从任务队列里取任务执行。我建议在任务粒度很细、数量很多的场景优先用线程池，而不是每来一批任务就std::thread开一遍。
值得一提的是，OpenMP 本身在底层就会创建线程池。像#pragma omp parallel for多次进入并行区时，线程是复用的，不会每次重新创建，所以它的性能通常比手动频繁开线程稳定很多。
2.2 OpenMP：最快的并行化入口
如果项目主要用 C/C++，想做多核并行优化，OpenMP 是目前最省事的方案，没有之一。它通过编译指令告诉编译器“这段循环我来并行化”，不需要你手动管理线程生命周期。
最基础也最常用的写法是直接给 for 循环加上一句指令：
#pragma omp parallel for for (int i = 0; i < N; ++i) { result[i] = transform(input[i]); }编译时用g++ -O3 -fopenmp，运行时默认使用所有逻辑核心。想手动控制线程数，可以先设置环境变量：
export OMP_NUM_THREADS=8 ./program如果代码里有全局累加这样的操作，不能直接多个线程同时改同一个变量。OpenMP 提供了reduction子句，自动为每个线程做局部累加，最后再归并：
double sum = 0.0; #pragma omp parallel for reduction(+:sum) for (int i = 0; i < N; ++i) { sum += data[i]; }很多新手会手动加critical临界区来保护累加，但临界区本质上是串行执行，性能损失很大。reduction是专门为归约场景设计的，性能好很多。能用reduction解决的事，尽量不要手动加锁。
2.3 线程数量不是越多越好
给多核优化配置线程数，我踩过最多坑的就是盲目遵循“核越多越快”。实际上，线程数并不是越大越好，特别是在 CPU 密集型任务里，线程数超出物理核心数后，不仅没有加速，反而会因为上下文切换和调度开销变慢。
现代 CPU 经常有超线程，系统会报告逻辑核心数量，但一个物理核心同时跑两个逻辑线程时，计算资源是共享的。对于纯计算密集型任务，我一般把线程数设成物理核心数；如果任务里有内存等待、IO 等待，可以适当超出物理核心数，利用等待时间跑更多线程。
另外，不要把所有核心都占满。机器上还有操作系统、后台服务，其他程序也需要 CPU。我通常给系统留出 1 到 2 个核心，尤其是线上服务场景，否则很容易出现“计算程序跑完，但整个机器卡死”的情况。
可以用标准库接口探测硬件并发数，但要注意它返回的通常是逻辑核心数：
unsigned int n = std::thread::hardware_concurrency();实际设置线程数时，我的经验值是：计算密集型任务取物理核心数，混合型任务取逻辑核心数略减，不确定时从 4、8、16 几个档位实测，取最快的一组。不要迷信任何公式，最终以机器上的实测为准。
3. 从能并行到高效并行：调度、缓存和同步细节
3.1 负载均衡：调度策略怎么选
同一个循环里，不同迭代的计算量可能不一样。OpenMP 的schedule子句就是用来决定这些迭代怎么分给线程的，选错了，有的线程忙死，有的线程闲死。
静态调度schedule(static)在进入循环之前就把迭代按块分给每个线程，运行时完全不需要协调，开销最低。它适合每一次迭代耗时都差不多的场景。比如数组元素做同样的数学变换，静态调度就很好。
动态调度schedule(dynamic, chunk)是线程算完一块后去队列里取下一块，能自适应负载不均，但每次取任务都有同步开销。它适合迭代耗时差异很大的场景，比如循环里根据数据内容做不同分支，部分迭代特别重。
引导调度schedule(guided)是动态调度的改进版，开始时块很大，越到后面块越小，兼顾了负载均衡和调度开销。我用下来的体会是：不确定任务分布时，可以先试guided，它通常比盲目动态调度更稳。
一个很典型的例子：对一批图片做处理，有的图片内容复杂需要大量计算，有的图片非常简单。如果用static，很可能一个线程分配到好几张复杂图片，其他线程早做完在等。换成dynamic或guided后，吞吐量能明显提升。记住，并行优化的目标是让所有核心同时结束，而不是让每个核心拿到的数据量相等。
3.2 数据竞争、原子操作与伪共享
多线程同时写同一个变量就是数据竞争，轻则结果错误，重则程序崩溃。最直观的解决方案是加锁，但锁用多了就会退化成串行。原子操作比锁更轻，适合对单个变量做简单修改。
考虑统计次数这种场景：
counter[tid]++;如果多个线程同时加，普通写操作会丢失更新。可以用原子变量解决，但更好的方式通常是让每个线程操作自己的独立变量，最后再归约。这样既没有竞争，也没有同步开销。
比数据竞争更隐蔽的是伪共享。它发生在两个线程写不同的变量，但这两个变量恰好落在同一条 CPU 缓存行上。CPU 保证缓存一致性时会频繁互相通知，导致明明没有数据竞争，性能却大幅下降。下面这个结构如果不注意，就很容易触发伪共享：
struct alignas(64) Counter { int value; }; Counter counters[8];通过alignas(64)让每个计数对象独占一个缓存行，伪共享就能消除。实际工程里，一个线程对应一个独立结果槽位时，一定要检查槽位之间是否在同一个缓存行上。这个坑在矩阵计算、统计直方图这类场景里特别常见，排查起来也更隐蔽，因为结果是对的，只是慢。
3.3 缓存友好性：循环重排和数据布局
多核并行能不能拿到接近线性的加速，很大程度上不取决于 CPU 计算能力，而取决于内存访问模式。CPU 缓存读取速度比内存快一两个数量级，程序如果把数据连续地读进缓存，就能大幅减少等待内存的时间。
一个最经典的例子是矩阵乘法。下面这种三重循环，内层k循环里访问B[k][j]，每次都在跳行，缓存命中率很低：
for (int i = 0; i < M; ++i) for (int j = 0; j < N; ++j) for (int k = 0; k < K; ++k) C[i][j] += A[i][k] * B[k][j];把循环顺序改成i-k-j后，内层循环同时连续访问B[k][j]和C[i][j]，数据访问一下子就变得规则了。等会儿第 4 部分我会用一个完整案例展示这个优化带来的实际加速效果。
数据布局上还有一个常见选择：结构体数组（AoS）和数组结构体（SoA）。比如要处理一批三维点坐标，如果定义成结构体数组：
struct Point { float x, y, z; }; Point points[N];并行遍历所有点的x坐标时，内存里每隔 12 字节才取一个浮点数，缓存利用率极低。如果改成三个独立数组：
float x[N], y[N], z[N];那x数组就是连续内存，遍历时几乎可以跑满内存带宽。我在优化粒子模拟、点云处理这类场景时，仅把 AoS 改成 SoA 就能有非常可观的提升，而且代码逻辑变化不大。
3.4 并行粒度：别在线程里反复开线程
并行化的粒度对性能影响很大。如果每个循环都只在很短的范围内加parallel for，循环本身的启动、同步开销甚至可能超过计算时间。
我的经验是：尽量在最外层循环并行化，内层循环保持串行。这样线程数量稳定，任务划分也简单。比如一个嵌套循环，外层迭代次数不多但内层计算量很大，可以在外层加#pragma omp parallel for，内层交给编译器自动向量化：
#pragma omp parallel for for (int i = 0; i < M; ++i) { for (int j = 0; j < N; ++j) { out[i][j] = compute(in[i][j]); } }如果外层并行后负载明显不均，可以考虑collapse(2)，把两层循环合并成一个更大的迭代空间再分配。但要注意，合并后如果内层访问模式不好，反而会破坏缓存局部性。所以我会分别测试parallel for和collapse(2)，用数据决定用哪种。
另外，避免在并行区域内再嵌套新的并行区域。OpenMP 默认不支持嵌套并行，就算支持，线程数量翻倍后也可能导致竞争和调度开销激增。规范做法是外层负责并行，内层负责计算，而不是每一层都开线程。
4. 实操记录：矩阵乘法从3.1倍优化到7.6倍
4.1 串行基线：先把正确结果跑出来
讲再多理论，不如看一个完整案例。我以矩阵乘法为例，矩阵规模固定为 1024×1024，使用 8 个物理核心。优化的每一步都保持结果正确，再用耗时和加速比说话。
串行版本是经典的三重循环：
void matmul_naive(const std::vector<double>& A, const std::vector<double>& B, std::vector<double>& C, int M, int N, int K) { for (int i = 0; i < M; ++i) { for (int j = 0; j < N; ++j) { double sum = 0.0; for (int k = 0; k < K; ++k) { sum += A[i * K + k] * B[k * N + j]; } C[i * N + j] = sum; } } }编译命令是：
g++ -O3 -fopenmp matmul.cpp -o matmul先用串行版本跑一遍，耗时 85 秒。这个耗时对 1024 矩阵来说看起来很高，但如果不做循环重排，内层访问 B 矩阵时频繁跨行跳变，实际耗时就是这么夸张。更重要的是，先跑串行能得到一份可信结果，后面每次验证并行版本和串行结果一致，这是并行开发里最重要的一步。
4.2 第一轮：直接套OpenMP，为什么只有3倍
最简单的方式是在最外层循环加上#pragma omp parallel for：
#pragma omp parallel for schedule(static) for (int i = 0; i < M; ++i) { for (int j = 0; j < N; ++j) { double sum = 0.0; for (int k = 0; k < K; ++k) { sum += A[i * K + k] * B[k * N + j]; } C[i * N + j] = sum; } }实测耗时降到 27.4 秒，加速比约 3.1 倍。第一反应是：8 个核怎么才 3 倍？原因很简单，并行确实把计算分散到了 8 个核心，但每个核心仍然在重复做 cache miss 严重的 B 矩阵访问。内存总线成了新的瓶颈， CPU 计算单元很多时候在等数据，所以即使 8 个线程同时跑，整体也只能挤出 3 倍多一点的吞吐。
这个阶段踩坑最多的地方是：看到加速比不理想，就开始怀疑线程数不够或调度策略不好，结果换来换去变化不大。真正的问题不在线程数，而在访存模式。这时候要先看内存指标，而不是盲目调线程。
4.3 第二轮：循环重排让访存连续
把内层循环从j-k顺序改成k-j，也就是经典的三重循环i-k-j：
// 先把 C 清零 #pragma omp parallel for for (int i = 0; i < M; ++i) { for (int k = 0; k < K; ++k) { double a = A[i * K + k]; for (int j = 0; j < N; ++j) { C[i * N + j] += a * B[k * N + j]; } } }这个版本里，内层j循环同时连续访问B[k][j]和C[i][j]。A 矩阵的当前元素a可以一直放在寄存器里反复使用，内存读写变得规则很多。
实测耗时降到 16.3 秒，加速比提升到 5.2 倍。注意，这一步没有增加任何线程，只是改变了循环顺序，提升了缓存命中率。很多并行优化到一定程度后，瓶颈不是并行度不够，而是串行程序本身的访存方式太差。把访存优化好了，并行才能真正释放全部能力。
4.4 第三轮：分块计算压榨缓存
循环重排之后继续优化，我做了分块计算。把矩阵切成小块，让一个块能够尽量留在 L2 缓存里，减少反复从内存换入换出的次数：
const int BLOCK = 32; #pragma omp parallel for schedule(static) for (int ib = 0; ib < M; ib += BLOCK) { for (int kb = 0; kb < K; kb += BLOCK) { for (int jb = 0; jb < N; jb += BLOCK) { for (int i = ib; i < ib + BLOCK; ++i) { for (int k = kb; k < kb + BLOCK; ++k) { double a = A[i * K + k]; for (int j = jb; j < jb + BLOCK; ++j) { C[i * N + j] += a * B[k * N + j]; } } } } } }这里的BLOCK=32是我在这台机器上试出来的常用值，太小了缓存块优势不明显，太大了又可能超出 L2 容量，反而增加缓存换入换出。分块之后，数据访问的局部性进一步提升。
这一步耗时降到 11.2 秒，加速比达到 7.6 倍。8 个物理核心能跑到 7.6 倍，已经接近理论线性加速了。整个过程让我印象很深：第一步加 OpenMP 只是“把代码拆开”，真正的加速来自后面的访存优化。优化后的矩阵乘法在并行度、缓存利用和调度开销三方面都比较平衡，所以结果理想。
5. 并行优化常见问题排查与避坑清单
5.1 现象：并行后反而变慢
这是最劝退新手的场景。加了并行比不加还慢，通常有三个原因。
第一，任务粒度太小。如果循环只有几千次迭代，每次迭代又是一次很轻的运算，并行化的线程创建、同步成本会远远大于计算收益。这种情况我通常会加大任务粒度，或者把多个小循环合并成一个大循环后再并行。
第二，线程间频繁同步。如果循环体里有大量critical或原子操作，这些操作本质上会串行化，线程越多竞争越激烈，自然快不起来。优化方向是减少临界区范围，或者改用归约、局部变量。
第三，内存带宽饱和。矩阵乘法第一轮就是这个情况，加了线程之后 CPU 占用率可能很高，但耗时没怎么降，因为内存已经忙不过来。排查时可以用perf stat看cache-misses和内存带宽指标，一旦发现内存瓶颈，应该优先优化访存模式，而不是继续加线程。
5.2 现象：结果时对时错
多线程程序出现偶发性错误，大概率是数据竞争。我第一次写并行归约时就遇到过：同一个全局变量被多个线程同时累加，最后结果每次跑都不一样。
排查思路先看共享变量。容易出错的位置有两类：一类是全局计数、累计求和，另一类是多线程直接写同一块数组区域。如果确认有竞争，最简单的修法是给对应代码段加锁，但更好的做法是让每个线程操作自己的临时副本，最后在主线程统一合并。
Linux 下可以用 ThreadSanitizer 检测数据竞争，编译时加-fsanitize=thread，跑一遍测试就能定位到读写冲突的位置。配合同事偶尔才复现的诡异 bug，用这个工具能省下大量时间。我建议所有并行核心模块在提交前都跑一遍 TSan，这比事后排查轻松太多。
5.3 现象：CPU跑满但耗时没降
CPU 占用接近 100%，耗时却没有按比例下降，通常是缓存和内存层次的问题。八个线程都在拼命访问内存同一个区域，CPU 利用率看上去很高，实际上大部分时间都在等待缓存行同步。
先检查是否存在伪共享。比如两个线程各自维护一个统计变量，变量恰好挨在一起，就会造成缓存行在核心之间频繁“搬家”。解决办法已经说过，用alignas(64)对齐到缓存行边界。
再检查访问模式是否连续。如果线程随机访问大数组，每个线程各自取一块完全不连续的数据，内存带宽会被无谓消耗。理想的数据分块方式是让每个线程访问一段连续内存，这样更利于 CPU 预取和缓存复用。内存带宽是共享资源，所有核心一起争夺时，局部性差的程序会快速耗尽带宽。
5.4 现象：线程数设置不生效
很多人在代码里写死了omp_set_num_threads(8)，运行后发现线程数还是不对。这通常有几个原因。
一是环境变量优先级问题。如果代码里调用了omp_set_num_threads，它一般会覆盖环境变量OMP_NUM_THREADS，但某些并行区域里如果显式指定了num_threads(4)，那又会覆盖代码里之前的设置。排查时先统一一种设置方式。
二是动态调度机制。OpenMP 允许动态调整线程数量，可以通过关闭动态调整来保证设置生效：
omp_set_dynamic(0); omp_set_num_threads(8);三是线程亲和性设置。进程可能被系统绑定在部分核心上，设置 8 个线程也许只会挤在 4 个核上。可以用taskset查看和设置进程的 CPU 亲和性，确保线程真的跑到了预期的物理核心上。
最后再分享一个我自己的习惯：每次做并行优化，我会先保存一个串行版本的正确结果，然后在优化过程中不断对比并行输出。这个习惯救过我很多次，因为并行 bug 往往不是立刻爆出来的，而是在数据量变化时偶尔出现。优化一段，验证一段，记录一次耗时，不要一口气改太多。多核并行优化更像是一个逐步逼近的过程，每改动一个变量，都要能说清楚它改了哪个瓶颈。这样踩过的坑才会真正变成可复用的经验。
