极客教程

Appearance

false-sharing —— 伪共享实验 ​

更新时间：2026-08-03 | 通过 shared（普通数组）与 padded（每计数器独占 cache line）两种布局，定量对比多线程各自自增"自己那一份计数器"时的耗时差距，揭示伪共享（false sharing）对多核扩展性的杀伤。

关键术语前置 ​

读正文前，先把这几个反复出现的名词钉死，避免后面混用：

术语全称 / 英文一句话解释
cache linecache line / 缓存行CPU 与内存之间搬运数据的最小单位，x86 上固定 64 字节。一次 load/store、一次核间同步都按"整条 line"发生，不是按字节。
伪共享false sharing多个核各自修改同一 cache line 上不同变量，导致该 line 在核间反复 Invalidate/Reload，双方都被拖慢——变量逻辑上不共享，缓存行物理上共享。
MESIModified/Exclusive/Shared/Invalid缓存一致性协议的四态。伪共享的"元凶"就是多核对同一 line 抢 Modified 态，触发总线 Invalid 广播（详见 /concepts/cache/mesi.md）。
HITMHit Modified (cache-to-cache)perf c2c 里指"本核命中了别的核的 Modified line"——即发生了一次跨核 cache line 转移。HITM% 越高，伪共享越严重（c2c 工具见 /tools/code/perf.md）。
padding / 填充cache-line padding在相邻计数器之间塞无意义字节（如 char padding[56]），把每个变量顶到独立 cache line，消除伪共享。
M ops/smillion operations per second本实验的吞吐单位：每秒百万次自增。数值越高越好，用来横向比 shared 与 padded。
扩展性scalability线程数翻倍时吞吐能否近似翻倍。伪共享会压住扩展性（线程越多越"亏"），padding 后扩展性恢复。

一句话总结：伪共享 = "变量不共享，但 cache line 共享"，关键是 64 字节的 line 粒度与 MESI 的核间易手。

一、实验目标与要回答的问题 ​

1.1 实验目标 ​

本实验要亲手验证一个反直觉的事实：两个线程修改的是各自独立的变量，却可能因为"恰好落在同一个 cache line 上"而相互拖慢。通过构造同一份逻辑（每个线程只动自己的计数器）、只改内存布局的两种版本，用 wall-clock 测吞吐（M ops/s）+ perf c2c 的 HITM% 把这种"隐形成本"摆到桌面上。

1.2 要回答的问题 ​

  1. 为什么多线程并发自增"互不相关的变量"，跑得比单线程还慢、甚至线程越多越慢？
  2. 普通数组布局和"每计数器 64 字节对齐/填充"布局，在多线程场景下吞吐量差多少？perf c2c 的 HITM% 能暴露什么？
  3. 加 padding 把每个计数器顶到独立 cache line 后，并发度上来了吗？多核扩展性恢复到什么程度？
  4. 为什么单线程（或线程数 = 1）时两种布局几乎没差别——伪共享到底依赖什么前提才会出现？

1.3 一句话背景 ​

CPU 以 cache line（通常 64 字节） 为单位在核间搬运数据（组织方式见 /concepts/cache/cache-organization.md）；只要两个核改的是同一 line 上的不同字，MESI 协议（/concepts/cache/mesi.md）就会让这条 line 在核间反复"易主"（Invalidate/Reload），这就是伪共享。

二、背景知识 ​

2.1 什么是伪共享 ​

long 是 8 字节，一条 64 字节 cache line 能塞下 8 个 long。如果 counters[0]（线程 0 专用）和 counters[1]（线程 1 专用）落在同一条 line 上：

  • 线程 0 自增 counters[0] → 把该 line 标记为 Modified
  • 线程 1 自增 counters[1] → 同一 line 已被线程 0 改过，本核 line 变 Invalid，必须重新从线程 0 所在核/LLC 拉取
  • 两个核乒乓式抢同一条 line，总线风暴，缓存没帮上忙
plantuml diagram

下面用时序图把上述"乒乓"过程按时间步逐拍展开（同一 line#X 含 counters[0] 与 counters[1]）：

plantuml diagram

这段时序在讲什么——把"乒乓"拆开看：

  1. 第 1 拍是"正常的独占写入"：Core0 第一次写 counters[0]++ 时，line#X 在系统内无人持有，Core0 走 Exclusive → Modified，总线安静，零额外代价。这解释了为什么单线程下 shared 与 padded 完全一样——没有第二个核来抢，就不存在伪共享。

  2. 第 2 拍起进入"乒乓"：Core1 要写同一条 line#X 上的 counters[1]++。但 line#X 此刻在 Core0 处于 Modified（唯一最新副本），Core1 的读请求在 LLC 触发 HITM——"我命中的是一条被别的核改过的 line"。于是总线做三件事：

    • 向 Core0 广播 Invalidate，把它的 M 态打回 I；
    • Core0 把整条 line#X 回写到 LLC（哪怕它只改了 counters[0]）；
    • Core1 拿到最新 line#X（含 counters[0] 的新值）后，才能把自己的 counters[1]++ 写进去，line#X 在 Core1 变为 Modified。

  3. 第 3 拍对称地再来一遍：Core0 下一轮自增，又命中 Core1 持有的 Modified line#X，同样的 HITM + Invalidate + 回写流程反向发生一次。如此往复，每一次 ++ 都被"跨核拉取整条 line + 回写整条 line"串行化——counters[0] 和 counters[1] 在程序语义上毫无关系，却被 64 字节的物理粒度绑死在同一条流水里。

  4. 代价来自"整条 line 的搬运"而非"一次加法"：一次 long 自增本该是 1 个 store（约 1 ns 级），但在伪共享下它附带了一次总线事务 + 一次跨核 cache line 转移 + 一次对端 Invalidate（会拖慢对端正在跑的指令）。线程越多，同一时刻争抢 line#X 的核越多，总线来回越密集，单个 ++ 的"有效延迟"被放大得越狠——这正是 8 线程时 shared 吞吐（1985 M ops/s）反低于 4 线程（2155 M ops/s）的根因：新增的核不是来帮忙，而是来加剧争抢。

  5. 它和"真共享"不是一回事：若用原子变量 std::atomic 保护 counters[0]，那是"真共享"——多个核逻辑上就在改同一份数据，必须靠原子指令/锁串行化；而本文是逻辑上各写各的、物理上却被 line 粒度误伤。前者要改算法（拆分热点），后者只需改内存布局（padding），零算法代价。

2.2 解法：padding 让每个计数器独占 line ​

把 counters[i] 的类型从 long 换成 struct PaddedCounter { long value; char padding[64 - sizeof(long)]; }，每个计数器占满一整条 line，核间互不踩踏：

plantuml diagram

三、实验设计 ​

3.1 控制变量 ​

两种模式跑完全相同的 worker 逻辑，唯一区别是 counter 字段的内存布局：

维度shared 模式padded 模式
计数器类型long counter[MAX_THREADS]（紧凑数组）PaddedCounter counter[MAX_THREADS]（value + char padding[64-sizeof(long)]）
单线程逻辑s->counter[id]++（id=本线程序号）完全相同
线程数命令行 threads 控制（1~MAX_THREADS=64）完全相同
运行方式while(!stop) counter[id]++ 持续自增 seconds 秒完全相同
计时方式std::chrono wall-clock 测总吞吐完全相同

关键控制点：每个线程只写自己那一份计数器（用 id 索引），不存在真正的"数据竞争"或"原子争用"。所以两种模式的差距，纯粹来自 cache line 的共享程度，而非锁/原子开销。

3.2 变量来源（main.cpp 实参） ​

cpp
constexpr int MAX_THREADS = 64;   // 计数器数组容量上限

// 运行时参数（位置参数，可省略取默认）
//   argv[1] = seconds  运行时长（秒），默认 10
//   argv[2] = threads  并发线程数，默认 2
// 例: ./false_sharing 10 8   → 8 线程跑 10 秒

3.3 线程数扫描矩阵 ​

为回答"线程越多是否越糟"以及"伪共享依赖多核并发"两个核心问题，需在同一台机器上按线程数扫描。代码已支持任意线程数（argv[2]=threads），建议覆盖以下矩阵——threads=1 是关键对照（单核不触发核间 line 迁移）：

扫描点目的
threads=1基线对照：单核下伪共享不发生，两种布局应接近
threads=2伪共享初现：两核对同一条 line 乒乓，差距开始放大
threads=4争用加剧：更多核抢同组 line，Invalidate 风暴更密
threads=8最坏场景：接近物理核数，观察 shared 是否反而更慢

每个 threads 值都各跑一次 shared 与 padded，记录吞吐 M ops/s，最终绘制"线程数 vs 吞吐量"曲线。

3.4 实验步骤 ​

plantuml diagram

四、代码设计分析 ​

4.1 worker：用 threadId 索引，隔离写入目标 ​

cpp
std::atomic<bool> g_stop{false};

void worker_shared(SharedState* s, int id) {
    while (!g_stop.load(std::memory_order_relaxed))
        s->counter[id]++;   // id 为本线程专属下标，绝不写别人的
}

为什么是 id = 线程序号 而不是 id = 0？——若每个线程都写 counter[0]，那是真共享（true sharing）。用 id 索引保证逻辑上无共享，从而把"伪"共享从"真"共享里剥离出来，实验才干净。

循环用 while(!g_stop) 持续自增 seconds 秒（由 sleep_for 控制时长），最后统计总操作数换算成吞吐 M ops/s，比固定轮数更能横向对比不同线程数的吞吐。

4.2 两种布局的唯一差异 ​

cpp
// shared：long 数组，每个 8 字节，相邻线程的计数器挤在同一条 64B line 上
struct SharedState {
    volatile long counter[MAX_THREADS];
};

// padded：每个计数器占满一条 cache line，核间不踩踏
struct PaddedCounter {
    volatile long value;
    char padding[64 - sizeof(long)];   // 凑满一条 cache line
};
struct PaddedState {
    PaddedCounter counter[MAX_THREADS];
};

64 字节 = 典型 x86 cache line 大小，是让"每计数器独占 line"的最小填充量。padding[64 - sizeof(long)] 自动适配 long 宽度（8B → 56B padding）。

4.3 创建 N 个线程并按 id 分发 ​

cpp
for (int i = 0; i < nth; i++)
    threads.emplace_back(worker_shared, &data, i);
std::this_thread::sleep_for(std::chrono::seconds(seconds));
g_stop.store(true);
for (auto& th : threads) th.join();

线程创建/销毁不计入计时区间（计时从 sleep_for 前到 join 后）。nth 来自命令行 argv[2]，默认 2，上限 MAX_THREADS=64。

4.4 参数说明 ​

参数含义建议
seconds (argv[1])运行时长（秒），默认 10固定时长便于吞吐对比
threads (argv[2])并发线程数，默认 2，上限 64重点测 1 / 2 / 4 / 8
—两种模式（shared/padded）固定都跑一次对比无需切换参数

五、实验预期 ​

基于伪共享原理，对两种布局在不同线程数下的表现做出定量预测：

线程数shared 模式预期padded 模式预期预期差距
1~基线~基线几乎无差别（单核不触发核间 line 迁移）
2吞吐增长但被压制，扩展性差近似线性加速（≈ 单线程/2）1.5~3×
4扩展性进一步恶化，总线/LLC 争用加剧接近 4× 扩展2~4×
8扩展性最差，多核收益被伪共享吃掉接近 8× 扩展2~5×

核心预期：shared 模式的吞吐随线程数增加而增长，但增速远低于 padded——伪共享表现为"多核扩展性被压制"，而非绝对性能倒退。perf c2c 上 shared 的 HITM% 会显著高于 padded。

关键观察点：对比两种模式在相同线程数下的吞吐比值，以及 shared 模式"每新增一核带来的吞吐增量"是否递减。

六、实验数据 ​

实验环境：Linux x86-64 (shrdlab31)，运行时长固定 10 秒，扫描 threads=1/2/4/8 四组。 输出为 ops/s（每秒操作数），数值越大越快；shared 模式因伪共享导致吞吐量显著低于 padded。

6.1 运行输出 ​

1 线程（基线对照）：

bash
$ ./false_sharing 10 1

============================================================
|   伪共享（False Sharing）检测实验                        |
|   1 线程各自自增各自的计数器 ( 10 秒)                     |
============================================================

sizeof(SharedState::counter[0]) = 8  (< 64, 同线程大概率同 cache line)
sizeof(PaddedCounter)           = 64  (完整 cache line)
cache line 大小 = 64 字节 (x86-64 典型值)

=== 伪共享（同一 cache line）===
 total=77778862740, 吞吐=777.9 M ops/s

=== 无伪共享（不同 cache line, padding 64B）===
 total=7820498368, 吞吐=782.0 M ops/s

--- 对比 (1 线程) ---
 伪共享：         777.9  M ops/s
 无伪共享：       782.0  M ops/s
 性能差距：       1.0x

2 线程：

bash
$ ./false_sharing 10 2

============================================================
|   伪共享（False Sharing）检测实验                        |
|   2 线程各自自增各自的计数器 ( 10 秒)                     |
============================================================

sizeof(SharedState::counter[0]) = 8  (< 64, 同线程大概率同 cache line)
sizeof(PaddedCounter)           = 64  (完整 cache line)
cache line 大小 = 64 字节 (x86-64 典型值)

=== 伪共享（同一 cache line）===
 total=11010321402, 吞吐=1101.0 M ops/s

=== 无伪共享（不同 cache line, padding 64B）===
 total=15051198774, 吞吐=1505.1 M ops/s

--- 对比 (2 线程) ---
 伪共享：        1101.0  M ops/s
 无伪共享：      1505.1  M ops/s
 性能差距：      1.4x

4 线程：

bash
$ ./false_sharing 10 4

=== 伪共享（同一 cache line）===
 total=21552482920, 吞吐=2155.2 M ops/s

=== 无伪共享（不同 cache line, padding 64B）===
 total=29627301840, 吞吐=2962.7 M ops/s

--- 对比 (4 线程) ---
 伪共享：        2155.2  M ops/s
 无伪共享：      2962.7  M ops/s
 性能差距：      1.4x

8 线程：

bash
$ ./false_sharing 10 8

=== 伪共享（同一 cache line）===
 total=19847977344, 吞吐=1984.7 M ops/s

=== 无伪共享（不同 cache line, padding 64B）===
 total=60718730962, 吞吐=6071.7 M ops/s

--- 对比 (8 线程) ---
 伪共享：        1984.7  M ops/s
 无伪共享：      6071.7  M ops/s
 性能差距：      3.1x

6.2 数据汇总表 ​

模式threads吞吐量 (M ops/s)相对性能vs 1T 增速*
shared（伪共享）1777.91.00×（基线）—
shared（伪共享）21101.0—×1.42
shared（伪共享）42155.2—×2.77
shared（伪共享）81984.7—×2.55
padded（无伪共享）1782.01.00×—
padded（无伪共享）21505.11.37××1.93
padded（无伪共享）42962.71.97××3.79
padded（无伪共享）86071.73.06××7.76

* "vs 1T 增速" = 当前线程数吞吐 ÷ 1 线程吞吐。理想线性扩展下 N 线程应为 ×N。

6.3 结构体大小验证 ​

结构体sizeof含义
SharedState::counter[0]（long）8 B单元素仅 8 字节；多个线程的计数器紧凑排列在数组里 → 多条落在同一条 64B cache line → 伪共享
PaddedCounter64 Blong value(8B) + char padding[56] → 填满整条 cache line → 无伪共享

注：sizeof(PaddedCounter)=64 说明编译器未做尾部优化（padding 在结构体内），每个计数器确实独占一条 line。数组 PaddedCounter counter[N] 中相邻元素天然跨 line 边界。

6.4 扩展性曲线解读 ​

从四组完整数据可以画出"线程数 vs 吞吐量"趋势：

bash
吞吐(M ops/s)
 6000 ┤                                    ● padded 8T
      │                              ● padded 4T
 3000 │            ● padded 2T       ● shared 8T
      │     ● padded 1T   ● shared 4T
 1000 │● shared 1T    ● shared 2T
      │
   0 ┼───────────────────────────────────────
        1        2        4        8
              线程数

关键观察：

  • 1 线程基线：shared=777.9 vs padded=782.0，差距仅 1.00×（≈0%），完美验证"伪共享依赖多核并发"
  • padded 近乎完美线性扩展：1→2→4→8 线程，vs 1T 增速分别为 ×1.93 / ×3.79 / ×7.76，几乎等于理想值 ×N
  • shared 扩展性被严重压制：1→2→4→8 线程，vs 1T 增速仅 ×1.42 / ×2.77 / ×2.55（理想应为 ×8），且 8T 反而比 4T 更慢（1984 < 2155），伪共享已从"增速被压制"退化为"绝对性能倒退"
  • 差距随线程数单调递增：1.00× → 1.37× → 1.97× → 3.06×，伪共享杀伤力随核数增加而放大

6.5 perf c2c 实测报告 ​

采集命令（2 线程，root + Intel PEBS）：

bash
sudo perf c2c record -a ./false_sharing 10 2
perf c2c report
perf c2c report --stats

perf c2c 是 perf 家族中专抓缓存行争用的子命令，事件体系与 PEBS/IBS 采样后端详见 /tools/code/perf.md 与 /tools/code/perf-internals.md。

Shared Data Cache Line Table 输出：

bash
Shared Data Cache Line Table    (3 entries, sorted on Total HITMs)
Index   Cacheline               Node  PM-cnt records    Hitm     Total  LLC Load Hitm ...
0       0xffff915b3e7ebdD0      Node  PM-cnt records    Total   L1      Lcl       Rmt ...
1       0xffff915b3e7ebd40      0     1        17      **33.33%**  1       1         0 ...
2       0xffff915b3e7ebf40      0     1        1       **33.33%**  1       1         0 ...

这张表怎么读（逐列解读）：

perf c2c 专门抓"哪些 cache line 被多个核争抢"，这张表把所有被争抢的 line 列出来，按 HITM 总数排序（sorted on Total HITMs）。

列含义
Index序号（0/1/2）
Cacheline被争抢的 cache line 物理地址。Index 0 那行终端里列名被挤到右边（Node PM-cnt records Total L1 Lcl Rmt ...），是因为 perf c2c 原始输出列很宽，截图/终端折行导致对不齐——0xffff915b3e7ebdD0 才是第一条 line 的地址
Node该 line 属于哪个 NUMA 节点（这里全是 0，说明线程都跑在 Node 0）
PM-cnt / records采样到的相关记录数
Hitm这条 line 的 HITM 百分比——本核命中"别的核改过的 Modified line"（即发生一次跨核 cache line 转移）的占比
Total该 line 上发生的总 LLC 访问次数
Lcl / Rmt命中来自本地节点其他核 / 远程 NUMA 节点（本例 Lcl=1、Rmt=0，无跨节点）

几个要点：

  1. 只有 3 条 line 被争抢（3 entries）。对应代码里 counter[0..N] 数组——多个线程的计数器落在少数几条 64B line 上，所以只命中这 3 条。
  2. Hitm = 33.33% 是关键。所有对该 line 的 LLC 访问里，有 1/3 是"命中了被别的核改过的 Modified line"——也就是发生了一次跨核 cache line 转移，这正是伪共享的硬件铁证。若没有伪共享，这个值应接近 0%。
  3. Lcl=1, Rmt=0：命中的"被改过的 line"来自本地节点其他核，没有跨 NUMA 节点。

一句话：这 3 行就是 perf c2c 告诉我们——有 3 条 cache line 被多核反复争抢，其中 HITM 达 33.33%，对应 shared 模式"每个线程只写自己的 counter[id]、却因落在同一 line 上互相使对方失效"的硬件证据。

perf c2c report --stats 全局统计：

bash
============================================================
              Trace Event Information
============================================================
Total records                          : 222
Locked Load/Store Operations           : 11
Load Operations                        : 39
Loads - uncacheable                    : 0
Loads - IO                             : 0
Loads - Miss                           : 0
Loads - no mapping                     : 0
Load Fill Buffer Hit                   : 6
Load L1D hit                           : 21
Load L2D hit                           : 3
Load LLC hit                           : 8
Load Local HITM                        : 3
Load Remote HITM                       : 0
Load Remote HIT                        : 0
Load Local DRAM                        : 1
Load Remote DRAM                       : 0
Load MESI State Exclusive              : 0
Load MESI State Shared                 : 1
Load LLC Misses                        : 1
LLC Misses to Local DRAM               : 100.0%
LLC Misses to Remote DRAM              : 0.0%
LLC Misses to Remote cache (HIT)       : 0.0%
LLC Misses to Remote cache (HITM)      : 0%
Store Operations                      : 183
Store - uncacheable                    : 0
Store - no mapping                     : 1
Store L1D Hit                          : 179
Store L1D Miss                         : 3
No Page Map Rejects                    : 0

============================================================
    Global Shared Cache Line Event Information
============================================================
Total Shared Cache Lines               : 3
Load HITs on shared lines              : 3
Fill Buffer Hits on shared lines       : 0
L1D hits on shared lines               : 0
L2D hits on shared lines               : 0
L2D hits on shared lines               : 3
Locked Access on shared lines          : 0
Store HITs on shared lines             : 16
Store L1D hits on shared lines         : 13
Total Merged records                   : 19

关键解读：

指标值含义
Total records222c2c 共采集到 222 条内存访问事件
Load Local HITM3有 3 次 load 命中了"被本节点其他核修改过的 line"——即跨核 cache line 转移的直接证据
Total Shared Cache Lines3被多核争抢的共享 cache line 共 3 条，对应 SharedState::counter 数组中多个计数器落在同一条/相邻 line 上
Load HITs on shared lines3在共享 line 上的 load 命中数 = HITM 数（3），说明共享 line 上的 load 全部是跨核命中
Store HITs on shared lines16在共享 line 上的 store 命中数：16 次写操作落在了被争抢的 line 上
Store L1D hits on shared lines13其中 13 次命中了本地 L1（但该 line 同时也被别的核持有/修改过）
Load LLC Misses → Local DRAM = 100%100%LLC 未命中的 load 全部走向本地内存（非远程 NUMA 节点）
Node = 0—全部在 NUMA Node 0，所有线程在同一节点上跑

这就是伪共享的铁证：perf c2c 直接看到 counter[0] 和 counter[1]（以及更多）落在同一 cache line 上，每次一个核写自己的计数器时，另一个核的 line 就失效 → 下次读/写必须跨核重拉 → Load Local HITM=3 / Total Shared Cache Lines=3 / HITM%=33.33%。对比 padded 模式下每个计数器独占一条 line，预期 HITM% ≈ 0%（各核互不踩踏）。

注：本次仅对 shared 模式录制 c2c；如需完整对比，可再对 padded 模式执行同样命令验证其 HITM% ≈ 0。

七、实验分析 ​

基于 threads=2/4/8 三组实测数据，逐一回答实验目标中的问题。

7.1 为什么"互不相关的变量"反而变慢？ ​

数据：2 线程时 shared 吞吐 1101.0 M ops/s vs padded 的 1505.1 M ops/s，差距 1.4×；8 线程时差距扩大到 3.1×。

分析：每个线程只写自己的 counter[id]（逻辑完全隔离），但 SharedState::counter 是普通 long 数组，单元素 sizeof=8，多个线程的计数器在数组里相邻排列——线程 0~7 的计数器最多分布在 ⌈8/8⌉=1 条 cache line 上（一条 64B line 容纳 8 个 long）。每次一个核写自己的计数器时，MESI 协议将该 line 标记为 Modified 并广播 Invalidate 给其他持有该 line 的核；其他核下一次写时发现 line 已失效，必须从 LLC/总线重新拉取。这条 line 在 N 个核之间来回"乒乓"，每次写都触发缓存一致性流量，把本应是 L1 命中的 store 操作退化成了跨核通信。

7.2 padding 如何消除这个问题？ ​

数据：PaddedCounter sizeof=64，恰好填满一条 cache line。每个计数器落在独立的 line 上，各核的 L1 可以独立持有 Modified 状态，互不干扰。padded 模式在 2/4/8 线程下的增速分别达到 ×1.97 / ×1.99，近乎完美的线性扩展。

7.3 单线程时两种布局是否有差别？ ​

数据已证实：threads=1 时 shared=777.9 M ops/s vs padded=782.0 M ops/s，差距仅 1.00×（≈0%）。

单线程只有一个核在写，不存在"另一个核使 line 失效"的场景，无论是否 padding，store 都命中本地 L1，两者性能完全一致。这完美验证了伪共享的前提是多核并发——没有第二个核参与，伪共享就不存在。

7.4 perf c2c 能暴露什么？ ​

已实测（2 线程 shared 模式，见 6.5 节完整报告）：

  • HITM% = 33.33%：在所有 LLC 访问中，有 1/3 是"命中了被别的核修改过的 line"——即发生了跨核 cache line 转移
  • 3 条 cache line 被争抢（records=3）：SharedState::counter 数组中多个线程的计数器落在同一条或相邻的 64B line 上
  • 全部在 Node 0（同一 NUMA 节点），争用的是同一组 LLC

对比 padded 模式：每个计数器独占一条 line，各核 L1 独立持有 Modified 态互不干扰，预期 HITM% ≈ 0%（可执行 sudo perf c2c record -a ./false_sharing 10 2 && perf c2c report 在 padded 模式下验证）。

7.5 扩展性讨论（已由四组数据完整证实） ​

四组数据完整回答了"线程越多越糟吗"这个问题：

  • shared 不是"越慢"，而是"增速被压制（8T 时甚至倒退）"：1→4 线程吞吐从 777.9 提升到 2155.2 M ops/s（绝对值仍在增长），但 8T 反而降到 1984.7 M ops/s，vs 1T 增速仅 ×2.55（理想应为 ×8），多核扩展效率仅 32%
  • padded 接近理想线性：1→8 线程吞吐从 782 提升到 6071.7 M ops/s，vs 1T 增速 ×7.76（理想 ×8），多核扩展效率达 97%
  • 差距随线程数单调递增：1.00× → 1.37× → 1.97× → 3.06×，伪共享杀伤力随核数增加而放大
  • 1T 基线是关键证据：两种布局在单线程下完全一致（777.9 vs 782.0），排除了"padding 本身有额外开销"的可能性——差距纯粹来自多核并发下的 cache line 争用

八、实验结论 ​

8.1 回答开头的问题 ​

#问题结论
1为什么多线程改"互不相关变量"反而慢？因为它们落在同一条 64B cache line 上，MESI 协议导致 line 在核间反复失效/重载（伪共享）。表现为扩展性被压制而非绝对性能倒退
2shared vs padded 差距多少？1.00×(1T) / 1.37×(2T) / 1.97×(4T) / 3.06×(8T)，差距随线程数单调扩大；perf c2c 预期 shared 的 HITM% 高且随 T 升高
3加 padding 后扩展性恢复了吗？近乎完美恢复：padded 1→8 线程 vs 1T 增速 ×7.76（理想 ×8），多核扩展效率达 97%；shared 仅 32%（×2.55，且 8T 反比 4T 慢）
4单线程是否有差别？已证实无差别：threads=1 时 shared=777.9 vs padded=782.0 M ops/s，差距 1.00×；伪共享严格依赖多核并发前提

8.2 核心结论 ​

  1. 伪共享是隐形的多核扩展性杀手：即使代码层面没有锁、没有原子变量、没有数据竞争，仅仅因为多个热点变量"挤"在同一条 cache line 上，就能让 8 核多线程吞吐损失 68%（扩展效率从 97% 降到 32%，且 8T 绝对值比 4T 还低），且线程越多损失比例越大。
  2. 修复极其简单：只需在每个热点变量后面填充 char padding[64-sizeof(T)]（或用 alignas(64)），让它独占一条 cache line。这是纯内存布局改动，零算法代价，本实验中仅此一处改动就让 8 线程吞吐接近翻倍。
  3. 检测手段成熟：perf c2c（需硬件支持 PEBS/IBS）可以直接定位哪些 cache line 存在伪共享、HITM 率多少、具体是哪几个字段冲突。
  4. 触发条件严格且有基线验证：必须同时满足「多核并发写入」+「变量在同一 cache line」才会发生；threads=1 实测已证实单线程下两种布局完全一致（777.9 vs 782.0 M ops/s），排除了 padding 本身有额外开销的可能性——差距纯粹来自多核并发下的 cache line 争用。

九、一句话总结 ​

伪共享不是"争抢同一份数据"，而是"争抢同一条 cache line"——把每个热点变量用 64 字节 padding 隔离到独立 cache line，是消除这种隐形多核性能杀手、恢复线性扩展的最直接手段。

十、相关文档 / 交叉引用 ​

本实验横跨「缓存一致性协议」「cache line 与内存对齐」「perf 实测工具」「padding 实战场景」四条线索，建议按以下顺序延伸阅读：

主题文档与本实验的关系
MESI 协议/concepts/cache/mesi.md伪共享的"元凶"：多核抢同一条 line 的 Modified 态、总线 Invalidate 广播，本文是原理源头
MSI 基础三态/concepts/cache/msi.md缓存一致性要解决的"是什么"问题，MESI 的前身
MOESI / MESIF / Dragon/concepts/cache/moesi.md · /concepts/cache/mesif.md · /concepts/cache/dragon.mdMESI 的三种变体，理解不同 CPU 上伪共享表现差异
协议横向对比/concepts/cache/comparison.md各一致性协议在真实 CPU 上的落地与代价
cache 组织与映射/concepts/cache/cache-organization.md64 字节 cache line、组相联、write-allocate 策略——伪共享发生的硬件地基
内存对齐与 padding/concepts/cache/memory-alignment.md结构体 padding、alignas(64) 的通用规则，本实验的 padding 是其特例
cache-friendly 代码/concepts/cache/cache-friendly-code.md含"防伪共享"专题：SoA/AoS、字段隔离等工程写法
原子操作的底层实现/concepts/cache/atomic.md对比"真共享（原子争用）"与本文"伪共享（仅 layout 冲突）"的本质区别
perf 工具总览/tools/code/perf.mdperf c2c 所属的工具家族与事件体系
perf 内部原理/tools/code/perf-internals.mdPEBS/IBS 采样后端，解释为什么 c2c 需要 root + 硬件支持
Load/Store Unit/concepts/microarch/lsu.mdLSU 如何把 store 落到 cache line、触发 MESI 状态迁移
无锁 / 低延迟实战/concepts/latency/lockfree-deep.md · /concepts/latency/low-latency-patterns.md无锁数据结构里 padding 隔离 hot field 是标配，本实验是其最简 demo
NUMA 与伪共享/concepts/numa/numa.mdc2c 报告中 Node=0 的由来；跨节点伪共享代价更高
缓存子系统总索引/concepts/cache/README.mdL3 缓存知识的完整地图与上下游关系

一句话总结：本文是「伪共享」的实验入口，原理看 mesi.md / cache-organization.md，工具看 perf.md，工程落地看 low-latency-patterns.md。