go框架不提供cpu亲和性控制，runtime.lockosthread()仅防goroutine迁移，不能绑定核心；必须用unix.schedsetaffinity()设线程亲和性并配合numactl绑定numa节点，否则跨节点内存访问延迟高2–3倍。

Go 框架本身不提供 CPU 亲和性控制能力，runtime.LockOSThread() 不能绑定线程到指定核心，仅防止 goroutine 迁移；真正生效的必须是系统调用（如 unix.SchedSetaffinity）配合进程级 NUMA 绑定。

为什么 runtime.LockOSThread() 对 HTTP 服务无效

它只锁定 goroutine 到当前 OS 线程，但无法控制该线程运行在哪颗 CPU 上。Go 运行时仍可能将已锁定的线程调度到任意核心——尤其在 GC、sysmon 抢占或负载变化时。更关键的是：

• net/http.Server 共享全局 netpoller，所有 epoll_wait 始终由单个 OS 线程执行，LockOSThread() 完全无法分散网络事件监听
• 多个 goroutine 调用 srv.Serve(l) 会因监听器已被占用而立即返回 http: Server closed 错误
• 若没检查 err，容易误以为“起了多个实例”，实际只是假并发、真报错

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

这是最直接、最小侵入的方式，适用于启动即绑定的长期服务（如 API 网关、音视频处理模块）。注意必须在业务逻辑开始前执行，且需配合 runtime.LockOSThread() 防止 goroutine “逃逸”：

Golang Uber Dig

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

下载

• unix.SchedSetaffinity(0, &cpuset) 中第一个参数为 0，表示作用于当前线程（不是进程）
• cpuset.Set(cpuID) 只接受整数 ID；绑多个核心需循环调用（如 cpuset.Set(4); cpuset.Set(5)）
• ARM big.LITTLE 架构下，/sys/devices/system/cpu/cpu*/topology/core_id 才反映真实物理核心编号
• 绑定后必须立刻调用 runtime.LockOSThread()，否则后续 goroutine 可能被调度到其他线程，破坏绑定效果

SO_REUSEPORT + 多进程才是高并发网络服务的正解

单进程无法突破 Go 的单 netpoller 架构限制，多 goroutine 跑 http.Server.Serve() 不等于多核网络并行。生产环境应采用多进程部署，并配合内核级连接分发：

• Linux 3.9+ 支持 SO_REUSEPORT，允许多个进程 bind() 同一端口，内核自动做连接级负载均衡
• Go 1.11+ 可通过 net.ListenConfig{Control: ...} 启用：syscall.SetsockoptInt32(fd, syscall.SOL_SOCKET, syscall.SO_REUSEPORT, 1)
• macOS 不支持连接级分发，仅端口复用，必须加 nginx 或 HAProxy 做前端分发
• 每个进程应搭配 numactl --cpunodebind=0 --membind=0 启动，避免跨 NUMA 节点内存访问（延迟高 2–3 倍）

CPU 密集型任务才值得手动绑核

I/O 密集型框架（如 Gin、Echo 默认 HTTP 服务）绑核收益极低，反而可能因线程固定导致调度僵化。只有明确满足以下条件时才考虑：

• 任务纯计算、无阻塞 I/O（如图像编解码、加密验签、向量检索）
• 单进程承担稳定高负载，且可预估核心资源需求
• 避开超线程逻辑核（例如只用 CPU 0、2、4…，而非 0、1、2、3…）
• 双路服务器或 ARM 多 die 架构下，必须同步绑定 CPU 和 NUMA 内存节点，否则缓存失效率飙升

绑核不是银弹——它把调度权从内核交还给应用，一旦配置错误（比如绑到小核、跨 NUMA），延迟抖动可能从 0.2ms 涨到 8ms，比不绑更差。

golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！