gomaxprocs设为cpu核心数不总是最优，因阻塞i/o时增大会加重线程切换开销，计算密集型时过高又引发缓存抖动；需结合go tool trace、容器cgroup限制及压测验证。
为什么 runtime.GOMAXPROCS 设置为 CPU 核心数不总是最优
Go 程序默认将 GOMAXPROCS 设为逻辑 CPU 数，但这只是调度器能并行执行的 M（OS 线程）上限，并不等于实际吞吐最优值。当存在大量阻塞系统调用（如文件 I/O、数据库查询、http 调用）时，提高 GOMAXPROCS 可能增加线程切换开销，反而降低性能；而纯计算密集型任务中，设得过高又可能引发缓存抖动。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
go tool trace观察Proc的运行状态：若长期存在大量Runnable但无空闲Proc，才考虑上调GOMAXPROCS - 在容器环境中（如 kubernetes），需读取
/sys/fs/cgroup/cpu/cpu.cfs_quota_us和/sys/fs/cgroup/cpu/cpu.cfs_period_us动态计算可用核数，而非直接用runtime.NumCPU() - 设置后务必压测验证——例如在 8 核机器上设为 12，
pprof显示scheduler:goroutines队列长度翻倍且sync.Mutex竞争上升，说明已过载
sync.Pool 何时会拖慢性能而不是加速
sync.Pool 本意是复用临时对象以减少 GC 压力，但滥用会导致内存驻留时间变长、GC 周期拉长，甚至因内部锁竞争成为瓶颈。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 仅对生命周期明确、创建开销大、且大小相对固定的对象使用（如
bytes.Buffer、自定义结构体切片），避免放入含指针字段过多或带 finalizer 的对象 - 不要在短生命周期 goroutine 中频繁
Get/Put小对象（如单个int或小 Struct）：此时分配成本低于池查找+锁开销 - 监控
runtime.ReadMemStats中的PauseNs和NumGC，若开启sync.Pool后 GC 暂停时间不降反升，大概率是池中对象“太老”，卡在老年代未被及时回收
用 pprof 定位 goroutine 泄漏比看 goroutine count 更可靠
单纯检查 runtime.NumGoroutine() 返回值容易误判：大量 goroutine 处于 IO wait 或 semacquire 状态是正常现象；真正危险的是持续增长且堆栈固定在某几处的 goroutine。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
curl http://localhost:6060/debug/pprof/goroutine?debug=2获取完整堆栈，搜索重复出现的函数名（如http.(*persistConn).readLoop或你的processJob） - 配合
go tool pprof加载goroutineprofile 后，执行(pprof) top -cum查看累计阻塞路径，而非只看top - 常见泄漏点：
time.AfterFunc未取消、channel写入端关闭后读端仍在range、context.WithTimeout创建的子 context 未被显式cancel()
channel 操作不是零成本：缓冲区大小和类型影响显著
无缓冲 channel 的发送/接收必须双方 goroutine 同时就绪，本质是同步点；有缓冲 channel 虽缓解阻塞，但缓冲区过大（如 make(chan int, 1e6)）会占用大量堆内存，且写满后行为退化为无缓冲。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 根据生产者-消费者速率差估算缓冲区：若每秒写入 1000 条、消费延迟均值 50ms，则缓冲区设为
50左右足够，而非拍脑袋填1024 - 传递大结构体时，优先传指针或
unsafe.pointer，避免 channel 底层拷贝（尤其在select多路复用中） - 避免在 hot path 中用
len(ch)判断通道长度——它不保证原子性，且触发 runtime 的额外检查，应改用非阻塞select+default
实际调优中最容易被忽略的，是把「并发」当成目的本身。很多性能问题根源不在 goroutine 数量或 channel 使用，而在业务逻辑是否真能并行——比如一个本该串行更新的账户余额，强行并发只会引入更多锁和重试。先确认数据依赖图，再决定并发粒度。