go 程序默认可能仅使用单个 os 线程（即单核），即使机器有多核，也会显示为“100% cpu 占用”；需显式启用多 goroutine 并合理配置 gomaxprocs，才能真正发挥多核并行能力。
go 程序默认可能仅使用单个 os 线程（即单核），即使机器有多核，也会显示为“100% cpu 占用”；需显式启用多 goroutine 并合理配置 gomaxprocs，才能真正发挥多核并行能力。
在进行高性能基准测试（例如千万级插入操作）时，若观察到 main 进程在 Activity Monitor 或 top 中始终只占用约 100% CPU（如 8 核机器仅显示 100%，而非接近 800%），这通常意味着你的程序当前仅在一个 OS 线程上执行 —— 即 Go 的运行时默认将所有 goroutine 调度到单个 OS 线程（M:1 模式），除非显式启用多线程支持。
自 Go 1.5 起，GOMAXPROCS 默认值已设为机器逻辑 CPU 数（即 runtime.NumCPU()），因此多数现代 Go 环境无需手动设置即可启用多核调度。但以下情况仍可能导致单核瓶颈：
- 显式调用了 runtime.GOMAXPROCS(1)；
- 在旧版 Go（
- 所有计算密集型工作被串行写在 main goroutine 中，未启动额外 goroutine；
- 存在隐式同步（如共享变量未加锁、通道阻塞、或大量串行 I/O），导致并发无法真正并行化。
✅ 正确做法是：
-
确保 GOMAXPROCS 设置合理（通常无需干预，但可验证）：
fmt.Printf("GOMAXPROCS: %d, NumCPU: %d\n", runtime.GOMAXPROCS(0), runtime.NumCPU()) -
将负载分片并行处理，例如将 1000 万次插入拆分为 8 个 goroutine 各处理 125 万次：
const total = 10_000_000 const workers = 8 ch := make(chan int, total/1000) // 可选：用于结果收集或限流
var wg sync.WaitGroup for i := 0; i
⚠️ 注意事项： - **并非所有任务都适合并行化**：若缓存系统内部存在全局锁、串行日志写入、或强依赖顺序（如单一线性哈希表重建），增加 goroutine 反而引入竞争开销，性能可能下降； - **避免过度并发**：goroutine 数量 ≠ CPU 核心数，I/O 密集型任务可适度超配，但纯 CPU 密集型任务建议控制在 `GOMAXPROCS` 量级； - **使用 `pprof` 验证实际调度**：运行 `go tool pprof http://localhost:6060/debug/pprof/profile` 可查看是否真正利用多核（看 `Thread creation` 和 `Scheduler` 分布）。 总结：100% CPU 显示不是问题，而是信号——它提示你当前工作负载尚未并行化。真正的多核加速，依赖于**合理的任务切分 + 充足的 goroutine + 无竞争的并发设计**，而非简单增加协程数量。 benchmark 的价值，正在于暴露这类调度与设计层面的优化空间。
