企业官网建设流程全解析

1. 为什么并行计算不是"多开几个线程"这么简单

我见过太多人第一次接触并行计算时的反应：既然一个核跑得慢，那就开八个线程一起跑，速度不就翻八倍了？这个想法很符合直觉，但现实往往很残酷——你写完多线程版本，跑出来比单线程还慢，或者偶尔快偶尔慢，甚至结果偶尔还是错的。我自己第一次写并行程序就是这样，四个线程跑一个求和任务，结果比单线程慢了三倍，当时盯着屏幕怀疑人生。

问题出在哪？并行计算从来不是"把任务切碎丢给多个核心"这么简单。它是一整套关于任务分解、数据划分、通信协调、同步互斥、性能建模的系统工程。你得先想清楚：这个任务到底能不能并行？并行之后各个部分怎么交换数据？交换数据的代价会不会把并行省下来的时间全吃掉？这些问题的答案，决定了你写出来的程序是真正加速，还是白忙一场。

这篇文章我想把并行计算这套东西从头到尾讲透。从并行到底解决什么问题、有哪些常见的并行模型、内存一致性和同步这些容易踩坑的地方、再到实际写代码时怎么评估加速比和扩展性，最后聊聊常见的性能陷阱。适合已经会写基本代码、但对"为什么我的并行程序不加速"一头雾水的读者，也适合想系统补一下计算机系统里这块知识的同学。核心关键词是计算机系统和并行计算，我会尽量用生活化的类比把抽象概念讲清楚，同时保留足够的技术细节让你能真正上手。

先说一个贯穿全文的基本判断：并行计算的本质不是"让多个核心同时干活"，而是"在通信与计算的权衡中找到最优切分方式"。记住这句话，后面所有的内容都是它的展开。

2. 并行计算的两条根本路线：数据并行与任务并行

2.1 从"搬砖"类比理解两种并行

假设你要把一万块砖从A地搬到B地。有两种组织方式：

第一种，你雇十个人，每人负责搬一千块砖，大家各搬各的，互不干扰。这叫数据并行——同一套操作，作用在数据的不同部分上。

第二种，你雇三个人，一个人负责搬砖，一个人负责砌墙，一个人负责搅拌水泥。三个人做的是不同的工序，擅长不同的活。这叫任务并行——把不同的功能模块交给不同的执行单元。

这两种思路是并行计算的两条根本路线。数据并行更常见，因为它的扩展性好：数据量变大，加人就行；任务并行受限于工序数量，你总不能把搬砖再拆成"左手搬"和"右手搬"，那样协调成本比收益还大。

实际系统里两者往往混合使用。比如一个图像处理流水线，可能整体是任务并行的（读图、滤波、编码三个阶段各跑各的），但每个阶段内部又是数据并行的（滤波阶段把图片切成多块同时处理）。

2.2 数据并行的两种切法

数据并行往下再细分，又有两种切法，这个区别非常关键，搞混了会写出性能很差的代码。

按块切分：把一万块砖分成十堆，每堆连续的一千块。对应到数组，就是把下标 0-999 给线程一，1000-1999 给线程二，依此类推。这种方式的好处是每个线程访问的内存是连续的，缓存命中率高，因为在计算机系统里，缓存是按块加载的，连续访问能把一整块缓存行用满。

按轮转切分：线程一拿第 0、10、20 块，线程二拿第 1、11、21 块。这种方式乍看奇怪，但在某些场景下有用，比如当各个数据项的计算量差异很大时，轮转切分能让负载更均匀。代价是内存访问不连续，缓存效率下降，可能反而更慢。

我个人的经验是：能用按块切分就用按块切分，只有在负载严重不均、且计算量远大于内存访问开销时，才考虑轮转或更复杂的调度。这句话背后是实打实的性能差异，同一个矩阵运算，切法不同，跑出来的时间可能差两三倍。

2.3 任务并行里的依赖关系

任务并行的核心难点不是"怎么分成多个任务"，而是"任务之间有依赖，谁先谁后"。这就要提到**有向无环图（DAG）**这个模型：每个任务是一个节点，依赖关系是一条有向边，边指向的任务必须等前面的任务完成才能开始。

举个实际的例子。一个典型的推荐系统流水线可能是这样的：

1. 读取用户数据（无依赖）
2. 读取物品数据（无依赖）
3. 特征拼接（依赖 1 和 2）
4. 模型推理（依赖 3）
5. 结果排序（依赖 4）
6. 写回存储（依赖 5）

任务 1 和 2 可以并行，3 之后基本是串行的。看到问题了吗？这条流水线几乎没什么并行度，因为越往后依赖越重。这时候硬拆任务并行没意义，反而应该考虑第 3、4、5 步能不能做批处理式的数据并行——把多个用户的请求攒一批一起算，让 GPU 或 SIMD 指令把它们同时处理掉。

判断一个任务该用数据并行还是任务并行，我的经验法则是：看它的瓶颈在哪。如果瓶颈是计算量，往数据并行上想；如果瓶颈是不同工序的性质差异，往任务并行上想。强行用错模型，等于用螺丝刀拧螺母，能拧但费劲。

3. 内存模型与一致性：并行程序最容易翻车的地方

3.1 一个反直觉的例子

先看一段伪代码，这段代码能让所有并行新手栽跟头：

// 线程 A x = 1; flag = 1; // 线程 B while (flag == 0) { } print(x);

你觉得线程 B 会打印什么？很多人会说"1"。但真实的计算机系统里，它可能打印 0，甚至可能永远卡在循环里出不来。

为什么？两个原因。第一，编译器可能重排指令，把flag = 1提到x = 1前面，因为它看不出这两个变量有任何关系，重排对单线程语义没影响。第二，CPU 可能乱序执行，即使编译后的汇编是对的，现代处理器为了填满流水线，也会调整指令的实际执行顺序，或者在写缓冲里延迟写回，导致线程 B 看到的顺序和线程 A 写的顺序不一致。

这不是 bug，这是计算机系统为了性能做的正常优化。但在并行场景下，这些优化会破坏"代码顺序就是执行顺序"这个我们习以为常的假设。

3.2 缓存一致性协议在做什么

要理解为什么会出现上面的问题，得先看多核处理器怎么管缓存。

每个核心都有自己的私有缓存（L1、L2），共享最后一级缓存（L3）和主存。如果核心 A 把x = 1写进自己的 L1，核心 B 的 L1 里还留着x = 0的旧副本，两边就不一致了。硬件靠缓存一致性协议解决这个问题，最经典的是 MESI 协议。

MESI 用四个状态描述每一块缓存行的状态：

当一个核心想写某块数据时，它必须先把其他核心的对应缓存行置为 Invalid，这个动作叫"获取独占权"。这个过程需要跨核通信，是有成本的。如果两个核心频繁读写同一块数据，这块缓存行会在核心之间来回"弹跳"，每次都要发消息协商——这就是著名的**伪共享（False Sharing）**的根源。

3.3 伪共享：看不见的性能杀手

伪共享这个词听着玄乎，用起来很坑。缓存行通常是 64 字节，假设你有这样一个结构：

struct Counter { long a; long b; };

两个线程分别频繁给a和b加一。从逻辑上看，这俩变量毫无关系，各加各的，应该完全并行。但物理上a和b很可能在同一个 64 字节缓存行里。线程一改a会把整块缓存行置为独占，线程二的副本失效；线程二改b又要抢回来。两个核心像玩击鼓传花一样把同一块缓存行抢来抢去，性能直接崩掉。

解决办法很简单——填充（Padding），把两个变量隔开到不同的缓存行：

struct Counter { long a; char pad[56]; // 填充到 64 字节 long b; } __attribute__((aligned(64)));

我实测过一个高频计数器场景，未做填充时十六个线程的吞吐还不如单线程，加了填充之后直接涨到七倍。这种坑不看代码根本发现不了，因为你从逻辑上完全看不出它有问题。

提示：现代一些语言和库会自动处理伪共享。Java 的@Contended注解、C++ 的std::hardware_destructive_interference_size都是干这个的。但大多数情况下，你还是得自己意识到这个问题存在。

3.4 内存屏障与原子操作

回到 3.1 那个例子，怎么让它正确？答案是内存屏障和原子操作。

内存屏障（Memory Barrier / Fence）是一条特殊的指令，它告诉 CPU 和编译器："屏障之前的操作必须全部完成后，才能执行屏障之后的操作。"它限制了重排，保证了可见性。

原子操作则是"读-改-写"三步不可分割的操作。以 CAS（Compare-And-Swap）为例，它的语义是"如果内存里的值等于期望值，就换成新值，否则什么都不做"，并且整个过程是原子的。几乎所有无锁数据结构都建立在 CAS 之上。

这里有个实操心得值得记住：不了解内存模型就写无锁代码，几乎必然写出错的程序。我见过太多人照着网上的模板写无锁队列，测试时看着正常，压力一上来就崩，因为网上的模板往往省了必要的屏障或用了不正确的内存序。稳妥的做法是优先用语言提供的原子类型和现成的并发容器，比如 C++ 的std::atomic（明确指定内存序）、Java 的java.util.concurrent包，而不是自己从头造轮子。

内存序本身也有一套体系，从最弱的relaxed（只保证原子性，不保证顺序）到最强的seq_cst（全局顺序一致，最安全也最慢），理解它们的层级关系是进阶的关键：

• relaxed：只保证操作原子，不约束重排。适合计数器这类不关心顺序的场景。
• acquire/release：构成配对，release 之前的写对 acquire 之后可见。最常见的"发布数据"模式。
• seq_cst：所有线程看到的所有 seq_cst 操作顺序一致，最直观但开销最大。

用错内存序的后果是"程序在 x86 上好好的，换到 ARM 上就挂了"——因为 x86 内存模型较强，很多重排本来就不会发生，而 ARM 允许更激进的重排。跨平台开发的场景下，内存序必须严格对待，不能心存侥幸。

4. 并行编程的几种主流范式与选型思路

4.1 共享内存范式

共享内存是最直观的范式：多个线程跑在同一块地址空间里，直接读写公共变量。

它的优点是数据共享方便，一个线程算出来的中间结果另一个线程直接就能用，不需要显式地拷贝数据。缺点是同步复杂，你得时刻操心数据竞争、原子性、可见性这些问题，写不对就是各种诡异的偶发 bug。

线程和锁是最经典的组合。锁把并发访问变成了串行访问，安全但可能成为性能瓶颈。我一般遵循的原则是：

• 锁保护的临界区尽量小，只包住真正必须串行的部分
• 尽量避免在持锁期间做 IO 或调用可能阻塞的函数
• 优先用读写锁、无锁结构等更细粒度的方案，但前提是你真的理解它们的语义

共享内存适合数据交换频繁、负载相对均衡的场景，比如图像处理、矩阵运算、内存数据库。

4.2 消息传递范式

消息传递的思路是：每个进程有自己独立的内存空间，想交换数据就发消息。MPI 是这个领域的代表。

它的优点是不担心数据竞争，因为根本不存在共享数据，每个进程只管自己那块。扩展性特别好，可以跨机器、跨节点。缺点是通信成本高，每次交换都要显式地打包、发送、接收、解包，延迟比共享内存里的内存访问高好几个数量级。

消息传递适合大规模集群上的科学计算，比如气象模拟、流体力学、分子动力学。这些场景数据量大、计算密集、通信相对稀疏，能掩盖通信开销。

4.3 数据流与流水线范式

数据流范式把计算建模成"数据在算子之间流动"。每个算子是纯粹的变换，输入进来输出出去。这种范式天生适合并行，因为没有共享状态，算子之间只通过数据交互。

GPU 编程（CUDA、OpenCL）本质上是数据流的思想：你描述一个 kernel，它作用在整个数据集上，硬件负责把它铺到成千上万个执行单元上。这种模式下，程序员的关注点从"怎么调度"变成"怎么把算法表达成规整的并行原语"。

流水线范式则强调"连续数据处理，各阶段同时工作"。古老的按行处理、现代的流式处理框架都是这个思路。它的核心是把一个长任务拆成阶段，让不同数据在不同阶段上同时流动，就像工厂流水线。

4.4 怎么选：一张决策表

面对具体场景，用哪套范式？我整理了一张决策表，这个表是我自己在多年项目里摸索出来的，实用为主：

选错范式的代价非常大。我见过有人用共享内存 + 大量锁去做一个本质上是数据并行的任务，结果锁竞争把性能彻底吃掉了，改成 SIMD 之后快了二十倍。也见过有人用 MPI 去做单机上的交互式任务，通信延迟让体验惨不忍睹，换成线程就好了。

选型的核心问题是：通信/同步的频率和粒度。通信越稀疏，越能容忍高延迟的方案（MPI）；通信越密集，越需要用低开销的共享内存加精细的同步设计。

5. 加速比、扩展性与性能模型：别被"核数"骗了

5.1 Amdahl 定律：串行部分的诅咒

很多人以为八核就能加速八倍，这个幻想被 Amdahl 定律无情击碎。

Amdahl 定律说：假设程序中有一部分必须串行执行，占比为 s，那么无论加多少核心，加速比上限是1/s。

举个例子。如果你的程序有 10% 必须串行，那么极限加速比是 10 倍，哪怕你有一千个核心，也只能跑到十倍。如果串行部分占到 50%，极限加速比就是 2 倍。

这个定律的现实意义是：优化并行之前，先看看串行部分有多少。如果一个程序串行部分占 30%，你花大力气优化并行部分基本上是白费，正确的做法是先想办法把那 30% 并行化或者减少掉。

实测中我经常看到这种情况：一个任务单线程跑 100 秒，其中 20 秒是数据加载和结果写回（串行），80 秒是可并行的计算。有人上来就把 80 秒的部分用了八个线程，结果 20 + 10 = 30 秒，加速比只有 3.3 倍，他还纳闷为什么不是八倍。其实按 Amdahl 定律一算就明白了，你优化错了地方。

5.2 Gustafson 定律：另一种视角

Amdahl 定律假设问题规模固定。但实际中往往是问题规模随资源增长——有了更多核心，你会想处理更大的数据。这时候该用 Gustafson 定律。

Gustafson 定律说：如果问题规模可以随核心数一起扩大，那么加速比可以接近线性。因为随着问题变大，可并行部分占比通常也变大，串行部分占比相对缩小。

这两个定律不矛盾，它们回答的是不同问题：Amdahl 回答"同样的问题用更多核心能快多少"，Gustafson 回答"更多核心能做多大的问题"。理解它们的区别，能帮你正确评估自己的程序到底是在哪个维度上优化。

5.3 强扩展与弱扩展

工程上更实用的两个概念是强扩展和弱扩展。

强扩展（Strong Scaling）：问题规模固定，核心数增加，看加速比。这是 Amdahl 场景，加速比会逐渐饱和。

弱扩展（Weak Scaling）：每个核心处理的问题规模固定，核心数增加，问题规模也同比扩大，看单核心效率能否保持。这是 Gustafson 场景，理想情况下效率应该稳定在比较高的水平。

我评估一个并行程序是否优秀，通常先看弱扩展。如果弱扩展都做不到 70% 以上的效率，说明通信或同步开销太大，这个并行方案的架构大概率有问题。强扩展则是用来判断"这个任务值不值得并行"的，如果强扩展在四核心就到头了，那这台机器上再堆核心也没意义。

5.4 怎么测加速比才靠谱

测加速比这件事本身有很多讲究，稍不注意就会测出误导性的数据：

1. 必须多次运行取中位数或最小值，单次的噪声太大。
2. 必须确保输入规模足够大，小规模任务里启动和关闭线程的开销会占大头，测出来的加速比毫无意义。
3. 必须预热，尤其是涉及 JIT 编译或 GPU 的环境，前几次运行都是热身。
4. 必须固定线程数环境，别让操作系统和后台任务来捣乱。
5. 必须测完整的端到端时间，而不是只测计算部分，否则会被 Amdahl 定律偷袭。

我踩过的最大的坑是测一个矩阵乘法，规模设得不够大，测出来十六线程比单线程还慢，一度以为并行库有 bug，后来把规模放大十倍，加速比立刻变成接近十四倍。小规模并行测量的结果基本没有参考价值，这是必须刻在脑子里的。

6. 实际工程中的性能陷阱与调优清单

6.1 陷阱一：锁竞争

锁竞争是共享内存并行的头号性能杀手。表现是：线程数加了很多，性能却不涨反降，用分析工具一看，大量时间花在等锁上。

根因通常是临界区太大或者锁的粒度太粗。比如一个全局哈希表，所有操作都抢一把大锁，那不管多少线程都会排队。

解决办法有几种思路，按侵入性从小到大：

• 缩小临界区：只把真正必须原子的部分包进来，其他部分移出去。
• 分片锁（Lock Striping）：把一个大结构拆成若干分片，每片一把锁，不同 key 落到不同分片，自然分散竞争。java.util.concurrent.ConcurrentHashMap就是这么做的。
• 无锁化：用 CAS 等原子操作替代锁。实现复杂，收益视情况而定，别盲目上。

我个人的经验是，先用分片锁解决大部分竞争问题，无锁化只在 profiling 明确显示锁是瓶颈、且场景真的适合时才考虑。很多人一上来就想搞无锁，结果既没快多少，还引入了一堆难查的 bug。

6.2 陷阱二：负载不均

理想情况下所有线程同时开工、同时完工。现实往往是有的线程十分钟干完在那闲着，有的线程还在苦干，总时间被最慢的线程拖住。

根源是任务划分不均匀。比如按数据块切分时，某些数据块的计算量就是比别的大，规则切分反而制造了不均衡。

解决办法：

• 任务窃取（Work Stealing）：把任务切成很多小任务放进队列，空闲线程从队列尾部偷活干。Java 的 ForkJoinPool、Intel TBB 都是这个思路。
• 动态调度：不预先划分，而是让线程在运行时从共享任务池里领任务，天然负载均衡。
• 预测性划分：如果能预知计算量差异，可以按加权切分，让每个线程分到的"总计算量"接近。

任务窃取是目前最通用也最省心的方案，代价是任务划分要足够细，细到能填满调度粒度，否则调度开销会吃掉收益。

6.3 陷阱三：过度并行化

不是线程越多越好。每个线程都有自己的栈、自己的寄存器上下文，创建、调度、切换都有开销。当任务太小时，这些开销会超过并行带来的收益。

一个常见现象：一个 per-element 的操作，每个元素的处理只要几纳秒，你却给每个元素开一个任务。那绝大部分时间都花在任务调度上了。

解决办法是批量化：不要一个元素一个任务，而是把元素攒成批次，一批一个任务。批的大小要权衡，一般让单个批次的计算时间在微秒到毫秒级别比较合适。

6.4 陷阱四：内存带宽瓶颈

即使你的计算完美并行，如果所有线程都在疯狂读内存，那么内存带宽就成了公共瓶颈。多个核心抢内存总线，实际性能远低于核心数。

这不是算法问题，是硬件限制。应对思路：

• 提高计算密集度：让每个字节的读取对应更多的运算，把带宽需求降下来。
• 缓存分块（Blocking）：把大数组切成能装进缓存的小块，块内复用，减少对主存的访问。
• 共享数据：多个线程如果读同样的数据，尽量让它们读同一份缓存副本，而不是各自从主存拉。

矩阵乘法是典型的例子。朴素三重循环的内存访问模式很差，分块之后能把主存访问降到很低，性能提升十倍以上。这种优化本质上是把"带宽受限"变成"计算受限"。

6.5 调试并行程序的实际手段

并行 bug 难查，因为它们往往是偶发的、时序相关的。我常用的手段有这么几个：

第一，用死锁检测工具。大多数平台都有，能自动识别锁顺序问题。

第二，强制改变调度和时序。加随机 sleep、故意打乱线程启动顺序，让隐藏的竞争暴露出来。在一个设计不当的无锁队列上，我靠这个方法五分钟复现了概率万分之一的 bug。

第三，用 sanitizer。数据竞争检测器（如 ThreadSanitizer）、地址检测器（如 AddressSanitizer）能自动发现大量并发问题。代价是运行时开销大，但查 bug 时这点开销完全值得。

第四，日志加线程标记。所有日志都带上线程 ID 和时间戳，事后分析时序关系。这招土但有效。

第五，简化复现条件。把线程数降下来、把数据规模降下来，先在小规模上稳定复现，再逐步扩大。很多 bug 在四线程上能复现，在十六线程上才难查，那就先在四线程上定位。

7. 从零写一个并行程序：完整思路拆解

7.1 第一步：判断可并行度

拿到一个任务，第一件事不是写代码，是分析它能并行到什么程度。

举个例子：统计一个亿级数组里的素数个数。

先看依赖关系。判断一个数是不是素数，跟其他数的判断完全没有关系。这是完全可并行的任务，理想情况下核数翻倍，速度翻倍。

再看计算量分布。素数的分布极不均匀，小的数需要试除的因数少，大的数需要试除的多，而且素数本身比合数计算量大。所以不能简单地均分数组，否则负载会严重不均。

结论：这是一个数据完美并行、但负载不均的任务。适合动态调度或者任务窃取。

7.2 第二步：选择粒度

粒度太细，调度开销大；粒度太粗，负载不均。素数统计这个任务的单个元素计算量是微秒级别，如果每个元素一个任务，调度开销会比计算本身还大。

合适的做法是把数组分块，块的大小使得单块计算时间在几十微秒到毫秒之间，然后对这些块做任务窃取。这样既保证了负载均衡，又摊薄了调度开销。

7.3 第三步：设计同步策略

这个任务里，各个线程计算的是不同区间的素数个数，完全不需要同步。这是最理想的情况，没有任何共享状态需要协调。

只需要在最后把各线程的结果汇总一下。汇总这一步用原子加法或者最后的串行合并都行，因为只执行一次，开销可以忽略。

如果一个任务需要频繁同步，那就是设计上的红旗，得重新考虑切分方式。我的一般原则是：能避免同步就避免，能降低同步频率就降低，同步越少，扩展性越好。

7.4 第四步：估算加速比上限

按 Amdahl 定律算一下。假设数据的读取和结果汇总占总时间的 5%，并行部分占 95%，那么理论极限加速比是 1/0.05 = 20 倍。

如果只用八核心，理想加速比是 1 / (0.05 + 0.95/8) = 1 / 0.169 = 5.9 倍。实测如果拿到 5 倍以上就算是很好的实现了。

心里有这个数，测出来的结果才知道是正常还是有问题。先算理论上限，再看实测，这个习惯能帮你快速判断问题出在哪。

7.5 第五步：实测与迭代

写完了，跑一遍，看实际加速比和理论上限差多少。

如果差得远，逐个排查：

• 是不是负载不均？用计时统计每个线程的耗时，看方差。
• 是不是共享状态有竞争？检查有没有无意的共享变量（比如各线程都写同一个累加变量）。
• 是不是内存带宽瓶颈？看看是不是读数远超计算量。
• 是不是粒度不对？调大或调小块的大小试试。

这个迭代过程通常要反复几次，每次只改一个变量，观察效果。并行调优就是这么一个试错过程，没有一劳永逸的公式。

8. 常见问题上手指南

8.1 多少个线程最合适

很多人问线程数设多少，我的答案从来都是：跟核心数挂钩，通常设置为物理核心数或物理核心数附近。

为什么不是逻辑核心数（含超线程）？因为超线程共享物理核心的执行单元，两个逻辑核对计算密集型任务的加速有限，甚至因为争抢资源反而变慢。对于 IO 密集型任务，线程数可以设得比核心数多，因为线程大部分时间在等 IO。

实测建议：先设成物理核心数跑一遍，再试物理核心数的 1.5 倍、2 倍，看哪个最好。不同任务的表现差异很大，没有万能值。

8.2 什么时候不该并行

不是所有任务都值得并行。判断标准：

• 任务本身太小：总执行时间只有几百微秒，并行的开销会把收益吃掉。
• 串行占比太高：按 Amdahl 定律，串行超过 50% 就别折腾了。
• 一次性任务：就跑一次，写并行的开发和调试时间远超省下的运行时间。
• 需要强一致性的操作：同步成本高到并行失去意义。

我见过有人把只跑一次的脚本改成并行的，结果调试花了三天，省下的运行时间总共三分钟。这是典型的过度工程。

8.3 并行程序的正确性怎么保证

并行程序最大的挑战是正确性。几个实操建议：

第一，所有共享数据要么用锁保护，要么用原子操作，没有中间地带。哪怕你觉得"这个变量大概率不会被同时写"，也得老老实实保护起来，因为时序问题永远比你想象的更刁钻。

第二，优先用经过验证的并发容器，别自己造轮子。除非是学习和研究目的，生产代码里的无锁结构都应该用现成的库。

第三，写测试用例时要考虑并发。单次运行正确不代表每次都正确，需要重复运行、压力测试、用竞态检测工具。

第四，注意内存模型的平台差异。x86 上跑的代码在 ARM 上不一定对，跨平台的项目要严格按规范写内存序。

8.4 性能测量的常见误区

前面提到的测量要多次、要预热、要足够规模，这些是基础。还有几个更细的点：

别在调试模式下测性能，优化开关没开，测出来的结果毫无意义。

别忽略系统噪声，后台进程、电源管理、温度都会影响结果，条件尽量控制一致。

别只看平均值，尾延迟（比如 P99）往往比平均值更重要，尤其是对延迟敏感的场景。

别用单一指标，吞吐量和延迟是两个不同维度，要一起看。

9. 我自己踩过的几个坑，以及给出的建议

最后分享几个我在实际使用中印象深刻的教训，都是文档里不会写、只有真正动手才会遇到的。

第一个坑是关于预热。早期做 GPU 并行计算，测出来第一版性能比 CPU 慢十倍，差点就把方案换掉了。后来才发现，GPU 的首次 kernel 加载和显存分配都很耗时，前几次运行根本没进入稳定状态。加预热之后，性能优势立刻显现出来。测并行性能，预热不是可选项，是必选项。

第二个坑是关于测量粒度。有一次优化一个并行任务，测到的加速比总是不理想。后来把计时代码细化，发现时间根本不是花在计算上，而是花在结果收集上——各个线程都往一个共享队列里塞结果，队列的锁竞争成了瓶颈。改成每个线程先往本地缓冲写，最后一次性合并，性能立刻上去了。Profiling 要看分解，别只看总量。

第三个坑是关于内存序。写过一段无锁代码，在本地 x86 机器上跑了几个月都没问题，部署到 ARM 服务器上偶发崩溃。花了两天才定位到是一处内存序用得太弱，本地的强内存模型掩盖了问题。跨平台场景下，内存序一定要保守，别图快用最弱的。

第四个坑是关于负载均衡的假象。有个任务，表面上数据是根据索引均匀分块的，看起来应该很均衡。但实测加速比远低于预期，分析之后发现数据的分布有偏，前面的块计算量比后面小得多，导致先做完的线程长期空闲。改成动态调度之后解决。别假设数据是均匀的，要么分析分布，要么用动态调度兜底。

最后一个建议落到实处：写并行程序之前，先老老实实算出理论上限和串行部分占比。这个动作花不了十分钟，能帮你避免大量无用功。如果理论加速比就在三五倍，那你费大劲优化到七倍是不现实的，早点接受这个事实，把精力放在更值得的地方。

并行计算是个需要敬畏的领域，计算机系统给了你多个核心，但能不能用好，取决于你对同步、通信、内存模型、性能模型这些底层机制的理解深度。把这些东西吃透，你会发现那些曾经诡异的性能问题和偶发 bug 都有清晰的解释和解决路径。