解读

国内云原生面试里，**“NUMA 感知调度”**是区分“只会写业务代码”与“懂运行时调优”的高频分水岭。
面试官想确认三点：

1. 你是否持续跟踪 Go Runtime 的演进路线；
2. 能否把 NUMA 拓扑与调度器抽象模型对应起来；
3. 是否清楚 1.22 版本里“已经落地”与“仍在讨论”的边界，避免把实验特性当成稳定功能。

因此，回答必须给出明确版本结论，并指出可落地的替代方案。

知识点

1. NUMA 基本概念：多路服务器中，CPU 访问本地 Node 内存延迟低，跨 Node 延迟高；
2. Go 调度器抽象：G-M-P 模型，全局 runqueue + 每个 P 的本地 runqueue，M 与 OS 线程 1:1 绑定；
3. 拓扑感知需求：把 P 固定在同一个 NUMA Node 的 CPU 上，减少跨 Node 内存访问；
4. 官方提案：golang.org/issue/599 及其子任务，Go 1.22 并未合并 NUMA 感知调度；
5. 实验分支：runtime:NUMA 分支可在 Linux 上通过 GOEXPERIMENT=numa 编译，但官方明确标注“not ready for production”；
6. 替代方案：
   • 使用 taskset / numactl 把进程绑到指定 Node；
   • 在容器场景利用 Kubernetes Topology Manager + kubelet CPU Manager 的 “single-numa-node” 策略；
   • 业务层拆分多个独立进程，每个进程绑定一个 Node，用反向代理做无状态水平扩展。

答案

“截至目前 Go 1.22 正式版本，NUMA 感知调度仍处于实验阶段，并未默认启用。
相关提案 golang.org/issue/599 的代码仅在 GOEXPERIMENT=numa 编译参数下可用，官方文档明确提示**‘性能收益与稳定性尚未达到生产要求’**。
因此，线上服务若对 NUMA 亲和性敏感，建议先用 numactl –cpunodebind=0 –membind=0 ./your_bin 做进程级绑定，或在 Kubernetes 中开启 Topology Manager 的 single-numa-node 策略，把调度决策下沉到操作系统与容器层，而不是等待 Go Runtime 原生支持。”

拓展思考

1. 如果未来 Go 合并 NUMA 感知调度，P 与 NUMA Node 的映射策略可能提供两种模式：
   • 静态绑定：启动时根据 /sys/devices/system/node 拓扑一次性划分 P，适合长生命周期服务；
   • 动态迁移：在 GC 或调度器抢占点重新评估内存访问热度，把 G 移到更优 Node，但需解决跨 Node 内存重新归集的代价；
2. 对内存型网关（如七层负载均衡）来说，即使 NUMA 调度落地，仍需结合内存池与对象复用，否则跨 Node 的 malloc 仍会成为瓶颈；
3. 面试时可以主动反问：“贵司线上主机是几路 NUMA？是否已用 numactl 做过 baseline 测试？”——既展示实战意识，又把话题拉回可落地的调优手段，容易拿到加分。