说起来有点不好意思早年我第一次认真做多核并行计算优化的时候拿一台8核服务器跑了一个多线程程序结果比原来的单线程版本还慢被同事损了一句“多核负优化”。后来慢慢摸清门道才发现多核并行优化根本不是把任务扔给多个线程那么简单同步开销、缓存一致性、任务切分、调度亲和性每一层都有坑。这篇文章就结合我自己调过的项目和常见的优化手段把多核并行计算优化这件事拆开揉碎聊一聊适合刚接触多线程编程的人、已经在写并行程序但性能上不去的人以及正在排查线上服务CPU大量浪费的运维和后台开发者。先把最重要的一句话放在前面多核优化的核心目标不是“让所有核都跑满”而是“在合理投入下让有效计算吞吐最大化”。跑满多核很容易难的是跑满的同时不产生大量无用的同步、空转和缓存抖动。下面从头梳理。1. 先看瓶颈再动手盲目加线程只会更慢1.1 为什么8核机器经常跑不满8倍性能很多人对多核并行第一个认知误区是“核越多线性越快”。第一批次学到Amdahl定律之后才明白程序的加速比上限取决于串行部分的比例。公式很简单加速比 1 / ((1 - 可并行比例) 可并行比例 / 核心数)。如果一个程序只有80%的代码能并行在8核机器上理论最高加速比只有1/(0.20.8/8)3.33倍并不是8倍。剩下来的20%串行部分比如初始化、合并结果、临界区、IO等待都会直接把上限压下来。所以拿到一个多核优化任务第一件事不是开线程池而是先找串行瓶颈在哪。我常用的方法是先跑一遍性能分析看各个核的使用状况再结合火焰图看函数的调用栈和CPU消耗。如果发现所有核都在忙转但程序整体耗时没降那大概率不是算力不够而是锁竞争、内存带宽瓶颈或者伪共享false sharing在捣乱。这些问题后续会逐个展开。1.2 性能画像工具与使用姿势工具方面Linux下我一般从这几件开始top或htop先看整体CPU使用率、平均负载、上下文切换次数。mpstat -P ALL 1观察每个物理核/逻辑核的使用率是否均衡。如果一个核跑满、其他核闲着基本可以断定并行度不够或者任务分配不均匀。pidstat -t -p pid 1看进程内各线程的CPU占用确认是某个线程拖后腿还是整体分散。perf top/perf record粗粒度看函数热点找到消耗CPU最高的函数。vmstat关注cscontext switches列如果上下文切换非常高说明线程过多、时间片切来切去或者锁等待频繁。有个很实用的经验如果CPU使用率已经接近100%但吞吐并没有上升优先怀疑cs和锁竞争如果CPU使用率只有30%优先怀疑并行任务拆分不够、线程都在空等或者串行部分过长。把这些数大概摆出来优化方向基本就清楚了。建议新手千万不要跳过这一步直接写并行代码。我自己早期犯过最蠢的错误是把一个本来就有大量文件锁和日志IO的程序反复改成多线程版本结果越改越慢。后来分析才发现瓶颈在磁盘IO排队上线程再多也改变不了物理设备的吞吐上限。先画像、再优化能省很多无效工作。2. 线程模型选型与参数落地的门道2.1 线程数到底设多少合适线程数不是越大越好。计算密集型任务一般推荐线程数等于物理核心数。注意我说的是物理核心数不是逻辑处理器数。超线程Hyper-Threading提供的逻辑核通常共享物理核的ALU和缓存两个逻辑核都用来跑重计算并不会翻倍反而可能因为资源竞争导致单线程性能下降。所以第一种常见配置是计算密集任务线程池核心线程数设为Runtime.getRuntime().availableProcessors()减去1或直接用物理核数。IO密集型任务则不同因为线程大部分时间在等待网络响应、磁盘读写或者数据库返回CPU本身没跑满。这种情况下可以适当增加线程数经验公式是线程数 CPU核数 × (1 平均等待时间 / 平均计算时间)。举个例子一个线程平均处理请求耗时100毫秒其中计算10毫秒、等待90毫秒那么4核机器大概可以设置4×(190/10)40个线程。这样能让CPU在等待期间转去处理其他请求。2.2 线程池的“潜规则”直接用new Thread一般只在写Demo时能用生产环境要使用线程池。线程池并不仅仅是重复利用线程降低创建开销更重要的是限制并发数、缓冲任务、平滑流量突发。Java里ThreadPoolExecutor有几个关键参数核心线程数、最大线程数、队列容量、拒绝策略。很多人配置时只关注核心数和最大数忽略了队列容量。实际调优时队列的排队能力会直接影响延迟和吞吐。队列用有界队列比如ArrayBlockingQueue可以防止无界排队导致内存爆炸。队列容量大相当于允许积压更多任务但单个任务的响应延迟会变高。队列满了之后是继续增加线程还是直接拒绝取决于业务场景。实时性要求高的系统可以设置较小的队列容量最大线程数适中用合理拒绝策略保护系统不被打垮。C那边没有现成的标准线程池一般用第三方库或者自己封装。我自己的习惯是任务队列用带互斥锁和条件变量的std::queue再配合std::atomicsize_t记录任务数避免频繁加锁查大小。如果任务粒度非常小可以考虑无锁队列但无锁队列的ABA问题、内存序问题很容易踩坑没有充分把握先用锁没错。2.3 任务粒度别把大任务拆太碎并行优化的一个关键指标是“任务粒度”。拆得太粗可能核数利用率不足拆得太细线程同步、任务分发、缓存污染的开销可能超过计算收益。我一般会按工作量来估算单块任务的计算时间至少应该在几十微秒以上否则并行化的收益会被开销吃掉。比如一个简单循环里只有少量加法这时为了并行而给每个迭代单独分配任务纯粹是负优化。更合理的做法是“分段分治”把数据切成核心数×N块N通常取2到8让每个线程处理一块。这样既保证了均衡性又不会因为块数太多带来调度开销。对于负载不均衡的场景比如处理稀疏数据或大小不一的文件可以考虑工作窃取work stealing算法让先完成的线程帮忙“偷”其他线程的剩余任务。3. 任务分解与算法层面的并行化思路3.1 数据并行 vs 任务并行算法设计上优先选择数据并行而不是任务并行。数据并行是把同一份数据切成不同的区块每个线程处理一部分最后合并结果任务并行是把不同功能模块分给不同线程。数据并行的好处是缓存友好、同步点少适合绝大多数数值计算、图像处理、数据筛选等场景。一个很经典的例子是数组求和。如果把整个数组用一个共享累加变量每次累加都加锁性能会差到令人崩溃。正确做法是每个线程先算自己的局部和全部算完之后再一次性合并局部和。这其实就是规约reduction的思想。归并排序、矩阵乘法、MapReduce框架归根到底都是这个套路。任务并行适合子任务之间依赖明确、彼此通信不多的场景比如流水线模块A处理数据交给模块B模块B再交给模块C每级并行的线程各自忙碌。但这类模式下单级拖慢会让整个链路节奏失衡调优时要特别注意各级的缓冲区水位和背压策略。3.2 OpenMP入门实操写C/C时OpenMP是我最喜欢的入门并行方案因为它用指令pragma就能把一个for循环并行起来省去手动建线程的麻烦。一个最简单的例子#include omp.h #include stdio.h int main() { long n 100000000; long sum 0; double start omp_get_wtime(); #pragma omp parallel for schedule(static) reduction(:sum) for (long i 0; i n; i) { sum i; } double end omp_get_wtime(); printf(sum %ld, time %.3f s\n, sum, end - start); return 0; }reduction(:sum)是这里的灵魂它让每个线程维护私有副本最后再用安全的方式合并。如果没有这个子句直接在循环里写sum i就会出现数据竞争结果随机错乱。schedule(static)表示静态分发适合每个迭代计算量差不多的场景如果每个迭代计算量差异很大可以改成schedule(dynamic)让运行时动态分配虽然多了一点调度开销但整体更均衡。编译时要加-fopenmpGCC/Clang或者/openmpMSVC。运行之前可以通过OMP_NUM_THREADS环境变量控制线程数方便做不同配置下的对比实验。3.3 避免伪共享缓存行的原罪伪共享可以说是多核优化里最隐蔽的性能杀手之一。CPU缓存是以缓存行cache line为单位的主流架构上通常是64字节。如果两个线程的变量恰好落在同一个缓存行里即使两个线程每次只改各自不同的字段底层缓存一致性协议也会让一个核更新后使另一个核的缓存行失效导致两个核必须反复从内存重新加载。举个具体例子假设定义了一个结构体struct Counter { long a; long b; };线程0一直写a线程1一直写b。这个结构体很小a和b几乎一定在同一个缓存行里于是两个线程互相拖累性能可能比单线程还差。解决办法非常土但很有用填充padding到64字节对齐或者把变量放入不同缓存行。struct Counter { long a; char padding[64]; // 让b落在不同的缓存行 long b; };实际工程里更优雅的做法是使用alignas(64)或std::hardware_destructive_interference_sizeC17来指定对齐。虽然这类优化让代码显得有点“脏”但在高频热点数据上收益极其显著。我第一次用perf看到缓存命中率只有50%时完全没猜到罪魁祸首是一条缓存行折腾了很久才找到后来把热点变量按线程分区并填充性能直接翻了一倍。如果你们也遇到“多核开了不少但就是快不起来”的情况请务必把伪共享纳入怀疑清单。4. 数据一致性、原子操作与内存同步的细节4.1 从缓存一致性MESI说起多核CPU的每个核心都有自己的L1/L2缓存共享主内存。为了让大家看到的共享数据一致硬件实现了缓存一致性协议主流x86和ARM处理器大多依赖类似MESIModified、Exclusive、Shared、Invalid的机制。简单理解当一个核修改了某个缓存行这个缓存行就会变成Modified其他核如果之前读到了这个缓存行的副本就会被标记为Invalid必须重新从内存获取。这解释了很多多核性能问题的根源共享数据的每一次写操作都可能触发一次跨核的缓存行同步广播。在多核并行程序里无节制的共享可变数据等于让所有核陷入无休止的消息确认。因此从性价比来看最好的“锁”其实就是“尽量别共享”让每个线程拥有独立数据最后再合并。4.2 原子操作与内存序不只是“加减”那么点事C11开始提供了标准原子类型std::atomicT底层会生成对应硬件原子指令比自旋锁更轻量。但原子变量仍然有一个关键概念内存序memory order。很多人只知道atomic本身线程安全却忽略了不同内存序对性能和可见性的影响。拿std::atomicint来说memory_order_relaxed只保证原子性不保证顺序和可见性适合简单计数比如统计次数。memory_order_acquire用于读取场景保证后续的读写不会重排到acquire之前。memory_order_release用于写入场景保证release之前的读写不会重排到release之后。memory_order_seq_cst默认全局顺序一致最强但开销也最大。实际中大量代码只用默认的seq_cst虽然不会出问题但在高频路径上会有不必要的性能损失。比如下面这个计数器如果只需要统计次数使用memory_order_relaxed就够std::atomiclong count{0}; count.fetch_add(1, std::memory_order_relaxed);而典型的“发布-消费”模式则要使用release/acquire配对。比如线程A准备数据后把ready置为true线程B看到ready为true才去读取数据。如果不加合适的内存序线程B可能看到ready为true但数据还没完全写出来程序就翻车了。4.3 双重检查锁与内存屏障的坑写单例模式时很多人会用“双重检查锁”来减少锁开销。但在C/Java早期版本中如果不小心处理可能拿到一个“半初始化”的对象线程A正在构造对象还没有完全构造完成就先把引用赋值给共享指针线程B此时看到指针非空直接使用结果对象内部字段还是默认值。Java里通常用volatile或直接使用enum单例解决。C11之后有个非常省心的方案使用函数局部静态变量。因为C11标准明确规定带动态初始化的局部静态变量初始化是线程安全的且在第一次进入代码块时串行执行。代码看起来像这样Singleton getInstance() { static Singleton instance; // 线程安全 return instance; }这比手写锁、原子和双重检查简单太多而且编译器生成的代码底层就是正确的屏障机制。我把这条列为“能直接用标准库就别自己造锁”的重要范例。现代标准库在并发支持上已经比以前强很多锁、条件变量、原子、线程安全容器都有成熟实现自己实现一次双重检查锁除了学习锻炼在生产里基本都是找坑。4.4 锁的粒度与锁竞争优化如果已经确定不能不共享那就必须认真设计锁的粒度。锁的粒度太粗临界区代码很多并发度极低太细获取锁的次数成倍增加系统开销直线上升。一个常见优化是“读写锁”std::shared_mutex读多写少的场景下比普通互斥锁并发高很多因为多个读者可以同时进入。另外值得尝试的是自旋锁和互斥锁的选择。临界区非常短且临界区内不做复杂操作时自旋锁忙等能避免线程睡眠和唤醒的几百个周期开销临界区长或者可能被阻塞就别使用自旋锁否则多个CPU核都在空转。Linux内核里spin_lock的使用原则可以借鉴到用户态。还有一类优化是通过缩小原子操作范围来减少竞争。比如用fetch_add原子累加来代替“读-改-写”的普通变量加锁这在高并发计数器里很常见。但要注意如果多个原子变量之间有关联性比如“判断余额足够再扣款”原子操作并不能保证整体事务性仍然需要更高级别的锁或事务内存机制。5. 多核调度、中断与CPU亲和性的系统级优化5.1 线程迁移是隐形成本操作系统调度器为了让系统负载均衡会时不时把一个线程从一个核迁移到另一个核。迁移本身有代价被迁移线程在原先核心上缓存的数据全部失效下次访问要重新灌缓存如果涉及NUMA架构还可能导致线程所访问的内存仍然在远端Node延长延迟。如果程序对延迟非常敏感或者某个线程一直在处理同样一组热数据可以考虑把线程绑定到指定CPU核上。Linux里最直接的指令是tasksettaskset -c 2 ./my_parallel_program也可以在代码里调用sched_setaffinity或pthread_setaffinity_np来完成。OpenMP可以通过环境变量OMP_PROC_BINDtrue和OMP_PLACEScores把线程绑定到物理核上。绑核不是无脑做的。如果你绑定的核和别的进程发生资源抢用反而会恶化性能。所以我自己的实践是在高负载环境里观察一段时间后再做绑核测试同时对比taskset前后的延迟分位数和吞吐用数据决定是否保留。5.2 NUMA架构下的内存分配陷阱现代多路服务器基本都是NUMA架构内存控制器分布在各个CPU插槽上每个CPU访问本节点的内存快访问远端节点的内存慢。即使一个线程被绑定到某个核默认内存分配策略也不一定把内存分配到该节点附近。结果就是绑核带来的优化收益被远端内存访问拖掉一大半。调优手段是使用numactlnumactl --localalloc --cpunodebind0 ./my_parallel_program--localalloc让内存尽量在当前线程所在节点分配。如果程序启动时会一次性分配大量内存之后各线程再访问这种策略影响尤其明显。纯编程层面也可以使用mbind或libnuma提供的API手动控制内存页放置。不过对大部分应用来说先用numactl做实验成本最低收益可感知后再考虑代码内置。5.3 中断与软中断均衡处理网络包和磁盘IO时中断会被送达特定CPU。默认情况下很多驱动使用CPU0处理所有中断这时候CPU0会过载而其他核可能很闲。Linux上的irqbalance服务会自动将中断分发给多个CPU但有些场景下它的策略并不是最优的尤其是对延迟要求严格的应用最好手动把网卡队列的IRQ绑定到不同CPU。现代网卡支持多队列RSS/RFS每个队列可以绑定一个CPU核这样不同连接的网络包处理自动分散到多个核降低单个核的软中断压力。查看中断分布可以看/proc/interrupts如果中断几乎全部集中在一个核可以考虑手动调整echo 00000002 /proc/irq/87/smp_affinity假设IRQ是87CPU1的位图是2。这会减少单核瓶颈但需要注意IRQ号在不同系统上可能不同修改前先确认。对大多数普通开发工作来说确保irqbalance开启并保持默认即可除非你已经用top清楚看到某个CPU的软中断占比异常。对实时业务除了中断互斥锁的等待也可能导致优先级反转和调度延迟。但这部分已经进入实时调度的深水区普通多核优化里先做到CPU亲和、中断分散、避免核间反复迁移收益就已经很可观了。6. 实测调优记录与避坑排查6.1 一个并行累加器的调优过程为了把前面提到的思路串起来分享一个我实际做过的基准测试。任务是对一亿个整数求和数据放在int64_t数组里。机器是双路14核服务器超线程开启后显示56个逻辑核。我依次做了四版单线程循环直接求和。多线程版本每个线程用锁保护一个共享累加变量。多线程版本每个线程用std::atomiclong累加。多线程版本每个线程维护独立的局部变量最后再合并局部结果。测试耗时数据大概如下环境不同会有浮动但趋势一致方案耗时毫秒说明单线程约350基线多线程 互斥锁约1800锁竞争严重反而更慢多线程 原子变量约320原子指令有额外开销略好于单线程多线程 局部变量规约约45几乎线性提速缓存友好这个例子完美展示了为什么“用了多核优化”不等于“性能提升”。锁版本差到反直觉忙碌线程全在抢锁原子版本能跑但fetch_add在一个热点缓存行上反复执行依然承担了大量缓存同步开销局部变量版本彻底避开了共享冲突让每个线程完全在私有缓存行上工作最后合并一次整体成本极低。这个结论可以延伸到很多业务场景大量写请求如果都集中在同一个计数对象上再怎么加锁优化都不如干脆分开到不同对象上最后批量汇总。6.2 高频问题排查清单性能没提升甚至下降先看是否存在伪共享、锁竞争、任务粒度过小。用perf record看热点用perf c2c如果内核支持检测伪共享。结果偶尔错误大概率是数据竞争。用线程卫生检测工具C可以试ThreadSanitizer编译时加-fsanitizethreadJava可以用-Xcomp搭配并发测试或者结合代码审查检查共享变量是否缺少同步。死锁确认锁的获取顺序在所有线程中是否一致。用gdb挂到进程后执行thread apply all bt查看线程栈能快速发现互相等待的锁。也可以用lockdep如果在内核态开发。CPU使用率低可能并行度不够IO等待太多或者线程都被阻塞了。用mpstat看整体使用率再用pidstat看具体线程状态。吞吐上不去但CPU满关注内存带宽和缓存失效。高带宽场景比如大矩阵乘法、海量数据扫描很容易撞到内存带宽瓶颈这时候增加线程数反而加剧争用合理做法是减少不必要的数据复制利用分块计算提升缓存命中。6.3 几个越早知道越好的小经验关于多核优化我自己还有一些散装经验一并分享出来。第一业务代码里优先使用无锁数据结构但它们并不是银弹。无锁队列虽然能避免阻塞但会带来复杂的内存序控制排查难度极高团队如果没有足够多的并发高手用带锁版本加合理分区往往更稳。第二做并行优化之前先建立正确性与性能测试基线把“优化前单线程跑多少”“优化后多线程跑多少”“结果是否一致”固化下来只要有一项不符立刻回滚不要带着怀疑继续调。第三压测时千万别只看平均值要关注P99甚至P99.9延迟。多核程序在开关超线程、绑核、内存分配等配置不同时尾延迟表现差别很大。很多时候平均延迟降低了但极端延迟反而更差这在线上往往更致命。所以调优的输出应该是“延迟分布吞吐正确性”三者同时达标而不是单一指标好看。最后再分享一个小技巧当你怀疑多线程程序里的某个热点变量是罪魁祸首最简单的验证方法就是暂时把它改成每个线程独有、最后再归并看看性能变化。如果不降反升那几乎可以断定原来的共享访问是瓶颈。这个方法我屡试不爽比对着汇编猜内存序、反复查缓存一致性协议省力得多。多核并行计算的优化本质上就是一场“减少无谓共享、提升有效局部性”的博弈抓住这个主线很多问题都会自然迎刃而解。
多核并行优化实战：从性能瓶颈排查到锁竞争与伪共享调优
说起来有点不好意思早年我第一次认真做多核并行计算优化的时候拿一台8核服务器跑了一个多线程程序结果比原来的单线程版本还慢被同事损了一句“多核负优化”。后来慢慢摸清门道才发现多核并行优化根本不是把任务扔给多个线程那么简单同步开销、缓存一致性、任务切分、调度亲和性每一层都有坑。这篇文章就结合我自己调过的项目和常见的优化手段把多核并行计算优化这件事拆开揉碎聊一聊适合刚接触多线程编程的人、已经在写并行程序但性能上不去的人以及正在排查线上服务CPU大量浪费的运维和后台开发者。先把最重要的一句话放在前面多核优化的核心目标不是“让所有核都跑满”而是“在合理投入下让有效计算吞吐最大化”。跑满多核很容易难的是跑满的同时不产生大量无用的同步、空转和缓存抖动。下面从头梳理。1. 先看瓶颈再动手盲目加线程只会更慢1.1 为什么8核机器经常跑不满8倍性能很多人对多核并行第一个认知误区是“核越多线性越快”。第一批次学到Amdahl定律之后才明白程序的加速比上限取决于串行部分的比例。公式很简单加速比 1 / ((1 - 可并行比例) 可并行比例 / 核心数)。如果一个程序只有80%的代码能并行在8核机器上理论最高加速比只有1/(0.20.8/8)3.33倍并不是8倍。剩下来的20%串行部分比如初始化、合并结果、临界区、IO等待都会直接把上限压下来。所以拿到一个多核优化任务第一件事不是开线程池而是先找串行瓶颈在哪。我常用的方法是先跑一遍性能分析看各个核的使用状况再结合火焰图看函数的调用栈和CPU消耗。如果发现所有核都在忙转但程序整体耗时没降那大概率不是算力不够而是锁竞争、内存带宽瓶颈或者伪共享false sharing在捣乱。这些问题后续会逐个展开。1.2 性能画像工具与使用姿势工具方面Linux下我一般从这几件开始top或htop先看整体CPU使用率、平均负载、上下文切换次数。mpstat -P ALL 1观察每个物理核/逻辑核的使用率是否均衡。如果一个核跑满、其他核闲着基本可以断定并行度不够或者任务分配不均匀。pidstat -t -p pid 1看进程内各线程的CPU占用确认是某个线程拖后腿还是整体分散。perf top/perf record粗粒度看函数热点找到消耗CPU最高的函数。vmstat关注cscontext switches列如果上下文切换非常高说明线程过多、时间片切来切去或者锁等待频繁。有个很实用的经验如果CPU使用率已经接近100%但吞吐并没有上升优先怀疑cs和锁竞争如果CPU使用率只有30%优先怀疑并行任务拆分不够、线程都在空等或者串行部分过长。把这些数大概摆出来优化方向基本就清楚了。建议新手千万不要跳过这一步直接写并行代码。我自己早期犯过最蠢的错误是把一个本来就有大量文件锁和日志IO的程序反复改成多线程版本结果越改越慢。后来分析才发现瓶颈在磁盘IO排队上线程再多也改变不了物理设备的吞吐上限。先画像、再优化能省很多无效工作。2. 线程模型选型与参数落地的门道2.1 线程数到底设多少合适线程数不是越大越好。计算密集型任务一般推荐线程数等于物理核心数。注意我说的是物理核心数不是逻辑处理器数。超线程Hyper-Threading提供的逻辑核通常共享物理核的ALU和缓存两个逻辑核都用来跑重计算并不会翻倍反而可能因为资源竞争导致单线程性能下降。所以第一种常见配置是计算密集任务线程池核心线程数设为Runtime.getRuntime().availableProcessors()减去1或直接用物理核数。IO密集型任务则不同因为线程大部分时间在等待网络响应、磁盘读写或者数据库返回CPU本身没跑满。这种情况下可以适当增加线程数经验公式是线程数 CPU核数 × (1 平均等待时间 / 平均计算时间)。举个例子一个线程平均处理请求耗时100毫秒其中计算10毫秒、等待90毫秒那么4核机器大概可以设置4×(190/10)40个线程。这样能让CPU在等待期间转去处理其他请求。2.2 线程池的“潜规则”直接用new Thread一般只在写Demo时能用生产环境要使用线程池。线程池并不仅仅是重复利用线程降低创建开销更重要的是限制并发数、缓冲任务、平滑流量突发。Java里ThreadPoolExecutor有几个关键参数核心线程数、最大线程数、队列容量、拒绝策略。很多人配置时只关注核心数和最大数忽略了队列容量。实际调优时队列的排队能力会直接影响延迟和吞吐。队列用有界队列比如ArrayBlockingQueue可以防止无界排队导致内存爆炸。队列容量大相当于允许积压更多任务但单个任务的响应延迟会变高。队列满了之后是继续增加线程还是直接拒绝取决于业务场景。实时性要求高的系统可以设置较小的队列容量最大线程数适中用合理拒绝策略保护系统不被打垮。C那边没有现成的标准线程池一般用第三方库或者自己封装。我自己的习惯是任务队列用带互斥锁和条件变量的std::queue再配合std::atomicsize_t记录任务数避免频繁加锁查大小。如果任务粒度非常小可以考虑无锁队列但无锁队列的ABA问题、内存序问题很容易踩坑没有充分把握先用锁没错。2.3 任务粒度别把大任务拆太碎并行优化的一个关键指标是“任务粒度”。拆得太粗可能核数利用率不足拆得太细线程同步、任务分发、缓存污染的开销可能超过计算收益。我一般会按工作量来估算单块任务的计算时间至少应该在几十微秒以上否则并行化的收益会被开销吃掉。比如一个简单循环里只有少量加法这时为了并行而给每个迭代单独分配任务纯粹是负优化。更合理的做法是“分段分治”把数据切成核心数×N块N通常取2到8让每个线程处理一块。这样既保证了均衡性又不会因为块数太多带来调度开销。对于负载不均衡的场景比如处理稀疏数据或大小不一的文件可以考虑工作窃取work stealing算法让先完成的线程帮忙“偷”其他线程的剩余任务。3. 任务分解与算法层面的并行化思路3.1 数据并行 vs 任务并行算法设计上优先选择数据并行而不是任务并行。数据并行是把同一份数据切成不同的区块每个线程处理一部分最后合并结果任务并行是把不同功能模块分给不同线程。数据并行的好处是缓存友好、同步点少适合绝大多数数值计算、图像处理、数据筛选等场景。一个很经典的例子是数组求和。如果把整个数组用一个共享累加变量每次累加都加锁性能会差到令人崩溃。正确做法是每个线程先算自己的局部和全部算完之后再一次性合并局部和。这其实就是规约reduction的思想。归并排序、矩阵乘法、MapReduce框架归根到底都是这个套路。任务并行适合子任务之间依赖明确、彼此通信不多的场景比如流水线模块A处理数据交给模块B模块B再交给模块C每级并行的线程各自忙碌。但这类模式下单级拖慢会让整个链路节奏失衡调优时要特别注意各级的缓冲区水位和背压策略。3.2 OpenMP入门实操写C/C时OpenMP是我最喜欢的入门并行方案因为它用指令pragma就能把一个for循环并行起来省去手动建线程的麻烦。一个最简单的例子#include omp.h #include stdio.h int main() { long n 100000000; long sum 0; double start omp_get_wtime(); #pragma omp parallel for schedule(static) reduction(:sum) for (long i 0; i n; i) { sum i; } double end omp_get_wtime(); printf(sum %ld, time %.3f s\n, sum, end - start); return 0; }reduction(:sum)是这里的灵魂它让每个线程维护私有副本最后再用安全的方式合并。如果没有这个子句直接在循环里写sum i就会出现数据竞争结果随机错乱。schedule(static)表示静态分发适合每个迭代计算量差不多的场景如果每个迭代计算量差异很大可以改成schedule(dynamic)让运行时动态分配虽然多了一点调度开销但整体更均衡。编译时要加-fopenmpGCC/Clang或者/openmpMSVC。运行之前可以通过OMP_NUM_THREADS环境变量控制线程数方便做不同配置下的对比实验。3.3 避免伪共享缓存行的原罪伪共享可以说是多核优化里最隐蔽的性能杀手之一。CPU缓存是以缓存行cache line为单位的主流架构上通常是64字节。如果两个线程的变量恰好落在同一个缓存行里即使两个线程每次只改各自不同的字段底层缓存一致性协议也会让一个核更新后使另一个核的缓存行失效导致两个核必须反复从内存重新加载。举个具体例子假设定义了一个结构体struct Counter { long a; long b; };线程0一直写a线程1一直写b。这个结构体很小a和b几乎一定在同一个缓存行里于是两个线程互相拖累性能可能比单线程还差。解决办法非常土但很有用填充padding到64字节对齐或者把变量放入不同缓存行。struct Counter { long a; char padding[64]; // 让b落在不同的缓存行 long b; };实际工程里更优雅的做法是使用alignas(64)或std::hardware_destructive_interference_sizeC17来指定对齐。虽然这类优化让代码显得有点“脏”但在高频热点数据上收益极其显著。我第一次用perf看到缓存命中率只有50%时完全没猜到罪魁祸首是一条缓存行折腾了很久才找到后来把热点变量按线程分区并填充性能直接翻了一倍。如果你们也遇到“多核开了不少但就是快不起来”的情况请务必把伪共享纳入怀疑清单。4. 数据一致性、原子操作与内存同步的细节4.1 从缓存一致性MESI说起多核CPU的每个核心都有自己的L1/L2缓存共享主内存。为了让大家看到的共享数据一致硬件实现了缓存一致性协议主流x86和ARM处理器大多依赖类似MESIModified、Exclusive、Shared、Invalid的机制。简单理解当一个核修改了某个缓存行这个缓存行就会变成Modified其他核如果之前读到了这个缓存行的副本就会被标记为Invalid必须重新从内存获取。这解释了很多多核性能问题的根源共享数据的每一次写操作都可能触发一次跨核的缓存行同步广播。在多核并行程序里无节制的共享可变数据等于让所有核陷入无休止的消息确认。因此从性价比来看最好的“锁”其实就是“尽量别共享”让每个线程拥有独立数据最后再合并。4.2 原子操作与内存序不只是“加减”那么点事C11开始提供了标准原子类型std::atomicT底层会生成对应硬件原子指令比自旋锁更轻量。但原子变量仍然有一个关键概念内存序memory order。很多人只知道atomic本身线程安全却忽略了不同内存序对性能和可见性的影响。拿std::atomicint来说memory_order_relaxed只保证原子性不保证顺序和可见性适合简单计数比如统计次数。memory_order_acquire用于读取场景保证后续的读写不会重排到acquire之前。memory_order_release用于写入场景保证release之前的读写不会重排到release之后。memory_order_seq_cst默认全局顺序一致最强但开销也最大。实际中大量代码只用默认的seq_cst虽然不会出问题但在高频路径上会有不必要的性能损失。比如下面这个计数器如果只需要统计次数使用memory_order_relaxed就够std::atomiclong count{0}; count.fetch_add(1, std::memory_order_relaxed);而典型的“发布-消费”模式则要使用release/acquire配对。比如线程A准备数据后把ready置为true线程B看到ready为true才去读取数据。如果不加合适的内存序线程B可能看到ready为true但数据还没完全写出来程序就翻车了。4.3 双重检查锁与内存屏障的坑写单例模式时很多人会用“双重检查锁”来减少锁开销。但在C/Java早期版本中如果不小心处理可能拿到一个“半初始化”的对象线程A正在构造对象还没有完全构造完成就先把引用赋值给共享指针线程B此时看到指针非空直接使用结果对象内部字段还是默认值。Java里通常用volatile或直接使用enum单例解决。C11之后有个非常省心的方案使用函数局部静态变量。因为C11标准明确规定带动态初始化的局部静态变量初始化是线程安全的且在第一次进入代码块时串行执行。代码看起来像这样Singleton getInstance() { static Singleton instance; // 线程安全 return instance; }这比手写锁、原子和双重检查简单太多而且编译器生成的代码底层就是正确的屏障机制。我把这条列为“能直接用标准库就别自己造锁”的重要范例。现代标准库在并发支持上已经比以前强很多锁、条件变量、原子、线程安全容器都有成熟实现自己实现一次双重检查锁除了学习锻炼在生产里基本都是找坑。4.4 锁的粒度与锁竞争优化如果已经确定不能不共享那就必须认真设计锁的粒度。锁的粒度太粗临界区代码很多并发度极低太细获取锁的次数成倍增加系统开销直线上升。一个常见优化是“读写锁”std::shared_mutex读多写少的场景下比普通互斥锁并发高很多因为多个读者可以同时进入。另外值得尝试的是自旋锁和互斥锁的选择。临界区非常短且临界区内不做复杂操作时自旋锁忙等能避免线程睡眠和唤醒的几百个周期开销临界区长或者可能被阻塞就别使用自旋锁否则多个CPU核都在空转。Linux内核里spin_lock的使用原则可以借鉴到用户态。还有一类优化是通过缩小原子操作范围来减少竞争。比如用fetch_add原子累加来代替“读-改-写”的普通变量加锁这在高并发计数器里很常见。但要注意如果多个原子变量之间有关联性比如“判断余额足够再扣款”原子操作并不能保证整体事务性仍然需要更高级别的锁或事务内存机制。5. 多核调度、中断与CPU亲和性的系统级优化5.1 线程迁移是隐形成本操作系统调度器为了让系统负载均衡会时不时把一个线程从一个核迁移到另一个核。迁移本身有代价被迁移线程在原先核心上缓存的数据全部失效下次访问要重新灌缓存如果涉及NUMA架构还可能导致线程所访问的内存仍然在远端Node延长延迟。如果程序对延迟非常敏感或者某个线程一直在处理同样一组热数据可以考虑把线程绑定到指定CPU核上。Linux里最直接的指令是tasksettaskset -c 2 ./my_parallel_program也可以在代码里调用sched_setaffinity或pthread_setaffinity_np来完成。OpenMP可以通过环境变量OMP_PROC_BINDtrue和OMP_PLACEScores把线程绑定到物理核上。绑核不是无脑做的。如果你绑定的核和别的进程发生资源抢用反而会恶化性能。所以我自己的实践是在高负载环境里观察一段时间后再做绑核测试同时对比taskset前后的延迟分位数和吞吐用数据决定是否保留。5.2 NUMA架构下的内存分配陷阱现代多路服务器基本都是NUMA架构内存控制器分布在各个CPU插槽上每个CPU访问本节点的内存快访问远端节点的内存慢。即使一个线程被绑定到某个核默认内存分配策略也不一定把内存分配到该节点附近。结果就是绑核带来的优化收益被远端内存访问拖掉一大半。调优手段是使用numactlnumactl --localalloc --cpunodebind0 ./my_parallel_program--localalloc让内存尽量在当前线程所在节点分配。如果程序启动时会一次性分配大量内存之后各线程再访问这种策略影响尤其明显。纯编程层面也可以使用mbind或libnuma提供的API手动控制内存页放置。不过对大部分应用来说先用numactl做实验成本最低收益可感知后再考虑代码内置。5.3 中断与软中断均衡处理网络包和磁盘IO时中断会被送达特定CPU。默认情况下很多驱动使用CPU0处理所有中断这时候CPU0会过载而其他核可能很闲。Linux上的irqbalance服务会自动将中断分发给多个CPU但有些场景下它的策略并不是最优的尤其是对延迟要求严格的应用最好手动把网卡队列的IRQ绑定到不同CPU。现代网卡支持多队列RSS/RFS每个队列可以绑定一个CPU核这样不同连接的网络包处理自动分散到多个核降低单个核的软中断压力。查看中断分布可以看/proc/interrupts如果中断几乎全部集中在一个核可以考虑手动调整echo 00000002 /proc/irq/87/smp_affinity假设IRQ是87CPU1的位图是2。这会减少单核瓶颈但需要注意IRQ号在不同系统上可能不同修改前先确认。对大多数普通开发工作来说确保irqbalance开启并保持默认即可除非你已经用top清楚看到某个CPU的软中断占比异常。对实时业务除了中断互斥锁的等待也可能导致优先级反转和调度延迟。但这部分已经进入实时调度的深水区普通多核优化里先做到CPU亲和、中断分散、避免核间反复迁移收益就已经很可观了。6. 实测调优记录与避坑排查6.1 一个并行累加器的调优过程为了把前面提到的思路串起来分享一个我实际做过的基准测试。任务是对一亿个整数求和数据放在int64_t数组里。机器是双路14核服务器超线程开启后显示56个逻辑核。我依次做了四版单线程循环直接求和。多线程版本每个线程用锁保护一个共享累加变量。多线程版本每个线程用std::atomiclong累加。多线程版本每个线程维护独立的局部变量最后再合并局部结果。测试耗时数据大概如下环境不同会有浮动但趋势一致方案耗时毫秒说明单线程约350基线多线程 互斥锁约1800锁竞争严重反而更慢多线程 原子变量约320原子指令有额外开销略好于单线程多线程 局部变量规约约45几乎线性提速缓存友好这个例子完美展示了为什么“用了多核优化”不等于“性能提升”。锁版本差到反直觉忙碌线程全在抢锁原子版本能跑但fetch_add在一个热点缓存行上反复执行依然承担了大量缓存同步开销局部变量版本彻底避开了共享冲突让每个线程完全在私有缓存行上工作最后合并一次整体成本极低。这个结论可以延伸到很多业务场景大量写请求如果都集中在同一个计数对象上再怎么加锁优化都不如干脆分开到不同对象上最后批量汇总。6.2 高频问题排查清单性能没提升甚至下降先看是否存在伪共享、锁竞争、任务粒度过小。用perf record看热点用perf c2c如果内核支持检测伪共享。结果偶尔错误大概率是数据竞争。用线程卫生检测工具C可以试ThreadSanitizer编译时加-fsanitizethreadJava可以用-Xcomp搭配并发测试或者结合代码审查检查共享变量是否缺少同步。死锁确认锁的获取顺序在所有线程中是否一致。用gdb挂到进程后执行thread apply all bt查看线程栈能快速发现互相等待的锁。也可以用lockdep如果在内核态开发。CPU使用率低可能并行度不够IO等待太多或者线程都被阻塞了。用mpstat看整体使用率再用pidstat看具体线程状态。吞吐上不去但CPU满关注内存带宽和缓存失效。高带宽场景比如大矩阵乘法、海量数据扫描很容易撞到内存带宽瓶颈这时候增加线程数反而加剧争用合理做法是减少不必要的数据复制利用分块计算提升缓存命中。6.3 几个越早知道越好的小经验关于多核优化我自己还有一些散装经验一并分享出来。第一业务代码里优先使用无锁数据结构但它们并不是银弹。无锁队列虽然能避免阻塞但会带来复杂的内存序控制排查难度极高团队如果没有足够多的并发高手用带锁版本加合理分区往往更稳。第二做并行优化之前先建立正确性与性能测试基线把“优化前单线程跑多少”“优化后多线程跑多少”“结果是否一致”固化下来只要有一项不符立刻回滚不要带着怀疑继续调。第三压测时千万别只看平均值要关注P99甚至P99.9延迟。多核程序在开关超线程、绑核、内存分配等配置不同时尾延迟表现差别很大。很多时候平均延迟降低了但极端延迟反而更差这在线上往往更致命。所以调优的输出应该是“延迟分布吞吐正确性”三者同时达标而不是单一指标好看。最后再分享一个小技巧当你怀疑多线程程序里的某个热点变量是罪魁祸首最简单的验证方法就是暂时把它改成每个线程独有、最后再归并看看性能变化。如果不降反升那几乎可以断定原来的共享访问是瓶颈。这个方法我屡试不爽比对着汇编猜内存序、反复查缓存一致性协议省力得多。多核并行计算的优化本质上就是一场“减少无谓共享、提升有效局部性”的博弈抓住这个主线很多问题都会自然迎刃而解。
