解析 ‘Cache Line Padding’：如何在 C++ 结构体中手动插入填充字节以彻底消除并发下的‘伪共享’？

各位同学，大家好。今天我们将深入探讨一个在高性能并发编程中至关重要，却又常常被忽视的性能陷阱——伪共享（False Sharing），以及如何通过一项直接而有效的技术——缓存行填充（Cache Line Padding），来彻底消除它。在现代多核CPU架构下，理解并掌握这项技术，对于构建高效、可伸缩的并发系统至关重要。

一、现代CPU架构与性能瓶颈

在进入正题之前，我们首先需要对现代CPU的内存访问模型有一个基本的认识。当今的计算机系统，CPU的速度与主内存（RAM）的速度之间存在着巨大的鸿沟。CPU执行指令的速度以纳秒计，而访问主内存则可能需要数十甚至数百纳秒。为了弥补这种速度差异，并提高数据访问效率，CPU引入了多级缓存（Cache）机制。

1. CPU缓存层次结构

典型的CPU缓存结构分为三级：

• L1 Cache (一级缓存)：离CPU最近，速度最快，容量最小（通常几十KB），每个核心独享。通常又分为指令缓存（L1i）和数据缓存（L1d）。
• L2 Cache (二级缓存)：比L1慢，容量稍大（几百KB到几MB），通常每个核心独享或几个核心共享。
• L3 Cache (三级缓存)：比L2慢，容量最大（几MB到几十MB），通常所有核心共享。

数据从主内存加载到L3，再到L2，最后到L1。CPU访问数据时，会首先检查L1，如果命中则立即使用；否则检查L2，以此类推。如果所有缓存都未命中，则需要从主内存加载，这将导致显著的性能延迟。

2. 缓存行（Cache Line）

CPU缓存并非以单个字节为单位进行数据传输，而是以固定大小的块进行。这个块就是缓存行（Cache Line）。

• 单位传输：当CPU需要访问内存中的某个字节时，它会一次性将包含该字节的整个缓存行从主内存加载到缓存中。
• 典型大小：在大多数现代x86和ARM架构处理器上，缓存行的大小通常是64字节。有些系统可能是32字节或128字节。
• 空间局部性：缓存行的设计利用了程序的空间局部性原理——如果一个内存位置被访问，那么它附近的内存位置很可能在不久的将来也被访问。

例如，如果一个int变量（4字节）被访问，那么其所在的64字节缓存行会被加载。即便你只用了4字节，其余60字节也一同被加载。

二、缓存一致性协议与伪共享的根源

多核处理器在共享内存的系统中运行时，必须确保所有核心对同一内存地址的视图是一致的。这就是缓存一致性（Cache Coherency）问题，由各种缓存一致性协议来维护，其中最著名的是 MESI协议（Modified, Exclusive, Shared, Invalid）及其变种（如MOESI）。

简而言之，当一个核心修改了其缓存中的某个数据时，它会通知其他核心，使其他核心中该数据对应的缓存行失效（Invalidate）。这样，其他核心在下次访问该数据时，就会发现自己的缓存已失效，从而从主内存（或拥有最新数据的其他核心缓存）重新加载最新数据。

伪共享（False Sharing）正是这种缓存一致性机制的“副作用”或“陷阱”。

1. 伪共享的定义

伪共享是指：当两个或多个独立的变量（即它们在逻辑上互不相关，由不同的线程独立访问和修改）恰好位于同一个缓存行中时，即使它们被不同的线程独立修改，也会由于缓存一致性协议的存在，导致该缓存行在不同核心的缓存之间来回“弹跳”，从而引发频繁的缓存失效和重载，严重降低程序性能。

之所以称之为“伪（False）”，是因为变量本身并没有被共享，它们是独立的。真正的共享是多个线程访问同一个变量。伪共享仅仅是因为它们在内存布局上“不幸”地共用了同一个缓存行。

2. 伪共享的工作机制

假设我们有两个独立的变量 X 和 Y，它们分别由线程 A 和线程 B 独立修改，且 X 和 Y 恰好位于同一个缓存行 CL1 中。

1. 初始状态：CL1 可能不在任何核心的缓存中，或者在两个核心的缓存中都处于 Shared 状态。
2. 线程 A 修改 X：
   • 线程 A 的核心将 CL1 加载到其L1缓存中。
   • 线程 A 修改 X。根据MESI协议，该核心会发送消息，使其在其他核心中缓存的 CL1 副本变为 Invalid 状态。
   • CL1 在线程 A 的核心中变为 Modified 状态。
3. 线程 B 修改 Y：
   • 线程 B 的核心尝试修改 Y。它发现其L1缓存中的 CL1 副本是 Invalid 状态。
   • 线程 B 的核心必须从线程 A 的核心（如果 CL1 仍在其缓存中）或者主内存（如果线程 A 的核心已将 CL1 写回主内存）获取 CL1 的最新副本。
   • CL1 被加载到线程 B 的核心的L1缓存中。
   • 线程 B 修改 Y。同样，线程 B 的核心会发送消息，使 CL1 在线程 A 的核心中的副本变为 Invalid 状态。
   • CL1 在线程 B 的核心中变为 Modified 状态。
4. 循环往复：当线程 A 再次修改 X 时，它会发现自己的 CL1 副本又失效了，需要重新加载。这个过程不断重复，导致 CL1 在两个核心之间频繁地“弹跳”，每一次弹跳都伴随着缓存失效、内存总线流量增加和数据重载的巨大开销。

这个“弹跳”过程，术语上称为缓存行颠簸（Cache Line Bouncing）。它会抵消多核并行带来的大部分性能优势，甚至可能使并行程序的性能比串行程序更差。

三、识别伪共享

伪共享是一个隐蔽的性能问题，因为它不会导致程序崩溃或逻辑错误，只会降低性能。因此，识别它通常需要借助专业的性能分析工具。

1. 伪共享的症状

• 意外的性能下降：并发部分的性能远低于预期，即使增加了线程数也无法有效提升。
• 高缓存未命中率：特别是L2和L3缓存的未命中率异常高。性能分析工具可以显示这些指标。
• 高内存总线流量：由于缓存行频繁在核心之间传输，导致内存总线变得非常繁忙。
• CPU利用率假象：CPU利用率可能看起来很高，但实际有效工作量低，大部分时间浪费在等待数据加载上。

2. 识别工具

• Intel VTune Amplifier：一个功能强大的性能分析器，可以识别缓存利用率问题，包括伪共享。
• Linux perf 命令：通过 perf stat -e cache-misses,L1-dcache-load-misses,LLC-load-misses ... 等命令可以观察缓存未命中事件。
• Windows Performance Monitor (PerfMon)：可以监控一些系统级的缓存计数器。
• 手动代码审查和内存布局分析：如果怀疑某个数据结构可能存在伪共享，可以通过查看其内存布局，结合缓存行大小进行初步判断。

四、解决方案：缓存行填充（Cache Line Padding）

消除伪共享的核心思想是：确保由不同线程独立修改的变量，始终位于不同的缓存行中。 缓存行填充正是实现这一目标的直接手段。

1. 缓存行填充的原理

缓存行填充的原理非常简单：在可能引发伪共享的变量之后，手动插入足够数量的无用字节（填充字节），将下一个变量“推”到下一个缓存行的起始位置。

假设缓存行大小为 CL_SIZE 字节（例如64字节）。

• 如果一个变量 var1 占用了 S1 字节，并且它需要被线程 A 独立修改。
• 如果紧随其后的变量 var2（占用 S2 字节）需要被线程 B 独立修改。
• 为了防止伪共享，我们需要在 var1 之后插入 CL_SIZE - (S1 % CL_SIZE) 字节的填充（如果 S1 是 CL_SIZE 的倍数，则填充 CL_SIZE 字节）。这样 var2 就会从一个新的缓存行开始。

2. 确定填充大小

• 硬编码缓存行大小：最常见且通常有效的方法是假设缓存行大小为64字节。这是一个普遍的安全选择，因为它涵盖了大多数现代CPU。

• C++17 std::hardware_destructive_interference_size：C++17标准引入了 std::hardware_destructive_interference_size，它是一个 std::size_t 类型的常量，表示“为了避免破坏性干扰（即伪共享）而需要保持的两个独立对象之间的最小偏移量”。这是推荐的、最可移植的方法。它的值通常是缓存行的大小。

  #include <iostream>
  #include <new> // For std::hardware_destructive_interference_size
  
  int main() {
      std::cout << "std::hardware_destructive_interference_size: "
                << std::hardware_destructive_interference_size << " bytesn";
      // On many systems, this will print 64
      return 0;
  }

五、在C++中实现缓存行填充

在C++中，我们主要通过两种方式实现缓存行填充：手动插入 char 数组，并结合 alignas 关键字确保结构体或其成员的起始地址对齐到缓存行边界。

1. 基本手动填充与 alignas

为了彻底消除伪共享，不仅要插入填充字节，还要确保被隔离的结构体或其关键成员的起始地址是缓存行对齐的。alignas 关键字（C++11及更高版本）正是为此而生。

alignas(N) 指示编译器将变量或类型的数据对齐到 N 字节的边界。

让我们来看一个简单的例子：一个计数器结构体。

#include <atomic>
#include <thread>
#include <vector>
#include <chrono>
#include <iostream>
#include <numeric> // For std::accumulate
#include <new>     // For std::hardware_destructive_interference_size

// 假设缓存行大小为64字节，或者使用C++17的常量
#ifdef __cpp_lib_hardware_interference_size
    constexpr std::size_t CACHE_LINE_SIZE = std::hardware_destructive_interference_size;
#else
    constexpr std::size_t CACHE_LINE_SIZE = 64; // Fallback for older C++ standards or compilers
#endif

// --- 方案一：存在伪共享的结构体 ---
struct Counter_FalseSharing {
    std::atomic<long long> value; // 8 bytes on most systems
}; // Total size: 8 bytes. If an array of these, they will pack tightly.

// --- 方案二：使用缓存行填充消除伪共享的结构体 ---
// 使用 alignas 确保结构体本身从缓存行边界开始
struct alignas(CACHE_LINE_SIZE) Counter_Padded {
    std::atomic<long long> value; // 8 bytes
    // 填充字节，确保 value 之后的数据（或下一个 Counter_Padded 实例）
    // 位于新的缓存行。
    // 填充大小 = CACHE_LINE_SIZE - (sizeof(std::atomic<long long>) % CACHE_LINE_SIZE)
    // 如果 sizeof(std::atomic<long long>) 正好是 CACHE_LINE_SIZE 的倍数，
    // 则取 CACHE_LINE_SIZE，防止填充为0导致下一个元素紧随其后。
    // 更准确地说，我们想让这个结构体占据一个完整的缓存行，
    // 即使内部只有8字节的value，也要填充到CACHE_LINE_SIZE。
    char pad[CACHE_LINE_SIZE - sizeof(std::atomic<long long>)];
}; // Total size: CACHE_LINE_SIZE bytes (e.g., 64 bytes)

解释：

• Counter_FalseSharing 结构体只包含一个 std::atomic<long long>，其大小通常是8字节。如果我们创建一个 Counter_FalseSharing 数组，那么每隔8字节就会有一个新的计数器。这意味着在64字节的缓存行中，将有8个计数器紧密排列。如果不同线程修改这8个计数器中的任意两个，就可能发生伪共享。
• Counter_Padded 结构体使用 alignas(CACHE_LINE_SIZE) 确保每个 Counter_Padded 实例都从一个缓存行的起始地址开始。
• char pad[...] 数组用于填充 value 成员之后的所有剩余空间，直到填满整个缓存行。这样，每个 Counter_Padded 实例都将独占一个完整的缓存行。当数组 padded_counters[NUM_THREADS] 被创建时，每个 padded_counters[i] 都会位于一个独立的缓存行中，从而彻底消除伪共享。

注意： 填充字节的计算 CACHE_LINE_SIZE - sizeof(std::atomic<long long>) 必须确保结果是非负数。由于 std::atomic<long long> 通常只有8字节，而 CACHE_LINE_SIZE 通常是64字节，所以这个计算是安全的。如果 sizeof(T) 恰好是 CACHE_LINE_SIZE 的倍数，那么 CACHE_LINE_SIZE - sizeof(T) 可能会导致填充为0。如果目标是让每个实例独占一个缓存行，那么即使 sizeof(T) 已经是 CACHE_LINE_SIZE 的倍数，也应该填充 CACHE_LINE_SIZE 字节，或者更精确地，确保下一个元素至少在 CACHE_LINE_SIZE 偏移处。然而，对于大多数小于缓存行的基本类型，直接减法是有效的。

2. 泛型填充技术

我们可以将填充逻辑封装到一个模板结构体中，以便更通用地使用。

template <typename T, std::size_t CacheLineSize = CACHE_LINE_SIZE>
struct alignas(CacheLineSize) PaddedValueWrapper {
    T value;
    // 确保填充字节的数量是正数。
    // 如果 T 的大小正好是 CacheLineSize 的倍数，那么 pad_size 应该为 0。
    // 否则，填充到下一个 CacheLineSize 边界。
    // 但是，为了确保 *整个Wrapper* 占据一个完整的CacheLine，
    // 并且下一个Wrapper从新的CacheLine开始，最简单的方式是填充到CacheLineSize。
    static_assert(sizeof(T) <= CacheLineSize, "PaddedValueWrapper is intended for types smaller than or equal to a cache line.");
    char pad[CacheLineSize - sizeof(T)];

    // 转发构造函数
    template<typename... Args>
    PaddedValueWrapper(Args&&... args) : value(std::forward<Args>(args)...) {}

    // 允许隐式转换为 T&
    operator T&() { return value; }
    operator const T&() const { return value; }
};

// 使用示例：
// PaddedValueWrapper<std::atomic<long long>> my_padded_counter;
// my_padded_counter.value.fetch_add(1);

这个 PaddedValueWrapper 的设计意图是让 value 独占一个缓存行。它确保整个 PaddedValueWrapper 实例的大小为 CacheLineSize 字节，并且由于 alignas，它会从一个缓存行边界开始。

六、实践案例：消除计数器数组的伪共享

现在，让我们通过一个实际的例子来演示伪共享的性能影响以及缓存行填充如何解决它。我们将创建两个计数器数组：一个没有填充（存在伪共享），一个经过填充（消除伪共享）。然后，让多个线程分别递增它们各自的计数器，并比较两种情况下的执行时间。

#include <atomic>
#include <thread>
#include <vector>
#include <chrono>
#include <iostream>
#include <numeric> // For std::accumulate
#include <new>     // For std::hardware_destructive_interference_size

// 确定缓存行大小，优先使用 C++17 标准常量
#ifdef __cpp_lib_hardware_interference_size
    constexpr std::size_t CACHE_LINE_SIZE = std::hardware_destructive_interference_size;
#else
    constexpr std::size_t CACHE_LINE_SIZE = 64; // Fallback for older C++ standards or compilers
#endif

// -----------------------------------------------------------------------------
// 方案一：存在伪共享的计数器结构体
// -----------------------------------------------------------------------------
struct Counter_FalseSharing {
    std::atomic<long long> value; // 通常为 8 字节
};

// -----------------------------------------------------------------------------
// 方案二：使用缓存行填充消除伪共享的计数器结构体
// -----------------------------------------------------------------------------
// 使用 alignas 确保结构体本身从缓存行边界开始
struct alignas(CACHE_LINE_SIZE) Counter_Padded {
    std::atomic<long long> value; // 通常为 8 字节
    // 填充字节，确保此结构体独占一个缓存行。
    // sizeof(std::atomic<long long>) 保证小于 CACHE_LINE_SIZE。
    // 填充大小 = CACHE_LINE_SIZE - 实际数据大小
    char pad[CACHE_LINE_SIZE - sizeof(std::atomic<long long>)];
};

// -----------------------------------------------------------------------------
// 性能测试函数
// -----------------------------------------------------------------------------
template <typename T_Counter>
void run_test(const std::string& test_name, int num_threads, long long iterations_per_thread) {
    // 创建计数器数组
    // 注意：如果是动态分配的数组，也需要确保其起始地址是缓存行对齐的。
    // 对于 std::vector，其内部数据通常是自然对齐的，但可能不是缓存行对齐。
    // 为了确保这一点，我们可以使用 std::aligned_alloc 或自定义分配器，
    // 或者对于小数组，直接使用 alignas 声明局部数组。
    // 这里为了简化，我们假设 T_Counter 的 alignas 会在数组元素层面生效。
    // 对于 std::vector<T_Counter>，T_Counter 内部的 alignas 会影响 T_Counter 的对齐，
    // 但 vector 本身的数据块起始地址不一定缓存行对齐。
    // 为了更严谨，这里使用原始数组，或者使用 C++17 的 std::vector<T, std::allocator<T>> 
    // 配上 std::pmr::polymorphic_allocator<T> 和 std::pmr::aligned_allocator。
    // 但为了示例清晰，我们这里使用了一个假设其内部元素已经通过其类型定义对齐的 vector。
    // 更安全的方法是：
    // std::vector<std::byte> buffer(num_threads * sizeof(T_Counter) + CACHE_LINE_SIZE -1);
    // T_Counter* counters = reinterpret_cast<T_Counter*>(std::align(CACHE_LINE_SIZE, num_threads * sizeof(T_Counter), buffer.data(), buffer.size()));
    // 但这会引入复杂性。对于演示目的，我们可以先用一个简化的。

    std::vector<T_Counter> counters(num_threads);

    // 初始化计数器
    for (int i = 0; i < num_threads; ++i) {
        counters[i].value = 0;
    }

    std::vector<std::thread> threads;
    auto start_time = std::chrono::high_resolution_clock::now();

    for (int i = 0; i < num_threads; ++i) {
        threads.emplace_back([&counters, i, iterations_per_thread]() {
            for (long long j = 0; j < iterations_per_thread; ++j) {
                counters[i].value.fetch_add(1, std::memory_order_relaxed);
            }
        });
    }

    for (auto& t : threads) {
        t.join();
    }

    auto end_time = std::chrono::high_resolution_clock::now();
    std::chrono::duration<double> duration = end_time - start_time;

    long long total_value = 0;
    for (int i = 0; i < num_threads; ++i) {
        total_value += counters[i].value.load(std::memory_order_relaxed);
    }

    std::cout << "Test: " << test_name << "n";
    std::cout << "  Threads: " << num_threads << ", Iterations per thread: " << iterations_per_thread << "n";
    std::cout << "  Total expected value: " << num_threads * iterations_per_thread << "n";
    std::cout << "  Total actual value:   " << total_value << "n";
    std::cout << "  Time taken: " << duration.count() * 1000 << " msn";
    std::cout << "--------------------------------------------------n";
}

int main() {
    std::cout << "Detected CACHE_LINE_SIZE: " << CACHE_LINE_SIZE << " bytesn";
    std::cout << "Size of Counter_FalseSharing: " << sizeof(Counter_FalseSharing) << " bytesn";
    std::cout << "Size of Counter_Padded: " << sizeof(Counter_Padded) << " bytesnn";

    int num_threads = std::thread::hardware_concurrency(); // 获取CPU核心数
    if (num_threads == 0) num_threads = 4; // 至少保证4个线程
    long long iterations_per_thread = 100'000'000; // 每个线程进行1亿次递增

    // 运行存在伪共享的测试
    run_test<Counter_FalseSharing>("False Sharing Test", num_threads, iterations_per_thread);

    // 运行消除伪共享的测试
    run_test<Counter_Padded>("Cache Line Padding Test", num_threads, iterations_per_thread);

    return 0;
}

编译和运行：

为了获得准确的性能数据，请使用优化选项编译（例如 g++ -O3 -std=c++17 -pthread your_program.cpp -o your_program）。

预期结果：

您会观察到 Counter_Padded 版本的执行时间显著低于 Counter_FalseSharing 版本。在多核系统上，性能提升可能会达到数倍甚至十倍以上。

示例输出（具体数值因硬件而异，但趋势一致）：

Detected CACHE_LINE_SIZE: 64 bytes
Size of Counter_FalseSharing: 8 bytes
Size of Counter_Padded: 64 bytes

Test: False Sharing Test
  Threads: 8, Iterations per thread: 100000000
  Total expected value: 800000000
  Total actual value:   800000000
  Time taken: 1547.89 ms
--------------------------------------------------
Test: Cache Line Padding Test
  Threads: 8, Iterations per thread: 100000000
  Total expected value: 800000000
  Total actual value:   800000000
  Time taken: 115.34 ms
--------------------------------------------------

从上面的示例输出中，我们可以清晰地看到，在8个线程各自进行1亿次递增操作时，存在伪共享的Counter_FalseSharing版本耗时超过1.5秒，而经过缓存行填充的Counter_Padded版本仅耗时约115毫秒。这展示了缓存行填充在消除伪共享方面带来的巨大性能提升，性能提升了约13倍！

七、考虑事项与最佳实践

缓存行填充虽然强大，但并非万能药，也并非总是最佳选择。它有其适用场景和需要权衡的利弊。

1. 内存开销

缓存行填充会显著增加数据结构占用的内存。例如，一个8字节的 long long 计数器，经过填充后可能占用64字节。如果您的数据结构非常庞大，或者需要创建大量实例，这种内存开销可能成为问题。

结构体类型	实际数据大小	填充字节数	总大小（假设64字节缓存行）
Counter_FalseSharing	8 bytes	0 bytes	8 bytes
Counter_Padded	8 bytes	56 bytes	64 bytes

2. 何时应用？

• 性能瓶颈分析：绝不要在未经性能分析的情况下盲目应用缓存行填充。只有当您通过性能分析工具（如VTune、perf）明确诊断出伪共享是导致性能下降的主要原因时，才考虑使用此技术。过早的优化是万恶之源。
• 高并发写入：当多个线程频繁地对逻辑上独立但物理上相邻的内存位置进行写操作时，伪共享最容易发生并产生最大的负面影响。如果主要是读操作，或者写入频率很低，伪共享的影响会小很多。
• 数据结构特点：通常影响的是数组中的元素、结构体中的字段，或者其他紧密排列的数据。

3. 可移植性

• std::hardware_destructive_interference_size (C++17) 是最可靠和可移植的方式来获取缓存行大小。如果您的编译环境不支持C++17或更高版本，或者该常量未实现，则回退到硬编码的64字节是一个合理的通用选择，因为它适用于大多数主流桌面和服务器CPU。
• 请注意，嵌入式系统或某些特殊架构可能有不同的缓存行大小。

4. 结构体对齐的重要性

仅仅在结构体内部填充是不够的。您还需要确保结构体实例本身的起始地址是缓存行对齐的。这就是 alignas(CACHE_LINE_SIZE) 关键字的作用。对于动态分配的内存，您可能需要使用 std::aligned_alloc (C++17) 或自定义分配器来确保对齐。

// 示例：动态分配对齐内存
#include <cstdlib> // For std::aligned_alloc, std::aligned_free
#include <memory>  // For std::unique_ptr

// ... (Counter_Padded definition as before) ...

int main() {
    int num_threads = 8;
    // 分配 num_threads 个 Counter_Padded 实例所需的对齐内存
    void* raw_memory = std::aligned_alloc(CACHE_LINE_SIZE, num_threads * sizeof(Counter_Padded));
    if (!raw_memory) {
        // Handle allocation failure
        return 1;
    }

    // 使用 unique_ptr 管理内存，确保自动释放
    // 自定义 deleter，因为 std::aligned_alloc 需要 std::aligned_free
    std::unique_ptr<Counter_Padded[], decltype(&std::aligned_free)>
        padded_counters(reinterpret_cast<Counter_Padded*>(raw_memory), &std::aligned_free);

    // 在分配的内存上构造对象
    for (int i = 0; i < num_threads; ++i) {
        new (&padded_counters[i]) Counter_Padded(); // Placement new
        // 确保 value 被初始化，比如为0
        padded_counters[i].value = 0;
    }

    // ... 执行多线程递增操作 ...

    // 在释放内存前，销毁对象（如果 Counter_Padded 有非平凡析构函数）
    // 对于像 Counter_Padded 这样的 POD 类型，通常不需要显式销毁
    // for (int i = 0; i < num_threads; ++i) {
    //     padded_counters[i].~Counter_Padded(); // Explicit destructor call
    // }

    // unique_ptr 会在超出作用域时自动调用 std::aligned_free
    return 0;
}

5. 数据布局优化

除了填充，更宏观的数据布局策略也值得考虑：

• 按线程分组数据：如果可能，将由同一个线程频繁访问的所有数据尽可能地放在一起，以提高缓存局部性。
• 分离读写数据：将频繁被多个线程读取但只被一个线程写入的数据，与频繁被多个线程写入的数据分开。
• thread_local 存储：如果一个变量真正是线程私有的，并且不需要与其他线程共享，那么 thread_local 关键字是更简单、更安全的解决方案，它天生就消除了伪共享的风险。

6. 替代方案

• 减少共享：重新设计算法，尽可能减少线程之间的数据共享。
• 局部拷贝后汇总：每个线程在本地操作数据副本，然后在某个同步点将结果汇总回共享数据结构。
• 使用专门的数据结构：一些并发数据结构（如无锁队列、哈希表）在设计时已经考虑了缓存局部性和伪共享问题。

八、更进一步的思考

1. std::hardware_constructive_interference_size

与 std::hardware_destructive_interference_size 相对的是 std::hardware_constructive_interference_size。它表示“为了优化构造性干扰（即提高缓存局部性）而建议将相关对象打包在一起的最小大小”。这意味着，如果一组数据经常被同一个线程一起访问，并且它们的大小之和小于或等于 std::hardware_constructive_interference_size，那么将它们紧密地放在一起（例如，在一个没有填充的结构体中）可以提高性能，因为它们很可能被加载到同一个缓存行中。

2. 编译器优化与填充

现代编译器非常智能，但在处理缓存行填充时，它们通常会遵循您显式指定的 alignas 和 char 数组。编译器不会自动为您插入伪共享填充，因为这会改变数据结构的大小，而编译器无法在没有明确指令的情况下做出这样的内存布局决策。

总结

伪共享是多核并发编程中一个隐蔽而强大的性能杀手。它源于CPU缓存一致性协议在处理独立变量共享同一缓存行时的“副作用”。通过在结构体中手动插入填充字节并结合 alignas 关键字，我们可以有效地将由不同线程独立修改的变量隔离到不同的缓存行中，从而彻底消除伪共享。

这项技术虽然简单，但其对性能的影响可能是巨大的。然而，它也伴随着内存开销，因此应始终在性能分析的指导下，并权衡利弊后，谨慎地应用于关键的性能敏感代码段。理解并恰当运用缓存行填充，是每一位追求高性能C++并发编程的开发者必备的技能。