JVM中Shenandoah收集器在多核处理器架构下对NUMA（Non-Uniform Memory Access）的适配

先说一个核心判断：Shenandoah收集器在JDK 21及当前主流OpenJDK发行版中，本质上并不原生支持NUMA感知。它没有实现线程绑定、本地内存优先分配或NUMA-aware调度，所有GC操作都基于统一堆视图运行。这意味着，如果要在NUMA架构上发挥其性能，很大程度上需要依赖外部工具（比如numactl）手动干预。

Shenandoah收集器本身不直接感知或原生适配NUMA拓扑。在多核处理器系统上运行时，它默认按照通用并发模型调度线程——既不会主动将GC工作线程绑定到特定NUMA节点，也不会优先把本地内存分配给对应的CPU核心。这一点，与G1在JDK 14+中明确增强的NUMA支持形成了鲜明对比。 ### Shenandoah未内置NUMA感知机制 截至JDK 21（LTS）及当前主流OpenJDK发行版（如Red Hat build、Eclipse Temurin），Shenandoah收集器没有实现NUMA-aware的内存分配策略或线程亲和性调度。它的Region分配、对象复制、转发指针更新等关键操作，均基于统一堆视图进行，并不区分本地内存与远程内存访问代价。 - 所有GC工作线程（如并发标记线程、回收线程）由JVM线程池统一管理，不绑定至特定CPU节点 - 堆内存由操作系统统一分配，Shenandoah不调用mbind()、numactl相关API来控制页放置位置 - 读屏障触发的转发指针访问，其延迟受实际物理内存位置影响，但收集器自身不优化该路径 ### NUMA对Shenandoah的实际影响 虽然Shenandoah不主动适配NUMA，但在真实的多节点服务器上，NUMA特性仍会间接影响其行为： - 停顿时间可能轻微波动：初始标记、最终标记等STW阶段，如果恰好涉及跨节点引用扫描，远程内存访问延迟可能会略微抬高停顿峰值 - 并发阶段吞吐受带宽限制：在并发回收阶段进行大量对象复制时，如果目标Region位于远程节点内存，QPI/Infinity Fabric总线争用可能降低复制速率 - 内存局部性未被利用：用户线程集中在Node 0分配对象，而Shenandoah线程却在Node 1执行回收，容易引发缓存行伪共享与跨节点同步开销 ### 手动提升NUMA友好性的可行做法 如果一定要在NUMA系统上跑Shenandoah并追求极致性能，那也不是完全没办法，主要得靠外部手段来“曲线救国”： - 启动JVM前使用numactl --cpunodebind=0 --membind=0 ja va ...将整个JVM进程限定在单个NUMA节点，直接消除跨节点访问 - 配合-XX:+UseLargePages减少TLB miss，缓解远程内存访问的地址翻译开销 - 调整-XX:ParallelGCThreads和-XX:ConcGCThreads，使其不超过单节点CPU核心数，避免线程跨节点迁移 - 监控/sys/devices/system/node/下各节点内存使用与跨节点访问计数（如numastat输出），验证是否出现显著的remote node page allocation ### 对比G1的NUMA支持更显差异 相比之下，G1就显得“贴心”多了。自JDK 14起，G1通过-XX:+UseNUMA参数即可启用显式NUMA优化：自动为每个节点维护独立的Remembered Set、按节点划分年轻代Eden区，并尝试将Region分配与创建线程所在节点对齐。而Shenandoah目前没有对应开关，也没有内部模块来处理这件事。它的设计重心始终放在“停顿时间与堆大小解耦”这一核心目标上，NUMA适配尚未被纳入官方路线图。