本文揭示 Go 程序中 GOMAXPROCS 增大导致性能下降的根本原因：当单个任务计算量极小（如 Fibonacci(1000)）时，goroutine 间通过 channel 同步的开销远超实际计算耗时，多线程反而引入严重争用与调度负担。
本文揭示 go 程序中 `gomaxprocs` 增大导致性能下降的根本原因：当单个任务计算量极小（如 fibonacci(1000)）时，goroutine 间通过 channel 同步的开销远超实际计算耗时，多线程反而引入严重争用与调度负担。
在 Go 并发编程实践中，一个常见误区是认为“更多 worker = 更快吞吐”。但你的测试结果——GOMAXPROCS=1 时耗时 1.78s，而设为 4 时飙升至 9.88s——恰恰暴露了关键性能反模式：同步开销压倒计算收益。
根本原因在于：原始程序中每个 worker 执行的 Fibonacci 计算极其轻量（rand.Intn(1000) → 最大仅迭代 1000 次浮点加法），而每次循环都需完成一次 channel 接收（ ——这涉及：
- goroutine 阻塞/唤醒调度；
- channel 锁竞争（底层使用 mutex + condition variable）；
- 内存屏障与缓存一致性同步。
当 GOMAXPROCS=4 时，4 个 OS 线程需频繁协作消费同一无缓冲 channel，大量时间消耗在等待锁、上下文切换和内存同步上，而非真实计算。实测显示，此时 CPU user 时间并未线性增长，但 sys 时间（系统调用/调度开销）显著上升，印证了这一判断。
✅ 正确的优化路径不是盲目增 worker，而是提升单任务计算密度，降低同步频次。如下重构可逆转性能趋势：
package main
import (
"math/rand"
"runtime"
"sync"
"time"
)
func fibonacci(n int) float64 {
if n <p>? 关键改进说明：</p>
- 增大单任务负载：将 rand.Intn(1000) 改为 rand.Intn(100000)+10000，使每次计算耗时从纳秒级升至毫秒级，让 CPU 计算真正成为瓶颈；
- 启用 channel 缓冲：make(chan int, 1024) 减少 sender 阻塞，平滑生产者-消费者节奏；
- 规范 WaitGroup 用法：wg.Add() 在启动 goroutine 前调用，range 替代无限 for{}，避免资源泄漏；
- 匹配 GOMAXPROCS 与 worker 数：消除线程空转或过度竞争。
⚠️ 注意事项：
- runtime.GOMAXPROCS 在现代 Go（1.5+）中默认等于逻辑 CPU 数，手动设置通常不必要，除非有明确调优依据；
- 微基准测试（micro-benchmark）极易失真：Fib(1000) 的耗时 ≈ 几十纳秒，而一次 unbuffered channel 操作 ≈ 数百纳秒——此时并发纯属负优化；
- 真实服务场景应优先关注 I/O-bound（数据库、HTTP、文件读写）任务的并发，其天然存在等待间隙，能有效摊销调度开销。
总结：Go 的并发优势在于高效处理 I/O 等待，而非榨干 CPU 计算。面对计算密集型任务，应优先考虑：
- 提升单任务粒度（batch processing）；
- 使用 sync.Pool 复用对象；
- 必要时启用 GOMP_NUM_THREADS（CGO 场景）或 runtime.LockOSThread()（绑定核心）；
- 始终以 pprof CPU profile 数据驱动决策，而非直觉。
性能优化的第一法则是：先测量，再假设，后验证。
