缓存一致性与 False Sharing（MESI/MOESI）

• MESI 状态
• 写同一行
• 状态迁移

假设两核 P0、P1 都缓存了同一 cache line。初始 P0 若独占该行（E 状态），P0 写时无需通知，状态变 M（Modified）。当 P1 想读该行时，P0 在总线响应，把数据转发给 P1，P0 状态从 M 变 S（Shared），P1 得到 S。之后 P1 想写该行，需发出独占请求（invalidate），P0 收到后把状态从 S 变 I（Invalid），P1 独占并把数据从 S 变 M（Modified，可本地写）。若 P0 之后又读，需从 P1 获取，P0 变 S、P1 变 S。核心：写前必须 invalidate 其他副本（M 状态独占），写后 M，读共享变 S，被 invalidate 变 I。

MESI 的核心是"写需独占、读可共享"。写同一行时，持有者升级为 M 并 invalidate 他人，其他人收到 invalidate 变 I。这保证写操作的一致性。

• M 状态
• E 状态
• S 状态

MESI 四种状态：M（Modified，已修改）：本缓存持有的行是唯一副本且已被修改（dirty），与内存不一致，写回内存前需负责提供数据；E（Exclusive，独占）：本缓存持有唯一副本、与内存一致（clean），其他缓存无此副本，可无需通知直接升级为 M 写；S（Shared，共享）：多个缓存持有该行的一致副本，与内存一致，写前需 invalidate 其他副本；I（Invalid，无效）：本缓存无有效副本，访问需重新加载。M 与 E 的区别：M 是 dirty、E 是 clean，但两者都是唯一副本。E→M 无需总线事务，S→M 需要 invalidate。

MESI 用 M/E/S/I 编码"唯一性 + 是否修改"。E 是"独占但干净"，M 是"独占且脏"，S 是"共享",I 是"无效"。E→M 的免费升级是 MESI 提升 E 状态价值的关键。

• Owned 状态
• MOESI
• 写回避免

MOESI 在 MESI 基础上增加 O（Owned，拥有）状态。O 状态表示：本缓存持有该行（可能被修改，dirty），但其他缓存也有副本（均为 S），且本缓存是数据"所有者"，负贵在收到请求时提供最新数据。工程意义：O 状态允许"脏但共享"的行不必立即写回内存，其他缓存读时直接从 O 所有者获取数据，避免把脏数据写回内存再让其他人读（减少写回流量）。这优化了"一核多次写、其他核读"的场景，提高带宽效率。AMD 采用 MOESI，O 状态使共享场景下无需反复写回内存。

O 状态是 MOESI 的核心价值：允许"脏但共享"，由所有者提供数据，避免写回内存。这对多核共享频繁读的性能/带宽有显著改善。

• MOESI 增加 O
• MESIF 增加 F
• 一致性协议扩展

MOESI（AMD）相对 MESI 增加 O（Owned，拥有）状态：允许脏数据被共享，所有者提供数据，避免写回内存。MESIF（Intel）相对 MESI 增加 F（Forward，转发）状态：在多个 Shared 副本中标记一个为"转发者"，当其他核请求该行的数据时，由 F 状态的副本统一转发数据，避免多个 S 副本同时响应造成总线冲突。两者都解决"共享数据的响应方选择"问题：MOESI 用 Owner 提供脏数据，MESIF 用 Forwarder 统一转发干净数据。AMD 用 O，Intel 用 F，是两种不同的扩展思路。

O 和 F 都是"指定一个响应者"。MOESI 的 O 允许脏共享，MESIF 的 F 在干净共享中指定转发者。两者相较 MESI 各增一个状态，解决共享响应问题。

• cache coherence
• memory consistency
• 区别

cache coherence（缓存一致性）处理的是"单个数据地址（cache line）"的可见性：保证所有核看到同一地址的写入是一致的（同一地址的先后写有全局顺序，且写最终可见）。它不关心"多个地址之间的顺序"。memory consistency（内存一致性）处理的是"多个数据地址之间"的访问顺序（内存模型）：规定 load/store 在不同地址上的相对顺序约束（如 TSO 允许 store 后读、x86 的 store 顺序、ARM 的 relaxed）。简言之：coherence 是"单地址、同一缓存行"的一致性，consistency 是"多地址、跨变量的顺序"模型。coherence 是 consistency 的底层基础，consistency 定义更高级的程序可见顺序。

Coherence 管"同一地址"，Consistency 管"多地址顺序"。二者是不同层次：coherence 保证单行一致，consistency 定义跨行的内存序。这是并行编程容易混淆的概念。

• false sharing
• MESI
• bounce

false sharing（伪共享）指多个核各自访问同一 cache line 中"不同的变量/字段"，但因为缓存以 cache line 为单位，这些不同的字段被当作同一个一致性单元处理。在 MESI 下：核 A 写其字段时，需把该行提升为 M 并 invalidate 核 B 的副本；核 B 写自己字段时，又需 invalidate 核 A 的副本并把自己提升为 M。于是同一 cache line 在两个核间反复"弹跳"（bounce），每次切换都触发总线 invalidate 事务、cache miss，尽管两核访问的是毫不相干的字段。这就是伪共享：逻辑上无共享，物理上（同一行）却造成频繁一致性竞争，性能急剧下降。

伪共享的本质是"缓存行粒度 > 变量粒度"。MESI 以行管理一致性，不同字段同处一行就互相 invalidate，造成不必要的一致性流量与 miss。

• MSI 协议
• MESI 优势
• E 状态

MSI 只有 M/S/I 三态，缺少 E（Exclusive）状态。在 MSI 中，一个核首次读一个未共享的行，也进入 S 状态，之后写仍需发出 invalidate 总线事务（即使该核是唯一持有者）。MESI 增加 E 状态：当核独占该行（无其他副本）且干净时，进入 E，写时无需任何总线事务，直接从 E 升级为 M（免费升级）。这消除了"单核独占数据写前仍需 invalidate"的不必要开销，显著减少写一致性的总线事务。因此 MESI 相对 MSI 更高效，Intel 采用 MESI（及其扩展 MESIF）取代 MSI。

E 状态是 MESI 相对 MSI 的关键改进：允许"独占独享"的核免费升级为 M，避免读后写时的冗余 invalidate。这减少了总线事务、提升性能。

• Forward 状态
• MESIF
• 响应方选择

MESIF 中，F（Forward）状态用于标记多个 Shared 副本中的"带有转发资格"的那一个。当该行有多个 S 副本时，若有核发出读请求，为避免多个副本同时响应（共享总线冲突、响应不确定），MESIF 规定由 F 状态的副本统一响应（转发数据），其他 S 副本不响应。F 状态在总线被 Invalidated 后指定，保证"只有一个响应者"，有序、无冲突地提供数据。作用：在多核共享读的高频场景下，F 状态明确了数据提供者，避免总线竞争与响应二义性，简化一致性 snoop 逻辑。

F 状态解决"多个共享副本谁响应"的问题，指定唯一转发者，避免多响应冲突。它与 AMD 的 O 状态（脏数据所有者）互补，是 Intel 的共享响应方案。

• directory-based coherence
• AMD Zen
• 可扩展性

directory-based coherence（基于目录的一致性）通过维护一个"目录"记录每个 cache line 的持有者/共享者，缓存请求时只需通知目录、由目录转发/定位，避免 snoop 全广播，因此可扩展到更多核。AMD Zen 的 CCX（4 核）内部用 snoop 过滤/目录，CCX 之间通过 infinity fabric 和目录（MSI 到 L3 的目录）维护一致性。在 16 核内，Zen 用 L3 作为目录（记录各 L2/核的持有状态），目录能精确知道哪些核持有某行，从而定向 invalidate/转发，避免全局 snoop 广播，保证一致性并及时序。目录的一致性好、可扩展，Zen 的 L3 目录让 16 核甚至更多核都能高效维持一致性。

目录式一致性用"目录记录持有者"替代"全广播 snoop"，可扩展性好。Zen 用 L3 目录 + 分层（CCX 内 snoop、跨 CCX 目录）在 16 核内维持高效的 directory-based coherence。

• @Contended
• 缓存行填充
• false sharing 消除

@Contended（sun.misc.Contended，Lombok 也提供）告诉 JVM 对该字段/类做缓存行填充（padding），使被标注的字段独占一个或多个 cache line（JVM 在字段前后填充 padding 字节直到对齐到 64B 边界）。这样不同核访问的不同字段被放到不同 cache line，不再共享同一 cache line，从而消除 false sharing（不再因同处一行而互相 invalidate）。@Contended 自动在 JVM 层面处理 padding，比手动 padding 更干净、可维护。它以牺牲少量内存为代价，消除多核高频并发写不同字段时的缓存行 bounce。

@Contended 的本质是"自动缓存行填充"，把冲突字段隔离到不同行。它是 JVM 层面的 false sharing 消除方案，比手写 padding 更优雅。

• struct 对齐
• cache line
• 边界对齐

C struct 的字段按类型对齐（如 int 4B、double 8B），但缓存以 64B 行为单位。若 struct 的边界或频繁访问的字段横跨 cache line 边界，会导致一个 struct/字段被拆到两个 cache line，访问它需要加载两行，降低效率，且可能引发 false sharing/伪共享。因此高性能代码常用 attribute((aligned(64))) 或 posix_memalign 让 struct 起始地址对齐 64B，使 struct 整体落在单个 cache line 内，避免跨行。对高频并发写的字段，还会用 padding 让每个字段独占一行。cache line 对齐的目的是让数据访问与缓存行边界对齐，最大化局部性、避免跨行访问与伪共享。

64B cache line 与 struct 对齐的关系：struct 越大越可能跨行，对齐到 64B 边界可让 struct 落在单行内，减少跨行访问与伪共享。这是性能敏感 C/C++ 的常见优化。

• Disruptor
• cache line padding
• false sharing 消除

Disruptor（LMAX 的高性能无锁队列）大量使用 cache line padding 消除 false sharing。它把消费者序号、生产者序号等"高频被不同线程写/读"的字段用 padding 隔开（如在序号前后填充 7 个 long，使每个序号独占一个 64B cache line，并让序号本身对齐到 cache line 边界）。这样生产者核写序号、消费者核读序号就不会与其他热字段共享同一 cache line，避免互相 invalidate 造成的缓存行 bounce。Disruptor 的设计者明确用 padding 隔离"被多个线程竞争的 single-writer 字段"，使每个字段独立缓存行，最大化并发吞吐。

Disruptor 是 cache line padding 消除伪共享的经典案例：把高频并发字段隔离到独立缓存行，避免 bounce。这是无锁高并发框架的核心性能手艺。

• container_of
• cache line 对齐
• 性能优化

Linux kernel 的链表（list_head）和 container_of 宏用于把对象嵌入链表并回推对象指针。对高频访问的链表节点/对象，kernel 用 ____cacheline_aligned 等属性让对象对齐到 cache line 边界，理由：一是避免对象横跨 cache line，减少一次访问需要加载两行的开销；二是对多核并发访问的对象，cache line 对齐 + 合理布局可避免不同对象共享同一 cache line 造成 false sharing；三是配合 per-cpu 数据、锁等，让每个 CPU 的私有数据在独立 cache line，减少跨核一致性竞争。所以 cache line 对齐让链表/对象访问具有更好的局部性与更少的一致性竞争。

kernel 用 cache line 对齐优化链表/对象：避免跨行、减少伪共享、隔离 per-cpu 数据。这是内核性能关键路径的常见优化。

• long/double 非原子
• false sharing 根因
• 区别

Java 中 long/double 的"非原子写"（在 32 位 JVM 上可能分两次 32 位写，导致读到中间态）与 false sharing 是两回事。false sharing 的根因是"多个变量被放到同一 cache line，不同核访问不同变量但缓存行粒度导致互相 invalidate"，与变量的原子性无关。即使 long/double 写是原子的（64 位 JVM 上），只要两个变量同处一行且被不同核交替写，仍会产生 false sharing。非原子写是"数据竞争/撕裂读"问题，false sharing 是"缓存行粒度的一致性竞争"问题。二者机制不同，消除 false sharing 靠 padding 隔离，非原子写靠 volatile/原子类/64 位 JVM 解决。

false sharing 的根因是"缓存行粒度 + 变量共行"，与原子性无关。long/double 非原子是"撕裂"，是另一层面的数据竞争。混淆二者是常见误区。

• false sharing 带宽
• L3 带宽
• 消耗曲线

false sharing 对 L3 带宽的消耗遵循"随冲突线程数/写频率上升而上升"的曲线：当两个核交替写同一 cache line 的不同字段时，每次写都需要把该行从 L3（或另一核的 L1/L2）取回并 invalidate 对方副本，产生 L3 的往返访问与一致性流量。随着线程数增加（如 4 核、8 核都争抢同一行），L3 带宽消耗呈非线性增长，可能导致 L3 成为瓶颈，甚至出现"性能峰值后随线程数增加而下降"的曲线（因为一致性开销超过并行收益）。典型特征：false sharing 的带宽消耗与"写频率 × 参与核数"成正比，远高于真正共享（读多写少）或隔离（无共享）的场景。

false sharing 的带宽消耗随并发写核数与写频率上升，曲线陡增，可能使 L3 饱和、性能不升反降。这是 false sharing 危害的量化体现。

• NUMA
• 跨 die false sharing
• 延迟/带宽

NUMA（非均匀内存访问）架构中，不同 die（或 socket）有自己的内存控制器与 L3，跨 die 访问/一致性需要通过跨 die 互联（如 AMD Infinity Fabric、Intel UPI）进行。在 NUMA 中，false sharing 的跨 die 一致性流量要走较慢的跨 die 互联，比同 die 内（通过 L3/共享 snoop）的一致性延迟高得多、带宽也受限。因此跨 die 的 false sharing 每次缓存行 bounce 都要穿越低带宽、高延迟的互联，性能损失远大于同 die。跨 die 的缓存行 bounce 还占用有限、昂贵的互联带宽，进一步加剧瓶颈。

NUMA 跨 die 一致性命中跨 die 互联，延迟高、带宽低，故跨 die 的 false sharing 更严重。NUMA 下应尽量把共享数据本地化，避免跨 die 竞争。

• store buffer
• invalidation queue
• 内存屏障

为性能，x86 用 store buffer（写缓冲）暂存本核的写，使其不阻塞等待缓存一致性，导致本核写后读自己刚写的值可能读到旧值（写未提交到缓存）；invalidation queue（失效队列）缓存接收到的 invalidate 请求，延迟处理，使本核可能读到已被其他核 invalidate 但尚未处理的旧数据。这些异步机制破坏了"本核写后读、其他核写后读"的即时可见性（弱于强一致）。修复：lfence 保证本核 load 顺序；sfence 保证 store 顺序；mfence 同时保证 load/store 顺序，强制 store buffer 冲刷、invalidate 队列处理，使写对其他核可见、读看到最新值。锁前缀（lock）指令（如 lock xchg、lock add）隐含全屏障（类似 mfence），保证原子操作前后内存序，用于实现同步原语。通过屏障/锁，程序员在需要强一致的点强制 store buffer 与 invalidation queue 生效，恢复可见性。

store buffer 与 invalidation queue 是 x86 宽松内存序（TSO）的来源之一。mfence/lfence 强制冲刷队列，lock 前缀隐含全屏障，用于在关键点恢复可见性、保证同步正确。

• MESI 状态转换
• 总线事务
• 读/写请求

MESI 状态转换由总线事务驱动：读请求（BusRd）：核读 miss 时发出，其他核若有副本则提供数据，状态变为 S（多个持有）或 E（唯一持有）。读独占（BusRdX）：核写 miss 时发出，请求独占，其他核的副本被 invalidate（变 I），本核写后变 M。写回（WriteBack）：M 状态行被替换时写回内存。具体转换：I→E（唯一读，无其他副本）、I→S（共享读）、I→M（读独占写）、E→M（本地写，无需事务）、S→M（需 BusRdX invalidate 他人）、M→S（其他核读时提供数据）、M→I（被替换或被 invalidate）。这些事务保证"写前独占、读可共享"。

MESI 总线事务（BusRd/BusRdX/WriteBack）驱动状态转换。E→M 免事务，S→M 需 invalidate，M→S 提供数据。理解事务与状态转换是掌握 MESI 的关键。

• false sharing 成因
• padding
• @Contended

False Sharing（伪共享）的成因：两个或多个线程各自访问同一 cache line 上"不同的变量"，但缓存以 cache line 为一致性单位，任一线程写自己的变量都会 invalidate 整行，导致其他线程的缓存行失效、反复重载，造成不必要的缓存行 bounce 与一致性流量。消除方法：缓存行填充（padding），在热字段前后填充无用的字节，使每个字段独占一个 cache line（不共享），从而避免相互 invalidate；@Contended 是 JVM 提供的自动填充注解，让 JVM 对被标注字段做 padding 隔离。两者本质都是"让冲突字段分属不同 cache line"，消除物理上的共享。

false sharing 的根因是"变量粒度 < 缓存行粒度"。padding 和 @Contended 通过把字段隔离到独立缓存行消除这一共享。区别是手写 padding 与 JVM 自动填充。

• perf c2c
• hitm
• 与 perf top/火焰图区别

perf c2c（cache-to-cache transfer）是 Linux 专用的缓存一致性分析工具，通过收集 cache miss、cache-to-cache transfer（HITM，hit in modified state）等事件，定位 false sharing 的具体 cache line 与冲突的代码路径（哪些指令/函数在争抢同一行）。它给出"冲突 pair"（两个核/函数反复把同一行改来改去）的分布。perf top/火焰图定位的是"CPU 热点"（哪个函数占 CPU 时间），但它们无法区分"CPU 花在正常计算"还是"花在缓存一致性 bounce 上"。区别：perf top 显示函数耗时占比，perf c2c 专门显示缓存一致性冲突（HITM 分布），能直接定位 false sharing 的行与冲突对，而 perf top 只能看到"该函数耗 CPU 多"却不知道原因。

perf c2c 针对"缓存一致性/伪共享"定位，perf top 针对"CPU 热点"定位。后者是"现象"，前者是"原因"（伪共享导致 CPU 空转于一致性）。二者互补。

• DSU
• AMBA CHI
• 与 x86 snoop 差异

ARM DynamIQ 的 DSU（DynamIQ Shared Unit）把多个核（大小核）与共享 L3 组织在一个集群，通过 AMBA CHI（Coherent Hub Interface）协议实现缓存一致性。CHI 是"点对点、基于请求/响应"的目录/一致性协议，利用 DSU 内的 L3 作为一致性点（point of coherence），记录各核的持有状态，跨核请求通过 CHI 定向转发/失效，无需广播 snoop。与 x86 的 snoop 总线方案的差异：传统 x86（如早期）用"共享总线广播 snoop"——每个核的写/失效广播到所有核，由各核 snoop 响应；CHI 是"基于目录/点对点"的现代协议，通过 L3 目录定向定位持有者，减少广播、更好扩展，且支持大小核异构与更细粒度。DSU/CHI 面向 ARM 的异构多核，x86 现代也已采用目录式（如 Intel 的 slice 目录），但 ARM 的 CHI 以点对点请求-响应为特色。

x86 传统 snoop 是广播式，ARM CHI 是点对点/目录式。DSU 用 L3 作一致性点，CHI 定向转发，可扩展性更好，适应大小核异构。这反映现代一致性协议从广播走向目录。

• invalidate
• update
• 写策略

写一致性协议主要有两种：invalidate（失效）——写时把其他副本标记为无效，之后他们再读时重新加载；update（更新）——写时把新值广播给所有副本并更新。invalidate 成为主流的原因：一是写操作往往后面跟着其他写（高频写同一变量），invalidate 只需一次广播，后续写无需再通知；update 每次写都广播更新，写频繁时开销巨大。二是 invalidate 是"按需"的——其他核若不再读该数据，无需付出更新成本，而 update 对所有副本都更新（即使没人用）。三是 invalidate 实现简单、总线流量少。因此 invalidate 在多核写频繁的场景下带宽效率远高于 update。

invalidate 优于 update 是因为"写高频、按需失效"：失效一次可覆盖后续多次写，而 update 每次写都广播。这是带宽与实现复杂度的权衡，invalidate 胜出。

• _Alignas
• attribute((aligned))
• 对齐语法

_Alignas 是 C11 标准关键字，用于指定变量/结构体的对齐要求，如 _Alignas(64) int x; 或 struct S { _Alignas(64) int a; }; 它是标准化的、可移植的（C11/C++11）。attribute((aligned(64))) 是 GCC/Clang 的扩展属性，实现同样效果，但非标准、是编译器特定的扩展。功能上两者都指定对齐字节数（如 64 对应 cache line），但 _Alignas 更标准、可移植，attribute 是厂商扩展。在跨平台代码中优先用 _Alignas（C11）或 alignas（C++11），只在特定编译器环境用 attribute。对齐到 64 用于 cache line 边界优化。

_Alignas 是标准 C11 关键字，attribute((aligned)) 是 GCC/Clang 扩展。功能等价，选择取决于"标准化 vs 编译器特性"。均用于 cache line 对齐。

• volatile 字段
• AtomicInteger[]
• false sharing 易发性

需要澄清：是"volatile 数组的相邻元素"或"AtomicInteger[] 的相邻元素"这类"数组/连续字段"容易 false sharing，因为数组元素是连续存放的，多个元素共享 cache line。若多个线程各自更新大数组的不同元素，这些元素落在同一 cache line 上，就会互相 invalidate，产生 false sharing。volatile 字段（单个对象的字段）与 AtomicInteger[] 的差异在于：volatile 字段若和其他字段相邻排列，可能共享 cache line；AtomicInteger[] 的元素也是连续排列。两者都可能 false sharing，但"数组/连续结构"更易发（因为元素天然连续、无法像字段那样分散）。正确观点：大数组的高频并发写不同元素，极易 false sharing，无论 volatile 还是 AtomicInteger[]，需 padding 或按核隔离。

数组元素连续分布，天然可能共享 cache line，多个线程写不同元素极易 false sharing。volatile 与 AtomicInteger[] 只是保证原子/可见性，不解决缓存行共享。消除需 padding/按核分区。

• snoop-based
• directory-based
• 可扩展性

snoop-based（基于嗅探）：所有缓存共享一致性总线，每个核的读/写失效请求广播到所有核，各核 snoop 总线并响应（命中则提供数据/失效）。实现简单，但广播导致总线带宽随核数增长，扩展性差，适合小核数。directory-based（基于目录）：维护一个目录记录每个 cache line 的持有者/共享者，请求时只通知目录，由目录定向转发/失效，避免全广播，带宽与核数接近线性，扩展性好，适合大核数。差异：snoop 是"广播+嗅探"，目录是"记录+定向"。现代多核（尤其 16+ 核）用目录式（或 snoop 过滤），snoop 用于小规模。

snoop 广播可扩展性差，目录定向可扩展性好。核数增多时目录式更优，是 NUMA/多核的主流。snoop 过滤是提高 snoop 扩展性的折中。

• destructive_interference_size
• 缓存行大小
• 默认 64B

std::hardware_destructive_interference_size 是 C++17 提供的常量，表示"会导致 destructive interference（破坏性干扰，即 false sharing）的最小 cache line 大小"，即用于缓存行填充的对齐单位。默认 64B 是因为现代主流 CPU（Intel、AMD、ARM）的缓存行普遍为 64B，这个值能确保两个被 padding 的对象间隔至少一个 cache line，避免 false sharing。它由实现根据目标平台的缓存行大小提供，通常为 64。用作 padding 时，用这个值对齐/填充可保证对象落在不同缓存行，跨平台移植时比硬编码 64 更安全。

hardware_destructive_interference_size 是"缓存行大小"的标准化常量，默认 64B 反映主流平台缓存行。用于 cache line 对齐消除 false sharing，且可移植。

• MOESI 的 O
• MESIF 的 F
• 区别

MOESI（AMD）与 MESIF（Intel）都是 MESI 的扩展，都增加一个状态解决"共享数据的响应方"问题，但选型不同：MOESI 增加 O（Owned）：允许"脏且共享"的数据存在，由 O 状态所有者负责向其他核提供最新数据（即使该行已修改、未写回内存），避免写回内存再转发的开销。MESIF 增加 F（Forward）：在多个"干净且共享"（S）副本中指定一个 F 状态副本作为唯一转发者，统一响应其他核的读请求，避免多个 S 副本同时响应造成总线冲突。区别：O 处理"脏共享"（提供最新脏数据），F 处理"干净共享"（指定统一响应者）。两者都提升共享场景的一致性效率。

O 是"脏数据的所有者提供者"，F 是"干净数据的统一转发者"。MOESI 用 O 避免写回，MESIF 用 F 避免多响应。都是 MESI 的针对性增强。

• padding 消除伪共享
• 编译器优化影响
• 布局保持

在 Go/Rust 中给高频写字段加 64 字节 padding，使每个被不同线程写/读的字段独占一个 cache line，不同字段不再共享同一缓存行，因此不会因缓存行粒度互相 invalidate，从而消除伪共享。编译器优化是否破坏 padding 布局：Go 编译器会对 struct 字段做重排（field reordering）以减少大小，可能打乱 padding 的预期隔离效果；Rust 默认不保证字段顺序（编译器可重排），但可用 #[repr(C)] 或 #[repr(align(64))] 固定布局/对齐，保证 padding 生效。所以：用语言提供的对齐/布局控制（如 Rust 的 repr、Go 的显式 padding 配合字段顺序控制）才能确保 padding 不被编译器优化破坏。若编译器自由重排，padding 可能失效。

padding 消除伪共享的前提是"布局稳定、字段隔离"。Go/Rust 编译器可能重排字段，需用 repr(C)/align 等机制固定布局，确保 padding 生效。这是"语言机制 vs 编译器优化"的细致点。