直接回答：现代 CPU 的 L1/L2/L3 缓存以 64 字节缓存行为单位交换数据，核间一致性靠 MESI 协议（Modified/Exclusive/Shared/Invalid 四态）传播失效消息。程序员的实际影响三条：false sharing——两个核各自写不同变量但落在同一缓存行，行在两个核间反复踢来踢去，性能塌方（Java 的 @Contended 就是为此而生）；顺序访问远快于随机访问（预取器与行粒度决定的，链表 vs 数组的性能鸿沟根源在此）；volatile/原子操作的代价本质是触发缓存行所有权的转移。
展开解析：性能认知的数量级：L1 约 1ns、L3 约 10ns、主存约 100ns——“缓存未命中”一次等于白等上百拍，这就是内存墙。应对套路：数据结构按访问模式布局（热字段聚在同一缓存行、冷字段拆出去；数组结构 SoA 替代 AoS 让向量化与预取友好）；写共享计数器用分段（LongAdder 的 Cell 数组就是空间换缓存行独占）；无锁队列的生产者消费者指针分别 padding 到不同缓存行。测量方法：perf stat 看 cache-misses 与 LLC-miss-rate，perf c2c 专查 false sharing。误区提醒：缓存行大小不是永远 64（Apple Silicon 部分 128、ARM 服务器有 64/128），跨平台代码用运行时常量而非魔法数；MESI 的细分变体（MOESI/MESIF）影响共享态的转发路径但编程模型不变。面试层面能把“为什么两个无关计数器放一起会让多线程程序变慢 10 倍”讲透就达标。
追问方向：写缓冲（store buffer）与失效队列对内存序有何影响？如何验证 false sharing 已消除？
（约 490 字）