关键在于数据、线程、内存三者物理同节点对齐：用numa_alloc_onnode分片分配数组，numactl或pthread_setaffinity_np绑定线程到对应节点，并优化循环为结构化访问与分块计算以适配本地内存带宽。
要让数组循环计算在numa架构下真正“吃满”近核内存的收益，关键不是单纯加速循环本身，而是让数据、线程、内存三者物理上尽可能同节点对齐。这需要从内存布局、线程绑定、访问模式三个层面协同发力，否则再快的cpu也会被跨节点内存访问拖慢。
让数组按NUMA节点分片分配
大数组若一次性用malloc或JVM堆分配，默认可能集中在某个节点，导致所有线程争抢同一块远程内存。应主动分片：
- 用
numa_alloc_onnode(size, node_id)（libnuma）为每个NUMA节点单独分配子数组，例如双节点系统中，把长度为N的数组拆成两段，分别分配在node 0和node 1 - Java应用可用
-XX:+UseNUMA配合-XX:+UseParallelGC，但必须确保堆≥4GB；启动后通过jstat -gc <pid>观察各节点内存使用是否均衡（如node0=3.2G, node1=3.1G） - 避免全局共享大数组；改用
ThreadLocal<double[]>或按线程组预分配本地副本，减少跨节点引用
将计算线程绑定到对应NUMA节点
线程在哪跑，决定了它默认从哪分配内存、访问哪块缓存。不绑定就等于随机“投宿”，极易错配：
- 启动Java进程时用
numactl --cpus=0-3 --membind=0 java -jar app.jar，强制前4核与node 0内存绑定 - C/C++程序可用
pthread_setaffinity_np()在创建worker线程时指定CPU掩码，并搭配numa_set_preferred(node_id)引导后续内存分配倾向本地 - Netty或ForkJoinPool等框架，需显式配置EventLoop或线程池绑定CPU核心组，避免OS调度器跨节点迁移
优化循环访问模式以适配本地内存带宽
即使数据和线程已同节点，不良访问模式仍会触发缓存行竞争或远程预取：
- 优先采用结构化访问：遍历方向尽量与数组内存布局一致（如C语言行主序数组用
i外层、j内层），减少cache line跳跃 - 对超大数组做分块计算（tiling），使每次处理的数据块能装入L3缓存（通常每节点L3为几十MB），降低对内存带宽的持续压力
- 避免伪共享：多个线程写同一cache line不同字段时，即使数据在本地也会因缓存一致性协议频繁同步；可在结构体字段间填充
pad[64]隔离
不复杂但容易忽略——NUMA收益从来不是单点开关能打开的，它是一套协同策略：分片是前提，绑定是保障，访存是放大器。三者缺一，算力就卡在内存路上。
