C++ CPU 缓存一致性与伪共享（False Sharing）：并发性能杀手与优化

各位观众，各位朋友，各位同行，大家好！今天咱们聊点儿刺激的——CPU缓存一致性与伪共享！这俩哥们儿，一个管秩序，一个专门捣乱，都是并发编程里绕不开的坑。如果你写的并发程序慢得像蜗牛，那很可能就是它们在背后搞鬼。

第一章：CPU缓存——速度与激情的碰撞

想象一下，CPU就像个超级计算器，速度快到飞起。但是，它和内存之间隔着十万八千里，数据传输速度慢得让人抓狂。怎么办？聪明的人类发明了CPU缓存！

CPU缓存就像CPU的小金库，把常用的数据放进去，CPU要用的时候直接从金库里拿，速度嗖嗖的！缓存分好几级，L1、L2、L3，L1最快最小，L3最慢最大。

// 假设我们有个简单的结构体
struct Data {
    int a;
    int b;
};

// CPU访问Data.a的时候，会把Data整个缓存行都加载到缓存里

这里，Data结构体的数据会被加载到一个缓存行中。缓存行是缓存的基本单位，通常是64字节（也可能是其他大小，取决于CPU架构）。

第二章：缓存一致性——维持秩序的警察叔叔

好了，现在每个CPU都有自己的小金库了，问题来了：如果多个CPU同时修改同一个数据，那大家的金库里的数据就不一样了，乱套了！

这时候，缓存一致性协议就派上用场了。它就像警察叔叔一样，负责维持各个缓存之间的数据一致性，保证大家看到的数据都是最新的。

最常见的缓存一致性协议是MESI协议，它定义了缓存行的四种状态：

• Modified (M)： 缓存行被修改过，并且只有当前CPU拥有最新数据。
• Exclusive (E)： 缓存行只有当前CPU拥有，并且数据是最新的，与内存一致。
• Shared (S)： 缓存行被多个CPU共享，数据是最新的，与内存一致。
• Invalid (I)： 缓存行无效，需要从内存或其他CPU缓存中重新加载。

举个栗子：

1. CPU A 从内存中读取数据 X，缓存行状态变为 E。
2. CPU B 也从内存中读取数据 X，CPU A 和 CPU B 的缓存行状态都变为 S。
3. CPU A 修改了数据 X，CPU A 的缓存行状态变为 M，CPU B 的缓存行状态变为 I。
4. CPU B 想要读取数据 X，发现缓存行无效，需要从 CPU A 的缓存中获取最新数据，或者从内存中重新加载。

这个过程看似简单，但背后却隐藏着大量的缓存同步操作，比如缓存失效、数据传输等等。这些操作会消耗大量的CPU时间，影响程序的性能。

第三章：伪共享——隐藏在阴影中的并发性能杀手

现在，我们已经了解了CPU缓存和缓存一致性协议。接下来，要介绍今天的主角之一——伪共享。

伪共享是指多个线程/CPU核心访问不同的数据，但这些数据恰好位于同一个缓存行中，导致缓存一致性协议频繁地进行缓存同步操作，从而降低程序的性能。

struct Counter {
    int count1;
    int count2;
};

Counter counter;

// 线程1
void thread1() {
    for (int i = 0; i < 1000000; ++i) {
        counter.count1++;
    }
}

// 线程2
void thread2() {
    for (int i = 0; i < 1000000; ++i) {
        counter.count2++;
    }
}

在这个例子中，count1和count2虽然是不同的变量，但是它们位于同一个Counter结构体中，很可能被分配到同一个缓存行中。当thread1修改count1时，会导致thread2所在的缓存行失效，thread2需要重新从内存或者thread1的缓存中加载数据。反之亦然。这样，两个线程表面上操作的是不同的数据，实际上却在争夺同一个缓存行，导致大量的缓存同步操作，性能大幅下降。

可以用下面的表格来总结一下伪共享的特点：

特点	说明
数据位置	多个线程/核心访问的数据位于同一个缓存行中。
表面独立	线程/核心操作的是不同的数据，逻辑上没有依赖关系。
缓存行争用	线程/核心之间争用同一个缓存行，导致频繁的缓存失效和数据传输。
性能下降	缓存一致性协议带来的额外开销，导致程序性能大幅下降。

第四章：实战演练——揪出伪共享的真凶

光说不练假把式，现在咱们来实际测试一下伪共享的影响。

#include <iostream>
#include <thread>
#include <chrono>
#include <vector>

using namespace std;
using namespace std::chrono;

// 没有填充的结构体
struct Counter {
    int count1;
    int count2;
};

// 填充后的结构体，避免伪共享
struct PaddedCounter {
    int count1;
    char padding[60]; // 假设缓存行大小为64字节
    int count2;
};

// 测试函数
template <typename T>
void test_counter(T& counter) {
    auto start = high_resolution_clock::now();

    thread t1([&]() {
        for (int i = 0; i < 100000000; ++i) {
            counter.count1++;
        }
    });

    thread t2([&]() {
        for (int i = 0; i < 100000000; ++i) {
            counter.count2++;
        }
    });

    t1.join();
    t2.join();

    auto end = high_resolution_clock::now();
    auto duration = duration_cast<milliseconds>(end - start);

    cout << "Duration: " << duration.count() << " ms" << endl;
}

int main() {
    Counter counter;
    PaddedCounter padded_counter;

    cout << "Without padding:" << endl;
    test_counter(counter);

    cout << "With padding:" << endl;
    test_counter(padded_counter);

    return 0;
}

这段代码分别测试了没有填充和填充后的Counter结构体。运行结果可能会让你大吃一惊：

Without padding:
Duration: 2500 ms (大概，取决于你的CPU)
With padding:
Duration: 1200 ms (大概，取决于你的CPU)

可以看到，填充后的结构体性能提升了一倍！这就是伪共享的威力。

第五章：解决之道——见招拆招，化解伪共享危机

既然伪共享这么可怕，那我们该如何避免它呢？别慌，方法有很多：

1. 填充（Padding）： 这是最常用的方法。在可能发生伪共享的数据之间填充足够的空间，使它们位于不同的缓存行中。就像上面的例子一样。

   struct PaddedData {
       int data;
       char padding[60]; // 确保数据位于独立的缓存行
   };

2. 数据对齐： 确保数据按照缓存行大小对齐。有些编译器提供了指令来控制数据对齐。

   #pragma pack(push, 64) // 强制按照64字节对齐
   struct AlignedData {
       int data;
   };
   #pragma pack(pop) // 恢复默认对齐方式

   但要注意，过度使用数据对齐可能会导致内存浪费。

3. 线程本地存储（Thread-Local Storage）： 为每个线程分配一份独立的数据副本，避免多个线程访问同一份数据。

   thread_local int thread_local_data;

4. 数组重排： 如果你使用的是数组，可以尝试重新排列数组元素的顺序，使频繁访问的元素位于相邻的位置，减少缓存行的争用。

5. 使用并发容器： 某些并发容器内部已经考虑了伪共享的问题，并进行了优化。例如，std::atomic在某些情况下可以避免伪共享。

选择哪种方法取决于具体的应用场景。一般来说，填充是最简单有效的方法，但可能会增加内存消耗。线程本地存储适用于每个线程都需要独立的数据副本的场景。数组重排需要仔细分析数据的访问模式。使用并发容器可以简化代码，但可能牺牲一定的灵活性。

第六章：深入剖析——伪共享的底层原理

为了更好地理解伪共享，我们还需要深入了解它的底层原理。

当一个CPU核心修改了某个缓存行中的数据时，会通知其他CPU核心，使它们对应的缓存行失效。这个过程涉及到复杂的总线协议和缓存一致性协议。

例如，在MESI协议中，当CPU A修改了数据，它会发送一个“Invalidate”消息给其他拥有该缓存行的CPU核心。其他CPU核心收到消息后，会将对应的缓存行标记为Invalid，下次访问该数据时需要重新从内存或者CPU A的缓存中加载。

这个过程会产生以下开销：

• 总线带宽占用： invalidate消息需要在总线上广播，占用总线带宽。
• 缓存失效开销： 其他CPU核心需要将缓存行标记为Invalid，并可能需要重新加载数据。
• 延迟： invalidate消息的传播和数据加载都需要时间，导致延迟增加。

这些开销累积起来，就会对程序的性能产生显著影响。

第七章：调试技巧——定位伪共享的利器

如何才能知道自己的程序是否存在伪共享呢？别担心，有一些工具可以帮助我们定位伪共享的真凶。

• 性能分析工具： Intel VTune Amplifier、perf等性能分析工具可以帮助我们分析程序的缓存行为，找出缓存失效频繁的代码段。
• 缓存模拟器： 缓存模拟器可以模拟CPU缓存的行为，帮助我们理解缓存一致性协议的细节。
• 代码审查： 仔细审查代码，找出可能发生伪共享的数据结构和访问模式。

第八章：总结与展望——与伪共享斗智斗勇

CPU缓存一致性和伪共享是并发编程中不可忽视的问题。理解它们的原理，掌握解决之道，才能写出高性能的并发程序。

虽然伪共享很可怕，但只要我们足够了解它，就能有效地避免它。记住，好的并发程序不是一蹴而就的，需要不断的学习、实践和优化。

未来的CPU架构可能会采用更先进的缓存一致性协议，甚至采用新的内存模型来解决伪共享的问题。但是，理解CPU缓存的原理和缓存一致性协议仍然是并发编程的基础。

希望今天的分享能帮助大家更好地理解CPU缓存一致性和伪共享，并在实际工作中避免这些坑。谢谢大家！

附录：常见CPU缓存行大小

不同的CPU架构，缓存行的大小可能不同。以下是一些常见CPU架构的缓存行大小：

CPU架构	缓存行大小 (字节)
Intel x86-64	64
AMD x86-64	64
ARM	64 或 128

可以使用以下代码来获取缓存行大小：

#include <iostream>
#include <limits>

int main() {
    std::cout << "Cache line size: " << std::numeric_limits<unsigned long>::max() << std::endl; // This is not the correct way to get cache line size.

    // A more reliable method depends on the specific operating system and architecture.
    // For example, on Linux:
    // #include <unistd.h>
    // long cache_line_size = sysconf(_SC_LEVEL1_DCACHE_LINESIZE);
    // std::cout << "Cache line size (Linux): " << cache_line_size << std::endl;

    return 0;
}

请注意，上面的代码只是一个示例，实际获取缓存行大小的方法取决于具体的操作系统和架构。在Linux系统中，可以使用sysconf(_SC_LEVEL1_DCACHE_LINESIZE)函数来获取L1数据缓存的缓存行大小。 在windows中，可以使用GetLogicalProcessorInformation函数。