线程绑定cpu核心能提升缓存命中率，是因为固定核心后，线程反复访问的热数据（如循环计数器、局部状态）可稳定驻留在该核l1缓存中；而跨核迁移会导致l1/l2缓存预热数据丢失，重新加载比l3慢3–5倍、比主存慢200倍以上。
为什么线程绑定CPU核心能提升缓存命中率
线程在不同核心间迁移时，L1/L2缓存中预热的数据会丢失，下次执行又要重新加载——这比从L3缓存读取慢3–5倍，比从主存读取慢200倍以上。固定线程到特定核心后，std::thread反复访问的热数据（如循环计数器、局部状态）大概率保留在该核心的L1缓存中。
实际操作只需两步：
- 获取当前系统CPU数量：
std::thread::hardware_concurrency() - 用
pthread_setaffinity_np（Linux）或SetThreadAffinityMask（Windows）绑定线程到指定核心编号
注意：不要盲目绑定所有线程到同一核心；若线程数超过物理核心数，应按NUMA节点分组分配，避免跨节点内存访问延迟飙升。
如何避免多线程下的伪共享（False Sharing）
两个线程修改同一缓存行（通常64字节）中的不同变量，即使无逻辑依赖，也会因MESI协议频繁使缓存行失效——典型表现为perf stat -e cache-misses数值异常高，但CPU使用率不高。
关键防御手段是隔离热点变量：
- 用
alignas(64)强制结构体对齐到缓存行边界，例如：struct alignas(64) Counter { std::atomic<int> value; };</int> - 避免把多个
std::atomic成员挤在同一个结构体内；每个计数器单独成结构体并alignas(64) - 使用
std::hardware_destructive_interference_size（C++17起）替代硬编码64，它在多数平台返回64，但可移植
常见错误：给整个std::vector<:atomic>></:atomic>加alignas没用——每个元素仍可能落在同一缓存行内。
SoA布局比AoS更适合多线程数值计算
在粒子模拟、图像处理等场景中，若每个线程只更新某类字段（如全部更新x坐标），AoS结构（struct Particle { float x,y,z; };）会导致每次读写都拖入64字节缓存行，其中2/3是冷数据；而SoA（std::vector<float> xs, ys, zs;</float>）让同类型数据连续存放，一次缓存行加载全是有效数据。
迁移要点：
- 将原本的
particles[i].x改为xs[i]，需重构访问逻辑 - SoA天然适配SIMD向量化，编译器更易生成
vmovaps类指令 - 若部分线程需读取完整粒子（x+y+z），则SoA会增加访存次数——此时应按访问模式分区，热字段SoA，冷字段AoS
别忽略内存分配：用std::vector::reserve()预分配，避免多线程resize触发内部锁竞争。
循环分块（Loop Tiling）如何适配L2缓存大小
大矩阵乘法中，不加优化的三重循环会让中间结果反复进出L1，而B[k][j]列访问还会导致大量L2未命中。分块的目标是让子块数据完全驻留于L2缓存（通常256KB–1MB）。
实操步骤：
- 估算单个
double占8字节，L2按512KB算，理论块大小上限为sqrt(512*1024/8) ≈ 256，实践中常取BLOCK_SIZE = 32或64（兼顾寄存器压力与空间局部性） - 代码结构必须是外层i/j分块，内层k完整遍历，否则无法复用
A[i][k]和C[i][j] - 用
__builtin_prefetch提示预取下一块的A和B首地址，但别过度——prefetch太多反而污染缓存
最容易被忽略的一点：分块尺寸不是越大越好。当BLOCK_SIZE超过L2容量时，子块内部又开始抖动，性能反而跳变下降——建议用perf record -e L1-dcache-load-misses验证实际缓存行为。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
