Go语言CPU亲和性设置_Golang NUMA架构性能优化-Golang-PHP中文网

go 程序无法仅靠 runtime.lockosthread() 实现稳定 cpu 绑定，因其仅防止 goroutine 迁移线程，不控制线程在哪个 cpu 运行；需配合 unix.schedsetaffinity() 设置亲和性，并用 numactl 同步绑定 cpu 与 numa 内存。

go语言cpu亲和性设置_golang numa架构性能优化

Go 程序无法靠 runtime.LockOSThread() 实现稳定 CPU 绑定，更不能直接绑定到 NUMA 节点——必须用系统调用控制 OS 线程，并配合 numactl 或内核级内存策略才能生效。

为什么 `runtime.LockOSThread()` 不能用于 CPU 亲和性

它只防止 Goroutine 被调度到其他 OS 线程，但不控制该线程运行在哪颗 CPU 上。Go 运行时仍可能把已锁定的线程迁移到任意核心，尤其在 GC、sysmon 抢占或系统负载变化时。更关键的是：一旦调用 LockOSThread()，后续所有新 Goroutine 都会继承该线程的绑定状态，但若该线程被内核调度到小核或跨 NUMA 节点，性能反而恶化。

常见错误现象：

绑定后 taskset -cp $PID 显示亲和性掩码仍是全核（0xff）
用 perf top 观察到 L3 缓存未命中率飙升
同一台机器上，相同负载下延迟抖动从 0.2ms 涨到 8ms

Linux 下用 `unix.SchedSetaffinity()` 绑定当前线程

这是最轻量、最可控的方式，适用于启动即绑定的长期服务（如音视频编解码器、高频交易网关）。注意：必须在业务逻辑开始前执行，且需配合 runtime.LockOSThread() 防止 Goroutine 被调度到其他线程破坏绑定。

关键点：

unix.SchedSetaffinity(0, &cpuset) 中第一个参数为 0 表示当前线程（不是进程）
cpuset.Set(cpuID) 只能设整数 ID；若想绑多个核心，需循环调用 Set()
ARM big.LITTLE 架构下，cpuID 不等于物理核心编号，需先查 /sys/devices/system/cpu/cpu*/topology/core_id
绑定后立即调用 runtime.LockOSThread()，否则后续 goroutine 可能“逃逸”到其他线程

示例代码片段：

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

cpuset := unix.CPUSet{}
cpuset.Set(4) // 绑大核
cpuset.Set(5)
err := unix.SchedSetaffinity(0, &cpuset)
if err != nil {
    log.Fatal("affinity set failed:", err)
}
runtime.LockOSThread()

NUMA 节点感知比单纯绑 CPU 更重要

在双路服务器或 ARM 多 die 架构中，跨 NUMA 节点访问内存延迟可达本地的 2–3 倍。仅绑 CPU 不绑内存，等于“把人锁在会议室，却把资料放在隔壁楼”。Go 默认内存分配来自当前线程所在节点的本地内存池，但以下情况会打破这一假设：

进程 fork 子进程后，子进程首次 malloc 可能落在非本地节点
使用 mmap(MAP_HUGETLB) 或大页分配时未指定 MPOL_BIND
CGO 调用 C 库分配内存（如 OpenSSL 的 BIO_new_socket）

推荐做法：

启动时用 numactl --cpunodebind=0 --membind=0 ./myserver，强制 CPU 和内存同节点
代码中调用 unix.MigratePages()（需 root）迁移已有内存页，但代价高，慎用
避免在绑定线程中频繁调用 CGO，或确保 CGO 分配也走本地 NUMA 节点（如 libnuma 的 numa_alloc_onnode()）

`taskset` 和 `numactl` 的边界在哪

taskset 是纯 CPU 层面的轻量工具，适合单节点、无 NUMA 感知的场景；numactl 才是 NUMA 系统下的事实标准。二者不可混用——taskset 不影响内存分配策略，而 numactl 启动的进程即使没显式设置 CPU 亲和性，也会受 --cpunodebind 限制。

典型误用：