1. 项目概述：从一次诡异的性能瓶颈说起
如果你写过C++多线程程序，并且对性能有要求，那你很可能遇到过一种令人困惑的场景：明明两个线程在操作完全独立的内存地址，理论上应该并行无阻，但程序的运行速度却比单线程还要慢，或者随着线程数增加，性能提升远低于预期。CPU使用率看着挺高，但活儿就是干不快。几年前，我在优化一个高频交易系统的风控模块时就踩进了这个坑。模块里有两个关键计数器：一个记录交易笔数，一个记录风险触发次数。它们被定义在一个结构体里，由两个独立的线程分别更新。逻辑上井水不犯河水，但性能测试时，双线程版本比单线程慢了将近30%。经过一番抽丝剥茧，最终定位到的罪魁祸首就是“伪共享”。
简单来说，伪共享是并发编程中一个非常隐蔽的性能杀手。它不涉及逻辑错误，不会导致程序崩溃或数据错乱，但它会悄无声息地拖垮你的程序性能，尤其是在多核处理器成为主流的今天。理解并解决它，是从“能跑”的多线程代码迈向“高效”的多线程代码的关键一步。这篇文章，我就结合自己的踩坑和填坑经历，把伪共享问题的来龙去脉、定位方法和解决方案掰开揉碎了讲清楚。无论你是正在学习C++并发的学生，还是已经有一定经验但想深入优化性能的开发者，相信都能从中获得实用的干货。
2. 伪共享问题的本质与原理剖析
要理解伪共享，我们必须先深入到现代CPU的缓存体系结构中去。这听起来有点硬核，但我会尽量用生活中的例子来类比，让你能直观地感受到问题所在。
2.1 现代CPU的缓存层次与缓存行
你的电脑CPU主频可能高达几个GHz，但内存的速度远远跟不上。为了解决这个速度鸿沟，CPU内部设计了多级缓存，就像在公司（CPU）和远程仓库（内存）之间设立了多级中转站（缓存）。
通常，我们有L1、L2、L3缓存。L1最快，但容量最小，通常每个CPU核心独享；L3最慢，但容量最大，由所有核心共享。数据在内存和CPU之间搬运，并不是一个字节一个字节地拿，而是以“块”为单位。这个块，就是缓存行。在x86-64架构下，一个缓存行的大小通常是64字节。你可以把它想象成快递员送快递，他每次不会只送一封信，而是把一个小区（64字节区域）的所有信件打包成一个包裹（缓存行）一起送。
当CPU核心需要读取某个内存地址的数据时，它会先把包含这个地址的整个缓存行从内存加载到自己的缓存中。后续如果还要访问这个缓存行内的其他数据，速度就极快，因为已经在“快递站”（缓存）里了。
2.2 缓存一致性协议：MESI及其变种
现在问题来了，多个核心都有自己的缓存，如果它们都缓存了同一块内存数据，某个核心修改了数据，其他核心的缓存数据不就过期了吗？为了解决这个问题，CPU设计了一套复杂的“通讯协议”，确保所有核心看到的内存视图是一致的。最著名的就是MESI协议。
MESI代表了缓存行的四种状态：
- M (Modified，已修改)：该缓存行只存在于当前核心的缓存中，并且已被修改，与内存中的数据不一致。它是数据的“唯一正版”。
- E (Exclusive，独占)：该缓存行只存在于当前核心的缓存中，但与内存中的数据一致。它是“干净的独家副本”。
- S (Shared，共享)：该缓存行可能存在于多个核心的缓存中，且所有缓存中的数据都与内存一致。大家手里都是“相同的复印件”。
- I (Invalid，无效)：该缓存行数据是无效的，不能使用。需要从其他缓存或内存中重新加载。
这个协议通过核心间发送“嗅探”消息来维护状态。当一个核心要写入一个处于S（共享）状态的缓存行时，它必须先向所有其他核心广播一个“请求独占”的消息，让其他核心把它们的该缓存行状态置为I（无效）。这个过程称为缓存行无效化。然后它才能把状态改为M并进行修改。其他核心后续如果再想读这个数据，就会发现自己的缓存无效了，必须重新从内存或修改者的缓存中加载最新的缓存行。
2.3 伪共享是如何发生的？
现在我们有了所有拼图。假设我们有一个简单的结构体：
struct Counter { long long a; // 8字节 long long b; // 8字节 };两个线程，线程1频繁自增counter.a，线程2频繁自增counter.b。a和b加起来16字节，远小于64字节，因此它们极有可能位于同一个缓存行中。
- 初始状态：线程1（核心1）和线程2（核心2）都读取了这个结构体，缓存行状态为S（共享）。
- 线程1写入a：核心1要写入
a，它发出无效化信号，核心2的缓存行状态变为I（无效）。核心1将缓存行状态改为M，修改a。 - 线程2写入b：几乎同时，核心2要写入
b。但它发现自己的缓存行状态是I（无效）！它不能直接写。于是核心2也必须发出请求，让核心1的缓存行无效化（或者写回内存），然后核心2加载新的缓存行，再改为M状态去修改b。 - 循环往复：两个线程你写一下，我写一下，导致这个缓存行在两个核心的缓存之间像乒乓球一样被来回弹射。大量的CPU周期浪费在了发送无效化消息、等待响应和重新加载缓存行上，而不是真正执行有用的计算。这就是伪共享——两个线程从逻辑上共享的是不同的变量（
a和b），但从物理上（缓存行）却被迫“共享”并产生了冲突。
注意：伪共享最恶劣的影响在于，它造成的性能损失与线程间的真实数据竞争无关。即使两个线程操作的数据毫无关联，只要它们不幸地落在同一个缓存行，就会引发这种“缓存乒乓”效应。在高并发、低延迟的场景下，这种开销是致命的。
3. 定位伪共享：从现象到根因的排查流程
当程序出现多线程性能 scaling 不理想（线程数增加，性能不线性增长甚至下降）时，伪共享是需要重点怀疑的对象之一。但如何证实它呢？不能光靠猜，我们需要一套可操作的定位方法。
3.1 性能监控与现象识别
首先，你需要一些监控工具来发现异常迹象：
- 性能分析器：使用像
perf(Linux)、VTune(Intel)、AMD uProf这样的工具。关注高LLC-load-misses(Last Level Cache 未命中) 和LLC-store-misses事件。伪共享会导致这些事件激增。 - 线程并发图：观察线程的运行状态。如果线程们看起来都在忙（CPU占用高），但任务完成速度很慢，且线程间存在明显的“步调一致”的等待（从并发图上看像是锁步执行），这可能是缓存行乒乓的间接表现。
- 简单的测试实验：这是最直接的方法。如果你怀疑两个变量
A和B存在伪共享，可以尝试在它们之间插入大的填充字节，强制将它们隔离到不同的缓存行，然后重新运行性能测试。如果性能有显著提升（例如30%以上），那么伪共享的可能性就极大。
3.2 代码审查与内存布局分析
在代码层面，你需要审视那些被多个线程频繁写入的“热点”数据。
- 识别共享数据结构：找到那些被定义在同一个类或结构体中，又被不同线程频繁修改的成员变量。特别是那些在循环中被不断更新的计数器、状态标志、数组元素等。
- 计算偏移量与对齐：使用
offsetof宏或直接打印地址来计算变量在结构体中的偏移量。结合编译器的对齐规则（可以使用alignas或编译器属性如__attribute__((aligned(64)))），推断它们是否可能位于同一个缓存行。#include <cstddef> #include <iostream> struct SuspiciousStruct { int thread1_data; int thread2_data; }; int main() { std::cout << "Offset of thread1_data: " << offsetof(SuspiciousStruct, thread1_data) << std::endl; std::cout << "Offset of thread2_data: " << offsetof(SuspiciousStruct, thread2_data) << std::endl; // 如果两者差值小于64字节，且结构体实例被多线程共享，风险就很高。 return 0; } - 审查数组的多线程访问模式：一个经典的伪共享场景是“线程私有”数组。例如，你声明了一个
int data[NUM_THREADS]，希望每个线程操作自己的下标data[thread_id]。这些数组元素在内存中是连续存放的，data[0]和data[1]很可能在同一个缓存行。如果线程0写data[0]，线程1写data[1]，伪共享就发生了。
3.3 使用专用工具进行验证
对于追求确凿证据的场景，可以使用更专业的工具：
perf c2c(Linux)：这是perf工具中专门用于检测伪共享的功能。它可以分析缓存行争用，直接告诉你哪些缓存行是“热点”，以及哪些线程和函数地址在争夺它。这是定位伪共享的“银弹”。
报告会列出“缓存行”、“偏移量”、“权重”等信息，直接指向引发问题的内存地址和代码。# 记录程序运行时的缓存事件 perf c2c record -a ./your_multi_threaded_program # 生成分析报告 perf c2c report- Valgrind 的 Cachegrind 工具：虽然主要模拟缓存层次，但其输出可以辅助分析缓存未命中的模式，间接提示伪共享的可能性。
定位伪共享是一个结合性能数据、代码逻辑和内存知识的推理过程。通常是从性能异常入手，通过代码审查缩小范围，最后用工具或实验来验证。
4. 解决伪共享的实战策略与代码示例
找到了问题，接下来就是解决问题。解决伪共享的核心思想就一条：让被不同线程频繁写入的变量，彼此之间的距离至少超过一个缓存行的大小（通常是64字节），确保它们不会被加载到同一个缓存行中。下面介绍几种常用的实战策略。
4.1 策略一：缓存行对齐与填充
这是最直接、最经典的方法。通过编译器扩展或C++11/17的标准属性，强制变量或结构体按缓存行边界对齐，并在变量间插入无用的填充字节。
方法1：使用编译器扩展（GCC/Clang）
struct AlignedCounter { long long a; char padding1[64 - sizeof(long long)]; // 填充到64字节边界 long long b; // 如果需要，可以继续填充以确保结构体大小是缓存行的整数倍 } __attribute__((aligned(64))); // 强制整个结构体64字节对齐 // 或者针对单个变量 long long a __attribute__((aligned(64))); long long b __attribute__((aligned(64)));方法2：使用C++11/17标准alignas
#include <cstddef> // C++17 提供了硬件缓存行大小的常量（通常是64） #ifdef __cpp_lib_hardware_interference_size static constexpr std::size_t hardware_destructive_interference_size = std::hardware_destructive_interference_size; #else // 保守估计，通常为64 static constexpr std::size_t hardware_destructive_interference_size = 64; #endif struct AlignedCounter { alignas(hardware_destructive_interference_size) long long a; alignas(hardware_destructive_interference_size) long long b; }; // 或者更精细的填充 struct PaddedCounter { long long a; char padding[hardware_destructive_interference_size - sizeof(long long)]; // 现在b肯定在下一个缓存行 long long b; };实操心得：
alignas是更现代、可移植性更好的方式。std::hardware_destructive_interference_size是C++17引入的，它提供了编译器估算的缓存行大小，比硬编码64更科学。如果你的编译器不支持C++17，硬编码64对于x86平台也基本没问题。填充时要注意，不仅要让a和b的起始地址在不同缓存行，还要确保它们各自独占的写入区域不会溢出到对方的缓存行。对于比缓存行小的类型，用alignas对齐其本身即可。
4.2 策略二：重新设计数据布局
有时，填充字节会浪费大量内存，特别是当有大量实例时。更好的方法是从数据结构设计上就避免伪共享。
线程局部存储：如果变量本质上是线程私有的，只是被错误地放在了共享结构里，那么应该使用线程局部存储。C++11提供了
thread_local关键字。// 每个线程都有自己的实例，根本不存在共享，彻底杜绝伪共享 thread_local long long my_private_counter = 0;但要注意，
thread_local变量在线程启动时构造，结束时析构，访问速度可能略慢于栈变量，且不适合需要在线程间聚合结果的场景。分离热点数据：将会被不同线程频繁写入的成员变量拆解到不同的结构体或类中，让它们从源头上就不在同一个内存块里。
// 优化前：伪共享高风险 class SharedData { int stats_from_thread_a; int stats_from_thread_b; // ... 其他数据 }; // 优化后：分离热点 class ThreadAData { int stats; // 仅线程A写入 // ... }; class ThreadBData { int stats; // 仅线程B写入 // ... }; // 主结构体持有指针或引用 class SharedData { ThreadAData* data_a; ThreadBData* data_b; // ... 其他共享只读或低频写数据 };这样，
data_a和data_b在堆上分配，地址通常离得很远，自然不在同一缓存行。数组访问的优化：对于前面提到的“线程私有数组”场景，不要简单地用
int data[NUM_THREADS]。应该让每个元素独占一个缓存行。constexpr size_t CACHE_LINE_SIZE = 64; constexpr size_t PADDING = CACHE_LINE_SIZE / sizeof(int); // 假设int是4字节，则需要16个int占满一行 struct PaddedInt { int value; int padding[PADDING - 1]; // 填充剩下的空间 }; // 或者使用对齐的原子类型（见策略三） std::atomic<int> data[NUM_THREADS] alignas(CACHE_LINE_SIZE); // 更推荐：每个线程使用独立的、对齐的变量，而非数组。
4.3 策略三：利用原子操作与内存序
当共享变量是计数器或标志位，且必须被多线程原子访问时，我们通常使用std::atomic。幸运的是，C++标准库考虑到了伪共享。
std::atomic的填充：在现代C++标准库实现中，std::atomic类型通常已经包含了一些填充来避免伪共享，尤其是对于像std::atomic_flag这样的类型。但为了绝对安全，特别是自定义的原子结构体，仍需手动对齐。struct AtomicCounters { alignas(64) std::atomic<long long> a{0}; alignas(64) std::atomic<long long> b{0}; };选择合适的内存序：解决伪共享主要是数据布局问题，但与之相关的原子操作内存序选择也影响性能。对于频繁修改的计数器，如果不需要严格的全局顺序，使用
std::memory_order_relaxed可以获得最佳性能，因为它减少了内存屏障带来的开销。// 线程1 counter.a.fetch_add(1, std::memory_order_relaxed); // 线程2 counter.b.fetch_add(1, std::memory_order_relaxed);注意：
memory_order_relaxed只保证原子操作本身的原子性，不提供线程间的同步顺序。它适用于独立的计数器场景。如果a和b的修改存在某种“发生前”关系需要被其他线程观察到，则必须使用更强的内存序，如memory_order_release/acquire。
4.4 策略评估与选型建议
没有一种策略是万能的，需要根据具体场景权衡：
| 策略 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| 缓存行对齐/填充 | 直接有效，修改简单 | 浪费内存，可能增加缓存占用，降低缓存利用率 | 热点变量少，结构固定，内存不敏感的场景 |
| 重新设计数据布局 | 从根本上解决问题，内存利用率高 | 可能需要重构代码，设计复杂度增加 | 新的项目或允许较大改动的重构 |
| 线程局部存储 | 彻底消除共享，性能极佳 | 数据生命周期与线程绑定，线程间聚合数据麻烦 | 纯线程私有数据，无需在线程间实时同步 |
| 原子操作与对齐 | 标准库支持好，适合并发原语 | 仅适用于原子变量，填充可能仍需手动 | 高频原子计数器、状态标志 |
通用建议：在项目初期进行并发设计时，就应有意识地将可能被不同线程频繁写入的数据分开。对于性能关键的代码段，在代码审查中加入“伪共享风险”检查项。在优化阶段，使用perf c2c等工具进行验证，做到有的放矢。
5. 实战案例：性能优化前后对比与深度分析
让我们通过一个具体的、可编译运行的例子，直观感受伪共享带来的性能损耗以及优化后的效果。我们将实现一个简单的多线程计数器累加程序。
5.1 存在伪共享的基准版本
// baseline.cpp - 存在伪共享的版本 #include <iostream> #include <vector> #include <thread> #include <chrono> #include <atomic> struct SharedData { std::atomic<long long> a{0}; std::atomic<long long> b{0}; }; void worker_a(SharedData& data, int iterations) { for (int i = 0; i < iterations; ++i) { data.a.fetch_add(1, std::memory_order_relaxed); } } void worker_b(SharedData& data, int iterations) { for (int i = 0; i < iterations; ++i) { data.b.fetch_add(1, std::memory_order_relaxed); } } int main() { const int iterations = 100'000'000; // 1亿次操作 SharedData data; auto start = std::chrono::high_resolution_clock::now(); std::thread t1(worker_a, std::ref(data), iterations); std::thread t2(worker_b, std::ref(data), iterations); t1.join(); t2.join(); auto end = std::chrono::high_resolution_clock::now(); auto duration = std::chrono::duration_cast<std::chrono::milliseconds>(end - start); std::cout << "Counter a: " << data.a.load() << std::endl; std::cout << "Counter b: " << data.b.load() << std::endl; std::cout << "Baseline time: " << duration.count() << " ms" << std::endl; return 0; }在这个版本中，a和b是std::atomic<long long>，各占8字节。它们被紧密地打包在SharedData结构体中，大小只有16字节，因此必然位于同一个64字节的缓存行内。两个线程分别疯狂地累加a和b，就会触发剧烈的缓存行乒乓。
5.2 使用缓存行对齐的优化版本
// optimized.cpp - 使用对齐消除伪共享 #include <iostream> #include <vector> #include <thread> #include <chrono> #include <atomic> #include <new> // 为了 std::hardware_destructive_interference_size // 尝试使用C++17的标准缓存行大小，否则回退到64 #ifdef __cpp_lib_hardware_interference_size static constexpr std::size_t CACHE_LINE_SIZE = std::hardware_destructive_interference_size; #else static constexpr std::size_t CACHE_LINE_SIZE = 64; #endif struct AlignedSharedData { alignas(CACHE_LINE_SIZE) std::atomic<long long> a{0}; alignas(CACHE_LINE_SIZE) std::atomic<long long> b{0}; }; void worker_a(AlignedSharedData& data, int iterations) { for (int i = 0; i < iterations; ++i) { data.a.fetch_add(1, std::memory_order_relaxed); } } void worker_b(AlignedSharedData& data, int iterations) { for (int i = 0; i < iterations; ++i) { data.b.fetch_add(1, std::memory_order_relaxed); } } int main() { const int iterations = 100'000'000; AlignedSharedData data; // 验证对齐 std::cout << "Size of struct: " << sizeof(AlignedSharedData) << " bytes" << std::endl; std::cout << "Address of a: " << &data.a << std::endl; std::cout << "Address of b: " << &data.b << std::endl; std::cout << "Difference: " << reinterpret_cast<char*>(&data.b) - reinterpret_cast<char*>(&data.a) << " bytes" << std::endl; // 差值应该 >= CACHE_LINE_SIZE auto start = std::chrono::high_resolution_clock::now(); std::thread t1(worker_a, std::ref(data), iterations); std::thread t2(worker_b, std::ref(data), iterations); t1.join(); t2.join(); auto end = std::chrono::high_resolution_clock::now(); auto duration = std::chrono::duration_cast<std::chrono::milliseconds>(end - start); std::cout << "Counter a: " << data.a.load() << std::endl; std::cout << "Counter b: " << data.b.load() << std::endl; std::cout << "Optimized time: " << duration.count() << " ms" << std::endl; return 0; }这个版本的关键在于alignas(CACHE_LINE_SIZE)。它强制编译器将a和b的地址对齐到缓存行的起始位置。由于每个缓存行是64字节，对齐后a和b的地址差至少是64字节，从而保证了它们位于不同的缓存行。
5.3 性能对比与结果分析
我在一台搭载 Intel i7-12700H（6P+8E核心）的笔记本上，使用g++ -O2 -std=c++17 -pthread编译并运行了这两个程序。为了减少偶然误差，每个程序运行了5次取中位数。
运行结果摘要：
| 版本 | 运行时间 (中位数) | 相对性能 |
|---|---|---|
| 基准版本 (存在伪共享) | ~520 毫秒 | 1.0x (基准) |
| 优化版本 (缓存行对齐) | ~180 毫秒 | ~2.9倍 |
结果分析：
- 性能提升显著：优化后的版本速度提升了近3倍！这清晰地展示了伪共享对性能的巨大破坏力。注意，这仅仅是两个线程操作两个独立计数器的场景。在实际应用中，如果热点更多、竞争更激烈，性能差距会更大。
- 地址验证：优化版本的输出显示，
a和b的地址差是64字节，证实了它们被成功隔离到不同的缓存行。 - 资源开销：优化版本的结构体
AlignedSharedData大小是128字节（两个对齐的8字节原子变量，各占一个64字节缓存行），而基准版本只有16字节。这是用空间换时间的典型 trade-off。在内存敏感的场景，需要谨慎评估。
这个案例有力地证明，对于高频并发写入的共享变量，即使逻辑独立，也必须考虑物理内存布局的影响。忽视伪共享，你的多线程程序可能一直在“假装努力”。
6. 进阶话题、陷阱与最佳实践
解决了基本的伪共享问题后，还有一些进阶场景和容易忽略的陷阱需要关注。
6.1 动态分配内存的对齐问题
使用new或malloc分配的内存，其对齐方式通常是保证适合任何标量类型（如alignof(std::max_align_t)），但这不一定等于缓存行对齐（64字节）。如果你动态创建了一个需要缓存行对齐的结构体，必须使用支持对齐的分配方式。
// 错误：普通new不保证64字节对齐 AlignedSharedData* pData = new AlignedSharedData; // 可能未对齐！ // 正确：使用C++17的带对齐参数的new AlignedSharedData* pData = new (std::align_val_t{64}) AlignedSharedData; // ... 使用 pData delete pData; // 注意：需要匹配的delete，但带对齐的delete比较复杂 // 更推荐：使用std::aligned_alloc (C++17) 或 posix_memalign (Linux) #include <cstdlib> void* ptr = std::aligned_alloc(64, sizeof(AlignedSharedData)); AlignedSharedData* pData = new (ptr) AlignedSharedData(); // 原位构造 // ... 使用 pData->~AlignedSharedData(); // 显式析构 std::free(ptr); // 释放内存重要提示：动态内存的对齐处理容易出错，且与平台相关。如果可能，尽量在栈上或作为类成员使用对齐的结构体。如果必须动态分配，务必仔细查阅编译器和标准库文档。
6.2 伪共享的“近亲”：真共享与锁争用
伪共享需要和另外两个多线程性能问题区分开：
- 真共享：多个线程真正读写同一块数据（同一个变量），需要通过锁或原子操作进行同步。这是逻辑上的竞争，解决方法是优化锁粒度、使用无锁数据结构或减少共享。
- 锁争用：多个线程竞争同一把锁，导致串行执行。解决方法是使用更细粒度的锁、读写锁或无锁编程。
伪共享的特殊性在于，数据在逻辑上不共享，但在物理缓存上共享。它的解决方案（内存布局调整）与真共享和锁争用截然不同。在性能调优时，需要先用工具（如perf）分析出瓶颈类型，再对症下药。
6.3 编译器优化与“意外”的共享
编译器为了优化，可能会进行结构体字段重排、内存合并等操作。有时你以为分开的变量，可能会被编译器“优化”到靠近的位置。使用alignas是告诉编译器你的对齐意图，通常编译器会尊重。对于极度敏感的场景，可以查阅编译器的文档，使用#pragma pack等指令来控制打包行为，但要注意可移植性。
另外，“相邻”的独立变量也可能导致伪共享。例如，两个全局变量int global_x;和int global_y;，如果它们在编译单元中定义顺序相邻，且链接器将它们放在相近的地址，也可能落入同一缓存行。对于这种场景，也需要考虑对齐。
6.4 最佳实践清单
根据我的经验，遵循以下实践可以最大程度避免伪共享：
- 设计阶段隔离热点：在设计多线程数据结构时，有意识地将会被不同线程频繁写入的字段分开。考虑使用指针间接引用，或者直接设计成线程局部的。
- 对高频写入的原子变量进行对齐：对于
std::atomic类型的计数器、标志位，养成使用alignas(64)的习惯。 - 谨慎使用紧凑数组存储线程私有数据：避免使用
int per_thread_data[N]。使用std::vector<std::atomic<int>>并对每个元素对齐，或者为每个线程分配独立的内存块。 - 利用线程局部存储：对于生命周期与线程一致、无需在线程间实时同步的私有数据，优先使用
thread_local。 - 性能测试与 profiling：将并发性能测试纳入常规流程。使用
perf c2c、VTune等工具定期检查缓存行争用情况。 - 了解你的硬件：缓存行大小并非总是64字节（虽然在x86上几乎是标准）。ARM架构可能有32字节或128字节的缓存行。使用
std::hardware_destructive_interference_size来获取可移植的估计值。 - 权衡内存与速度：对齐和填充会浪费内存，可能降低缓存利用率（因为有用的数据密度下降了）。在内存带宽受限或缓存容量很小的场景（如嵌入式系统），过度填充可能适得其反。需要基于实际 profiling 进行权衡。
伪共享是一个典型的“底层细节影响高层性能”的问题。它要求C++开发者不仅关注代码的逻辑正确性，还要对底层硬件如何执行代码有一定的了解。掌握其原理和解决方法，是编写高性能并发C++程序的必备技能。希望这篇长文能帮你彻底理清这个问题，下次当你的多线程程序性能不如预期时，能多一个强有力的排查和优化武器。
