Go语言通过控制并发度、复用worker池、避免GC干扰和必要时绑定OS线程来高效处理CPU密集型任务，而非依赖goroutine数量堆砌。
Go语言本身不直接“优化CPU密集型任务”，而是通过合理的调度设计、避免阻塞和合理分配资源，让CPU密集型任务在并发场景下更高效、不拖垮系统。关键不是靠goroutine数量堆砌，而是控制并发度、减少调度开销、避免GC压力和OS线程争抢。
理解CPU密集型任务的瓶颈在哪
CPU密集型任务（如图像处理、加密解密、数值计算）的特点是：长时间占用CPU、几乎不发生I/O等待、goroutine不会主动让出P。这时：
- 过多goroutine不会提升性能，反而增加调度器负担和上下文切换开销
- 默认GOMAXPROCS等于逻辑CPU数，但若任务本身已占满所有核，再增goroutine只会排队等待
- runtime.Gosched()对纯CPU循环无效——它只让出P给其他goroutine，但若所有goroutine都在跑CPU，本质仍是轮转抢时间片
用固定Worker池限制并发数
不要为每个任务起一个goroutine，而是复用一组固定数量的worker goroutine（通常设为GOMAXPROCS或略高），通过channel分发任务：
- 避免瞬间创建成千上万个goroutine导致内存暴涨和调度风暴
- worker数量与物理核心数匹配，减少线程抢占和缓存失效
- 示例：启动4个worker处理1000个矩阵乘法任务，比起1000个goroutine更稳更快
必要时调用runtime.LockOSThread()
某些场景（如调用C库做SIMD计算、绑定特定CPU核、避免线程迁移导致L3缓存失效）可临时锁定OS线程：
立即学习“go语言免费学习笔记（深入）”；
- 仅在真正需要时使用，用完及时UnlockOSThread()
- 注意：LockOSThread后该goroutine独占线程，不能再被调度器复用，滥用会导致P饥饿
- 适合长时、确定性高的计算模块，比如FFmpeg绑定核做视频帧处理
规避GC与内存分配干扰
CPU密集任务中频繁new或make会触发GC，暂停整个程序（STW），打断计算流：
- 复用slice、struct对象，用sync.Pool管理临时计算缓冲区
- 避免在热循环里构造字符串、map或interface{}，减少逃逸和堆分配
- 用go tool trace分析GC频率和停顿，确认是否成为隐性瓶颈
基本上就这些。Go的并发优势不在“多”，而在“可控”。对CPU密集型任务，少即是多，稳胜于快。
