Go搭配cgo场景下是否需要以及如何将OS线程绑定到CPU核心？

你当前的微秒级低延迟场景需要手动做CPU核心绑定，你提到的runtime.LockOSThread() + cgo调用pthread_setaffinity_np的方案完全可行。

• 你的C侧事件通道和线程强绑定，一旦处理请求的goroutine被调度到其他OS线程（M），或者对应的M被操作系统迁移到其他CPU核心，不仅会产生缓存失效、上下文切换的额外开销，还可能出现无法正常获取对应通道返回结果的问题
• Go默认调度器面向通用高吞吐场景设计，OS线程（M）不会绑定固定CPU核心，操作系统的调度策略随时可能把M迁移到其他核心，对于微秒级延迟敏感的场景，这种迁移带来的开销完全不可接受
• GMP模型里P和物理核心没有关联，也没有内置的核心亲和性优化逻辑，无法满足你的低延迟需求，必须手动干预。

• 提前确认可用的物理核心数量，绑核数量不要超过物理核心数，优先避开超线程逻辑核心，避免资源争抢
• 为每个处理C侧通道请求的工作goroutine调用runtime.LockOSThread()，调用后该goroutine会永久绑定到当前的M上，不会被调度到其他M，且该M也不会被用来调度其他goroutine，直到你主动调用runtime.UnlockOSThread()
• 在已经锁定OS线程的goroutine中发起cgo调用，执行pthread_setaffinity_np将当前M对应的OS线程绑定到指定的CPU核心
• 后续所有和该C侧通道相关的请求提交、结果轮询操作都必须在这个绑定完成的goroutine中执行，不要将相关操作分散到其他goroutine
• 如果工作goroutine需要提前退出，记得调用runtime.UnlockOSThread()释放对应的M，避免线程泄漏。

• 提前通过runtime.GOMAXPROCS()预留足够的P给普通业务goroutine使用。例如机器有8个物理核心，你计划绑定3个核心做低延迟轮询，可以将GOMAXPROCS设置为5，剩下的3个核心专门给绑定的M使用，完全不会被Go的其他调度逻辑抢占
• 绑核时注意不要让多个线程绑定到同一个物理核心，反而会增加调度开销
• 不要在绑定了核心的goroutine中执行任何非必要的阻塞操作，避免浪费预留的核心资源。

如果你的业务延迟容忍度在毫秒级以上，也没有线程绑定的C侧资源依赖，不需要做手动绑核。默认的Go调度器已经足够应对通用场景，手动绑核反而会增加维护复杂度，降低CPU整体利用率。

内容的提问来源于stack exchange，提问作者IcicleF