Go 程序无法仅靠 runtime.LockOSThread() 实现稳定 CPU 绑定，因其仅防止 Goroutine 迁移线程，不控制线程在哪个 CPU 运行；需配合 unix.SchedSetaffinity() 设置亲和性，并用 numactl 同步绑定 CPU 与 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 被调度到其他线程破坏绑定。
立即学习“go语言免费学习笔记（深入）”；
关键点：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
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 可能“逃逸”到其他线程
示例代码片段：
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 限制。
典型误用：
- 用
taskset -c 0-3 numactl --cpunodebind=0 ./app：后者覆盖前者，taskset无效 - 用
numactl --cpunodebind=0 ./app却没加--membind=0：CPU 在节点 0，但内存可能从节点 1 分配 - 在容器中只设
taskset：cgroups v2 下会被cpuset.cpus覆盖，需同步配置
真正稳定的 NUMA 绑定，永远要同时控制 CPU + 内存两个维度，缺一不可。
