阿姆达尔定律指出理论加速比上限为 $ s = \frac{1}{(1-p) + p/n} $，其中 $ p $ 为可并行比例、$ n $ 为核心数；当 $ p=0.8 $、$ n=8 $ 时，$ s \approx 3.33 $，远低于线性加速的 8 倍。
用 Amdahl 定律估算理论加速比
实际加速比不会随核心数线性增长，关键看程序中可并行部分占比。公式是 S = 1 / ((1 - P) + P / N)，其中 P 是可并行比例，N 是核心数。比如 P = 0.8、N = 8，算出来 S ≈ 3.33，不是 8 倍。
常见错误是直接拿总耗时除以单核耗时就当“加速比”，忽略了串行开销和测量噪声。必须在同一台机器、关闭 CPU 频率调节（如 sudo cpupower frequency-set -g performance）、禁用后台干扰进程后再测。
- 先跑单核 baseline：设置
runtime.GOMAXPROCS(1)，重复 5 次取中位数 - 再跑多核对比组：分别试
runtime.GOMAXPROCS(2)、4、8，每次也取中位数 - 避免用
time.Now()测微秒级差异，改用testing.Benchmark或perf stat
用 runtime/pprof 抓真实瓶颈
pprof 能暴露 Goroutine 调度、锁竞争、GC 干扰等隐藏开销，比单纯看 CPU 使用率靠谱得多。比如发现 sync.Mutex 的争用热点，或大量 runtime.mcall 调用，说明上下文切换太频繁。
实操步骤：
- 启动程序时加
http.ListenAndServe("localhost:6060", nil)，然后go tool pprof http://localhost:6060/debug/pprof/profile?seconds=30 - 重点看
top -cum输出里是否出现runtime.futex、runtime.usleep占比过高 - 用
go tool pprof -http=:8080 cpu.pprof查看火焰图，若大量扁平分支集中在chan send或map assign，说明通信/共享数据结构成了瓶颈
区分 CPU 密集型与 IO 密集型任务的线程数配置
盲目设 runtime.GOMAXPROCS(runtime.NumCPU()) 对 CPU 密集型任务合理，但对混合型或 IO 等待多的任务反而拖慢——因为 Goroutine 会因等待被调度器挂起，空出的核心被闲置，而新 Goroutine 又不断创建挤占栈内存。
- CPU 密集型（如矩阵计算、编解码）：设
runtime.GOMAXPROCS(runtime.NumCPU())或runtime.NumCPU() + 1 - IO 密集型（如 HTTP 批量请求、文件读写）：可设更高，但需配合短超时和连接池，否则只是堆积 goroutine
- 混合型：拆分逻辑，用不同
sync.Pool或独立 worker group 控制并发粒度，避免一把梭
注意 runtime.GOMAXPROCS 的生效时机和作用域
runtime.GOMAXPROCS(n) 不是“最多用 n 个核心”，而是“最多有 n 个 OS 线程能同时执行 Go 代码”。它只影响 M:P 绑定关系，不控制操作系统调度器本身。如果程序里有大量 syscall 或阻塞 C 函数调用，仍可能突破该限制。
容易踩的坑：
- 在
init()里调用runtime.GOMAXPROCS无效——必须在main()开头或更早（如func main() { runtime.GOMAXPROCS(runtime.NumCPU()) }） - 动态修改后，已存在的 goroutine 不会立刻迁移，新 goroutine 才受约束
- 容器环境（如 Kubernetes）下，
runtime.NumCPU()返回的是宿主机核数，不是limits.cpu限制值，得用cgroups接口读取实际配额
真实加速比永远卡在串行段、通信开销和内存带宽上，而不是你开了多少 goroutine。测的时候别只盯着数字，要进 pprof 看调度痕迹，进 /sys/fs/cgroup 看资源配额，否则优化就是调参幻觉。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
