概述

“性能优化”的四个问题

1. 价值判断是否性能问题
2. 定位问题层级出在哪个量级
3. 选择合适的策略去解决这个量级的瓶颈
4. 在这个策略下，代码/编译/微架构层面还能再提升多少

绝大多数失败的优化努力，其实死在第 1 和第 2 步，而不是第 4 步。

二、四个典型量级 + 对应的宏观打法

一句话口诀： 先解决量级问题，再解决内存问题，再解决分支问题，最后才碰指令级和编译器细节。

三、宏观决策流程

1. 价值
   • 这个 20% 慢真的值不值得花 2 周去优化
   • 优化后对关键指标（QPS、P99、功耗、帧率、资金效率等）提升有多大
   • 有没有更简单粗暴的方案（加机器、降精度、分区、业务降级）
2. 先用最高层工具定位（而不是先猜热点）
   • perf + flamegraph（最常用）
   • VTune / Tracy / Nsight / Perfetto
   • perf c2c / likwid / uica / llvm-mca（二级定位）
3. 用“瓶颈分类表”快速定策略

1. 分阶段投入原则

   第一阶段：定位 + 改布局 + batching + 去虚 第二阶段：向量化 + 分支重排 + PGO 第三阶段（2 周+）：BOLT / Propeller / 手写 SIMD / 汇编

四、趋势方向

1. 数据布局仍然是王道 AoS → SoA / AoSoA / hybrid layout 仍然是最高杠杆的改动之一。
2. 向量化比很多人想的更重要 AVX-512、SVE、ARM SVE2 普及度在上升，auto-vectorization 成功率也在提高，但前提是数据布局和内存访问模式友好。
3. PGO + ThinLTO + BOLT/Propeller 组合已成为“基本盘” 越来越多的项目把这三者作为默认构建选项，而不是“极致优化才开”。
4. 内存带宽和功耗成为新瓶颈 尤其在服务器、移动、AI 推理场景，优化目标从“快”变成“快且省电/省带宽”。
5. 工具驱动优化越来越强 靠感觉写内联、靠手改向量化正在变成低效行为，更多团队依赖 llvm-mca、uiCA、Propeller 等工具给出建议。

五、宏观框架

优化分成三个层次去看：

• 第一层：业务/算法层面，我们把 XXX 从 O(n²) 降到 O(n log n)，收益 ≈ 40×
• 第二层：内存访问层面，我们把数据从 AoS 改成 SoA + 主动预取，L3 miss 下降 65%，整体加速 2.4×
• 第三层：微架构 + 编译器层面，通过 PGO + ThinLTO + 分支重排，额外拿到 1.35×

NUMA

NUMA（Non-Uniform Memory Access，非均匀内存访问） 是现代多路（multi-socket）服务器中最核心的内存架构特征，几乎所有还在服役的主流服务器 CPU（Intel Xeon Scalable、AMD EPYC、部分 ARM 服务器芯片）都深度依赖 NUMA 来实现高核心数 + 高内存容量的可扩展性。

简单一句话概括： NUMA 就是“同一个系统里，不同 CPU 核心访问同一块内存的延迟和带宽是不一样的”，离得近的内存快，离得远的内存明显慢。

1. 历史

早期多核系统用 UMA（Uniform Memory Access）：所有核心通过一个共享的总线 / 内存控制器访问同一块内存。 但当核心数超过几十、上百时：

• 共享总线 / 控制器成为瓶颈
• 信号传播距离变长 → 延迟爆炸
• 电容、功耗、布线难度指数级上升

于是硬件厂商改用 分布式内存 + 点对点互联 的方式：

• 每个 CPU socket（或每个芯片组）带自己的本地内存控制器 + 本地 DIMM 槽
• socket 之间用高速互联（Intel 用 UPI / QPI，AMD 用 Infinity Fabric，部分 ARM 用 CMN / CM3）互相连起来
• 本地内存访问最快，跨 socket 访问要走互联 → 延迟增加 1.8~3 倍，带宽下降明显

这就是 NUMA 的物理根源。

2. 典型 NUMA 拓扑举例

关键点：现在的 NUMA 不只跨 socket 了，单 socket 内部也可能有子 NUMA（AMD NPS、Intel SNC / sub-NUMA clustering）。

3. NUMA 对性能的真实影响

实测数据：

• Redis/Memcached：跨 NUMA 命中率下降 → QPS 掉 20–50%
• 数据库（PG/MySQL/ClickHouse）：Join、聚合跨节点 → 延迟抖动增大 2–4 倍
• AI 推理/训练（大模型 loading）：内存带宽瓶颈时跨 NUMA 损失 30–60%
• 低延迟交易：跨 NUMA 一次访问就能多 80–120ns → 致命

4. Linux 下怎么感知和控制 NUMA

查看当前机器 NUMA 拓扑

1
2
3
4
5
6
7
8
9
10
11
12
13
14
# 节点数、CPU 分布、内存大小
numactl --hardware

# 更详细拓扑（推荐）
lscpu -e

# 树状图可视化（最直观）
lstopo   # 需要安装 hwloc 包

# 每个进程当前在哪些节点分配了内存
numastat -c  # 看进程名或 pid

# 节点间距离矩阵（latency 相对值）
numactl --hardware | grep distances

常用控制手段

自动优化工具

• numad（NUMA 自动守护进程）：动态迁移页面和进程，适合负载变化大的环境
• numactl –hardware-aware 或容器 orchestrator（如 K8s CPU Manager static policy）

5. 生产中最常见的 NUMA 优化策略

1. 延迟敏感型（交易、游戏服、实时推理）： 尽量 membind + cpubind 到同一个 NUMA 节点，避开跨节点访问。
2. 吞吐量型（Nginx、日志分析）： 可以用 interleave 或者不绑，让内存均匀分布，避免单节点带宽打满。
3. 内存大户（ClickHouse、分析型数据库）： 优先绑内存 + 绑核，结合 hugepage + mlockall。
4. 虚拟化 / 云原生（KVM、容器）： 用 vNUMA（暴露真实拓扑给 guest），K8s 用 static CPU policy + topologyKeys。

性能优化建议

最常见、最具代表性的优化手段的实际收益排序（从高到低

排序主要针对浮点/整数稠密计算热点（最常见的“高性能C++”场景），其他场景（如分支密集、稀疏、分配爆炸）会明显移位。

排序

“先吃内存，再吃向量，然后并行分核，最后填坑”

1. 内存（Cache + 布局） → 不做好后面全废
2. 向量（SIMD） → 天花板最高的那一刀
3. 并行（多线程/任务） → 乘以核心数，但别破坏前两步
4. 分配/热点微调 → 哪个爆了修哪个

不同场景的微调排序

• 游戏物理/粒子/渲染批处理：1（SoA+缓存） > 2（SIMD） > 3（并行） > 5（分配）
• ML推理内核 / 图像/音视频滤波：2（SIMD） ≈ 1（缓存） > 4（并行） > 7（PGO）
• 服务器 / 高吞吐后台计算：4（并行） > 1（缓存+伪共享） > 5（分配） > 2（SIMD较少用）
• HFT / 超低延迟：5（分配） > 1（缓存） > 8（分支） > 4（通常单线程）
• 科学计算 / 大矩阵：2（SIMD） > 1（缓存 blocking） > 4（并行） > 7（PGO）

中断

中断（Interrupt） 是操作系统和 CPU 必须处理的最重要机制之一，它让 CPU 能够及时响应外部事件或内部异常，而不是一直轮询检查。

中断的分类方式有很多种，不同教材/内核/架构的叫法略有差异。下面按最常见、最实用的分类方式来讲解（以现代 x86-64 Linux 视角为主），并标注发生时机。

1. 按来源 / 产生者分类

2. 按是否与 CPU 时钟同步分类

• 同步中断（Synchronous） 只在当前指令执行结束或指令边界产生，与 CPU 时钟严格同步。 → 异常（Exception）基本都属于这一类。 发生时机：执行到出错指令、系统调用指令、调试指令时。
• 异步中断（Asynchronous） 可在任意指令之间发生，与 CPU 执行流无关。 → 硬件中断（包括 NMI 和普通 IRQ）都属于异步。 发生时机：外部硬件信号随时到达。

3. 按可屏蔽性分类（影响优先级和紧急度）

• 可屏蔽中断（Maskable Interrupt） CPU 可通过设置中断掩码寄存器（或 cli/sti 指令）暂时忽略。 大部分外设中断都可屏蔽。
• 不可屏蔽中断（Non-Maskable Interrupt, NMI） 无论 cli 还是屏蔽位都无法忽略，用于最高紧急事件。 发生时机：硬件严重故障、系统挂起检测等。

4. Linux 内核实际最常用的“两阶段”视角（上半部 vs 下半部）

总结：中断发生时机的“一句话规律”

• 硬件中断：随时（异步），由外设电信号触发。
• 异常（同步中断）：当前指令执行中或结束时，CPU 自己检测到问题。
• 软中断：硬中断上半部标记后，在中断退出路径、ksoftirqd 内核线程、系统调用返回等“安全点”被执行。
• 系统调用（特殊软中断/陷阱）：用户程序主动执行 syscall 指令时。

分类组合：

1. 硬件中断 vs 异常（异步 vs 同步）
2. 可屏蔽 vs 不可屏蔽
3. 上半部（硬中断） vs 下半部（软中断/Tasklet）

上下文切换

含义

上下文切换（Context Switch） 是操作系统中非常核心且代价很高的一个操作。

简单一句话定义：

上下文切换 = 操作系统暂停当前正在运行的进程/线程，把CPU让给另一个进程/线程，并让新进程/线程开始执行的过程。

在这个过程中，操作系统必须“保存好旧任务的现场” + “恢复新任务的现场”，这会带来明显的性能开销。

上下文切换到底在保存和恢复什么？

上下文切换的典型开销

一句话总结开销：一次完整进程上下文切换通常消耗几微秒到十几微秒，相当于几千到几万条普通指令的执行时间。

上下文切换常见场景

1. 时间片用完（最常见） → 调度器抢占（preemptive）
2. 当前进程主动 sleep/yield/wait/block（I/O、锁、sleep、条件变量等）
3. 高优先级任务就绪（中断、信号、定时器）
4. 系统调用中显式调度（sched_yield）
5. 中断处理完后返回用户态时发现需要调度

上下文切换对性能的真实杀伤力

• 破坏了 CPU 缓存（L1/L2/TLB） 的局部性
• 破坏了 分支预测器、指令预取 的历史记录
• 多核下还可能引发 缓存一致性协议 开销（特别是跨 NUMA）
• 高并发服务器里如果每秒发生几十万次上下文切换，CPU 有效利用率可能掉到 30–50%

零拷贝与上下文切换的关系

总结一句话：

上下文切换是操作系统把 CPU 使用权从一个执行流（进程/线程）交给另一个执行流时，必须付出的“现场保存与恢复”代价，它本身不干活，但几乎每次都会带来 缓存失效 + 几千到几万 CPU 周期的开销，是高并发系统最主要的性能敌人之一。

系统调用中的”上下文切换”

系统调用为什么会产生“上下文切换”？ 其实严格来说，大多数系统调用并不引发完整的进程/线程上下文切换（即不切换到另一个进程或线程），而是引发一种特权级/模式切换（user mode ↔ kernel mode），但这个过程在寄存器、栈、TLB等方面与上下文切换高度相似，因此很多人（包括很多性能分析工具）会把它也称为“上下文切换”或“轻量上下文切换”。

最常见的现代 x86-64 Linux 来拆解真实流程和为什么有开销。

1. 系统调用典型流程

以 read() 系统调用为例（syscall 指令路径，Linux 5.x+）：

总结流程一句话： 用户 → syscall → 保存用户现场 → 内核态执行 → （可能调度其他进程） → 恢复用户现场 → 返回用户态

2. 系统调用和上下文切换的区别

所以最准确的说法是：

• 每一次系统调用都会发生用户态 ↔ 内核态的模式切换（privilege level switch / mode switch）
• 这个模式切换本身就要保存/恢复大量寄存器、切换内核栈、刷新部分预测器、可能换 cr3（地址空间） → 这和上下文切换的很多动作高度重合
• 但不一定会发生完整的进程/线程切换（即切换 current task_struct、换页表、换整个 CPU 上下文到另一个任务）

3. 为什么很多人直接说“系统调用会引起上下文切换”？

1. 开销在同一个数量级（尤其是老内核或大量浮点/AVX 寄存器时）
2. perf、bcc、systemtap 等工具通常把 mode switch 也统计进 “context switch” 或 “kernel/user transitions”
3. 阻塞型系统调用确实会引发真正的进程调度
4. 早期文档和很多教程简化表述，没有严格区分 “mode switch” 和 “full context switch”

4. 快速总结对比表

一句话结论：

系统调用一定会引发用户-内核模式切换（带有寄存器保存/恢复、栈切换等动作），这本身就很像“轻量上下文切换”；但只有在调用阻塞、时间片到期或显式调度时，才会发生完整的进程/线程上下文切换。

内存序

C++11 引入的 内存序（memory order） 是现代 C++ 并发编程中最核心、最难理解的概念之一。它本质上是在回答一个问题：

“当我在一个线程里对原子变量做了写操作，其他线程什么时候、按照什么顺序能看到我写的这个值，以及我之前写的非原子变量？”

下面按从最严格 → 最宽松的顺序给你讲解六种内存序，以及它们在底层大概是怎么实现的（以 x86-64 + ARM64 常见的硬件为例）。

C++11 提供的六种内存序（由强到弱）

每种内存序的核心语义与底层逻辑

1. memory_order_seq_cst（顺序一致性，最常用也最贵）

   • 保证：所有 seq_cst 操作在所有线程看来有一个单一全局总顺序（Single Total Order）
   • 这是最接近我们大脑直觉的模型
   • 代价最高，几乎总是插入最强的内存屏障（x86 上 mfence，ARM 上 dmb ish 或更强）
   • 几乎所有经典教材例子都默认用这个

2. memory_order_acquire + memory_order_release（最常用的高性能组合）

   Release-Acquire 模型（简称 RA 模型）：

   • Release store：本线程在此之前的所有内存操作（包括非原子变量），在其他线程看到这个 release 写入之前不能被重排到这个 store 之后
   • Acquire load：当本线程看到这个 acquire 读到的值时，之前那个 release store 之前的所有内存操作对本线程可见
   • 形成 Synchronizes-with 关系 → 建立 Happens-before 关系
   • 最经典用法：生产者-消费者模式里的 flag

   1
   2
   3
   4
   5
   6
   7
   8
   // 线程1（生产者）
   data = 42;
   ready.store(true, std::memory_order_release);   // 关键
      
   // 线程2（消费者）
   if (ready.load(std::memory_order_acquire)) {    // 关键
       // 此时 一定 能看到 data == 42
   }
   

3. memory_order_acq_rel（读-改-写专用）

   • 相当于 acquire + release 同时具备
   • 用于 fetch_add、compare_exchange_strong 等 RMW 操作
   • 既是 release 又是 acquire

4. memory_order_relaxed（最弱，只有原子性）

   • 只保证这个操作本身是原子的
   • 不阻止任何重排，不建立任何同步关系
   • 计数器、统计量、唯一 id 生成器等场景常用
   • 但极易出错，不能用来做同步

   1
   2
   std::atomic<int> cnt{0};
   cnt.fetch_add(1, std::memory_order_relaxed);  // 只保证不撕裂
   

5. memory_order_consume（目前几乎没人用）

   • 理论上只保证依赖传递（dependency-ordered）
   • 实际实现：GCC/Clang 几乎都把它降级成 acquire（性能损失）
   • C++26 之前基本被废弃状态，不要用

快速对比表

底层硬件实现差异（极简总结）

一句话总结使用建议：

• 写新代码、逻辑不复杂 → 直接用默认的 memory_order_seq_cst
• 性能极致追求、代码经过充分验证 → 用 release / acquire / acq_rel
• 只做计数、不依赖顺序 → relaxed
• 永远不要用 consume（除非你非常清楚自己在做什么且针对特定编译器）

• Previous
  eBPF
• Next
  耗时分析