数据局部性指线程访问的数据尽量驻留在本核L1/L2缓存中，避免跨核迁移导致缓存失效；包括时间局部性（重复访问同一内存）和空间局部性（连续访问相邻地址），并发下二者均易失效，引发伪共享或重加载延迟。
什么是并发中的数据局部性？
数据局部性在多核并发里不是“数据离得近”，而是“每个线程访问的数据，尽量只落在自己核心的L1/L2缓存里，不被别的核反复踢出”。它分两层：时间上重复用同一块内存（比如循环累加一个sum），空间上连续访问相邻地址（比如遍历std::vector而非std::list）。并发下失效的是前者——线程一迁移到另一核，刚热起来的sum就全丢了；后者失效更隐蔽——多个线程写不同变量却挤在同一cache line，引发伪共享。
为什么绑CPU核心能提升50%缓存命中率？
现代CPU的L1/L2缓存是每核私有。线程在核心0跑时，data[0]、counter等热数据会常驻其L1缓存；一旦被调度器挪到核心3，这些数据全得从L3或内存重新加载，延迟跳到200+周期。实测中，未绑定亲和性的高吞吐线程池，L1命中率常低于40%；固定到单核后普遍回升至85%以上。
-
pthread_setaffinity_np必须在创建线程后、实际工作前调用，否则无效 - 别把两个高负载线程绑到同一物理核的超线程逻辑核（如CPU 0 和 CPU 1），它们共用L1缓存，反而加剧竞争
- NUMA节点下，要同步绑定内存分配策略：
numactl --cpunodebind=0 --membind=0 ./app
怎么避免伪共享（False Sharing）？
伪共享不是代码写错，是结构体里两个int变量挨得太近，被塞进同一个64字节cache line，结果线程A改counter_a、线程B改counter_b，互相让对方的缓存行失效。现象是：CPU使用率飙高但吞吐上不去，perf看L1-dcache-load-misses异常高。
- 用
alignas(64)强制对齐，确保关键变量独占一行：struct alignas(64) WorkerStats { int64_t processed; int64_t errors; }; - 别用
__attribute__((aligned(64)))修饰单个int——编译器可能仍把它和邻近变量打包 - 检查结构体大小是否为64的整数倍，否则末尾填充可能被后续变量“吃掉”
数组遍历顺序为何影响并发性能？
并发场景下，如果多个线程各自处理二维数组的一块区域，但用列优先（for j; for i）方式读写，每个线程实际访问的内存地址跨度极大，导致预取失效、cache line反复换入换出。尤其当数组大到超出L3缓存时，性能断崖式下跌。
- 行优先（
for i; for j）让每个线程连续扫一片内存，预取器能跟上，L2命中率稳定在90%+ - 若必须列处理，改用循环分块（Loop Tiling）：按64字节对齐的块大小切分，例如
for (int ii = 0; ii （假设int为4字节，16×4=64） - 别依赖编译器自动向量化——
-O3可能优化掉你精心设计的分块，加#pragma GCC unroll 4更可控
真正难的不是知道要对齐或绑核，而是当你的WorkerStats嵌套在三层模板类里、又混着std::shared_ptr管理时，怎么定位哪个字节偏移触发了伪共享——这时候perf record -e cache-misses配合perf script看地址分布，比猜强得多。
