L1/L2缓存无法跨核复用，因硬件上为每核私有；高效复用需绑定线程至固定核心并优化数据局部性、避免伪共享及适配缓存容量。
多核环境下，L1 和 L2 缓存是每个核心私有的（或部分共享），无法“跨核复用”——这是硬件设计决定的。所谓“高效复用”，本质是让每个线程尽量固定在同一个核心上运行，并让其访问的数据尽可能留在该核心的 L1/L2 中，避免迁移和驱逐。
为什么不能跨核复用 L1/L2 Cache
L1 缓存物理上集成在核心内部，L2 通常也是每核独占（少数架构为双核共享），它们不支持直接被其他核心读写。当线程从一个核迁移到另一个核时，原来缓存里的数据会失效或被写回，新核要重新加载——这叫“缓存冷启动”。这不是软件能绕过的限制，而是 CPU 架构的硬约束。
常见错误现象包括：
- 性能曲线随线程数增加先升后降，甚至出现负扩展
-
perf stat -e cache-misses,cache-references显示缓存未命中率突增 - 同一数据结构被多个线程高频修改，但性能远低于预期
绑定线程到特定 CPU 核心（CPU affinity）
让线程长期驻留在一个核心上，是保持 L1/L2 热数据的前提。不绑定时，OS 调度器可能随时迁移线程。
立即学习“C++免费学习笔记（深入）”；
实操建议：
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- Linux 下用
pthread_setaffinity_np()或std::this_thread::set_affinity()（C++20 起部分实现支持，更推荐 POSIX） - 启动时用
taskset -c 0-3 ./myapp限定可用核，再配合线程内细粒度绑定 - 避免绑定到超线程逻辑核对（如
0和1若属同一物理核），因它们共享L1指令缓存和部分L2资源，易引发干扰 - 注意 NUMA：若程序使用大量内存，应同时绑定到靠近本地内存节点的核，用
numactl --cpunodebind=0 --membind=0 ./myapp
避免伪共享（False Sharing）
即使线程绑定了核心，如果多个线程修改位于同一缓存行（通常是 64 字节）的不同变量，仍会触发缓存一致性协议（MESI），导致频繁无效化和同步——表现为 L1 数据反复刷写、延迟飙升。
典型场景：
- 数组中相邻元素被不同线程更新：
counter[i]++，而i是连续索引 - 结构体中多个
std::atomic<int>成员紧挨着声明
解决方式：
- 用
alignas(64)对热点变量做缓存行对齐 - 结构体中将只读字段和频繁修改字段分离，中间插入填充（如
char padding[64]） - 改用单生产者单消费者队列等无锁结构，减少跨线程写竞争
数据布局与访问模式适配缓存层级
每个核心的 L1 只有 32–64 KB，L2 通常 256 KB–1 MB。若线程处理的数据集远超 L2 容量，再怎么绑定也留不住热数据。
关键策略：
- 按工作集（working set）切分任务：例如处理大数组时，让每个线程负责一段连续内存块（而非奇偶索引交错），提升空间局部性
- 优先使用栈分配小对象，避免堆分配导致内存碎片和跨页访问
- 对二维数据，坚持行优先遍历：
matrix[i][j]而非matrix[j][i]；GPU 上同样适用 - 避免在 hot loop 中调用虚函数或跳转表，防止指令缓存（
L1-I）频繁换入换出
最易被忽略的一点：缓存效率不是靠“加大数据结构”或“预取更多”，而是靠控制数据生命周期与线程生命周期的对齐。一个线程绑定在 core 3 上跑 10ms，比它在 core 0/1/2/3 之间来回切换 4 次，对 L1 的利用效率可能差 5 倍以上——这个差距，不会出现在代码行数里，但会真实反映在 L1-dcache-loads-misses 的 perf 计数中。
