跨NUMA节点分配内存导致性能暴跌，因远程访问延迟达200–300ns（本地仅70–100ns）且带宽降至40%–60%；须同步绑定线程到CPU节点并用numa_alloc_onnode在同节点分配内存，缺一不可。
为什么跨NUMA节点分配内存会导致性能暴跌
在双路或四路服务器上，CPU访问本地NUMA节点内存的延迟通常为70–100ns，而访问远端节点内存可能高达200–300ns。更致命的是带宽下降——远程访问带宽常只有本地的40%–60%。如果你用new或malloc分配内存，操作系统默认从当前线程所在节点的“首选内存池”分配；但若该线程随后被调度到另一NUMA节点执行（比如未设亲和性），它就会持续访问远端内存，形成隐蔽的性能黑洞。
如何让线程与内存同节点共存
必须同步控制两件事：线程在哪跑、内存从哪分。缺一不可。
- 先用
sched_setaffinity或std::this_thread::set_affinity（C++26）将线程绑定到某物理Socket上的核心（例如cpu_id0–15属于Node 0） - 再调用
numa_alloc_onnode(size_t size, int node)在对应节点分配内存，而非malloc - 若使用
std::vector等容器，需自定义Allocator，内部调用numa_alloc_onnode并传入预知的nodeID（可通过numa_node_of_cpu(cpu_id)反查）
OpenMP场景下容易忽略的陷阱
OMP_NUM_THREADS=32不等于性能最优——尤其当系统有2个NUMA节点、每节点16核时，盲目启用32线程会触发跨节点任务调度和内存争抢。
- 用
OMP_PLACES="{0}:16,{1}:16"显式划分两个节点各16个逻辑位置 - 配合
OMP_PROC_BIND=close，确保线程优先填满一个NUMA节点再扩展到下一个 - 禁用超线程干扰：
lscpu | grep "Thread(s) per core"确认是否为2，若业务是计算密集型，应设OMP_NUM_THREADS=16并只用物理核心
验证是否真正生效的三步检查法
光写代码不验证，等于没做优化。运行后立刻检查：
立即学习“C++免费学习笔记（深入）”；
- 用
numastat -p <pid>看numa_hit是否远高于numa_foreign（理想比值 > 95:5） - 用
taskset -cp <tid>确认线程实际运行在预期CPU上 - 在分配内存后，调用
numa_move_pages(0, 1, &addr, &node, &status, 0)主动迁移页面到目标节点（避免首次访问触发缺页中断时误选远端内存）
最易被跳过的环节是：线程绑定了核心，却忘了让内存也落在同一节点——这两者必须成对出现，否则所有亲和性设置都白费。
