Go多核性能瓶颈主因是GOMAXPROCS配置失当、I/O阻塞未卸载及goroutine泄漏；需检查同步I/O、全局锁争抢、LockOSThread误用，并用trace/pprof定位调度问题。
Go 程序默认就能利用多核，但“能跑”不等于“跑得高效”——真正卡住性能的，往往是 runtime.GOMAXPROCS 配置失当、I/O 阻塞未卸载、或 goroutine 泄漏导致调度器过载。
为什么设置了 GOMAXPROCS 还是单核跑满？
常见现象：top 显示只有 1 个 CPU 核心 100%，其余空闲，runtime.GOMAXPROCS(0) 返回值却是 8。这说明 OS 层面允许多核，但程序没产生足够可并行的非阻塞工作。
- 检查是否大量使用同步 I/O（如
os.ReadFile、http.Get直接在主 goroutine 调用），它们会让 P 绑定的 M 进入系统调用而暂停调度 - 确认没有全局互斥锁（
sync.Mutex）被高频争抢，它会强制串行化临界区，抵消并行收益 - 用
go tool trace观察Proc状态：若多个 P 长期处于idle或syscall，说明任务分发或阻塞处理有问题
runtime.LockOSThread 用错就拖垮调度器
这个函数把当前 goroutine 和底层 OS 线程绑定，常用于 CGO 场景（如调用需要线程局部存储的 C 库）。但它会阻止 goroutine 被迁移，一旦该线程陷入长时间系统调用或阻塞，对应 P 就无法调度其他 goroutine。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 仅在必须时调用，且配对使用
runtime.UnlockOSThread() - 绝对不要在循环里反复 Lock/Unlock，开销大且易出错
- CGO 调用前自动 Lock，返回后自动 Unlock，除非你显式干预了线程状态
- 若发现 trace 中出现大量
thread blocked，优先排查是否误用LockOSThread
goroutine 泄漏比慢还危险
泄漏的 goroutine 不会释放栈内存，也不退出，持续占用 P 和 M 资源，最终让调度器忙于管理而非执行业务逻辑。典型场景是 channel 读写不匹配、timer 未 stop、或 context 没传递取消信号。
立即学习“go语言免费学习笔记（深入）”；
- 用
pprof/goroutine?debug=2查看所有 goroutine 堆栈，重点关注select卡在 channel 操作、time.Sleep无限等待、或net/httphandler 未结束 - 对超时操作一律用
context.WithTimeout，并在 defer 中 cancel - channel 发送前确保有接收方，或改用带缓冲 channel + select default 分支兜底
- 启动长期 goroutine 时，用
sync.WaitGroup计数并显式回收，别依赖 GC
多核性能不是靠堆 goroutine 数量换来的，关键在让每个 P 保持高吞吐的非阻塞计算 —— 这要求你清楚每处 I/O 是同步还是异步、每次锁的持有时间是否可控、每个 goroutine 的生命周期是否明确。稍不注意，go run -gcflags="-m" 提示的逃逸分析警告，可能就是性能瓶颈的起点。
