go 程序默认不自动利用全部 cpu 核心，需显式设置 gomaxprocs（环境变量或 runtime.gomaxprocs）才能释放多核并发能力；否则即使虚拟机分配了 4 核，服务仍仅在单 os 线程上调度 goroutine，导致性能无法随核心数提升。
go 程序默认不自动利用全部 cpu 核心，需显式设置 gomaxprocs（环境变量或 runtime.gomaxprocs）才能释放多核并发能力；否则即使虚拟机分配了 4 核，服务仍仅在单 os 线程上调度 goroutine，导致性能无法随核心数提升。
Go 的并发模型基于 Goroutine + M:N 调度器（GMP 模型），其性能能否随物理 CPU 核心数线性提升，关键取决于 P（Processor）的数量 —— 即 Go 运行时允许并行执行用户代码的逻辑处理器个数。P 的数量由 GOMAXPROCS 控制，默认值在 Go 1.5 之前恒为 1；自 Go 1.5 起，默认值等于系统可用逻辑 CPU 数（即 runtime.NumCPU()）。但该行为仅在程序启动时生效，且可能被环境变量或显式调用覆盖。
因此，当您在 VirtualBox 中将虚拟 CPU 从 1 核升级至 4 核后，若未重启 Go 进程或未显式设置 GOMAXPROCS，运行时仍可能沿用旧值（尤其在容器/VM 环境中，runtime.NumCPU() 有时未能及时感知 CPU 变更），导致所有 goroutine 被限制在单个 P 上串行调度，无法真正并行——这正是您观察到“增加核心无性能提升”的根本原因。
✅ 正确启用多核的两种方式
方式一：通过环境变量（推荐，无需改代码）
# 启动前设置，对所有 Go 程序生效 export GOMAXPROCS=4 go run main.go
或直接在命令行中临时指定：
GOMAXPROCS=4 go run main.go
方式二：代码中显式调用（需在 main 开头尽早设置）
package main
import (
"net/http"
"runtime" // 必须导入
)
func main() {
runtime.GOMAXPROCS(4) // ⚠️ 必须在任何 goroutine 启动前调用！
http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
w.Header().Set("Content-Type", "text/plain")
w.Write([]byte("Hello World"))
})
http.ListenAndServe(":80", nil)
}? 注意：runtime.GOMAXPROCS(n) 应在 main 函数最开始调用，确保在 http.ListenAndServe（它会启动监听 goroutine）之前完成设置。延迟调用可能导致部分 goroutine 已在旧 P 配置下启动，影响效果。
? 为什么 ab 测试未体现提升？——客户端瓶颈分析
您观察到 wrk 在设置 GOMAXPROCS=4 后 QPS 提升显著（从 ~26k → ~58k），但 ab 结果几乎不变（~7k）。这不是 Go 的问题，而是 ab（Apache Bench）自身架构限制：
- ab 是单线程工具（仅使用 1 个 OS 线程发起请求），无法生成足够并发压力来压满服务端多核能力；
- 它的连接复用、事件循环效率远低于 wrk（基于 epoll/kqueue 的多线程异步 I/O）；
- 当服务端已能轻松处理每秒数万请求时，ab 成为瓶颈：它自己发不出那么多请求，自然测不出服务端的真实吞吐上限。
✅ 验证建议：始终使用多线程压测工具（如 wrk -t4、hey -c1000 -z30s 或 fortio）评估 Go 服务的多核性能；ab 仅适用于粗略功能验证。
? 性能对比总结（基于您的测试数据）
| 配置 | GOMAXPROCS | 压测工具 | 并发模型 | QPS（近似） | 关键结论 |
|---|---|---|---|---|---|
| 1 核 VM | 默认 1 | wrk -t1 | 单线程客户端 + 单 P 服务端 | ~24k | 基准线 |
| 4 核 VM | 未设 / 仍为 1 | wrk -t1 | 单线程客户端 + 单 P 服务端 | ~26k | 无提升 → P 未扩容 |
| 4 核 VM | GOMAXPROCS=4 | wrk -t1 | 单线程客户端 + 4P 并行服务端 | ~48k | +100% → 多核生效 |
| 4 核 VM | GOMAXPROCS=4 | wrk -t4 | 多线程客户端 + 4P 服务端 | ~59k | 逼近理论峰值 |
✅ 真实生产环境中，还应结合 pprof 分析 CPU/内存/阻塞情况，并确保业务逻辑无全局锁、无长耗时同步操作，才能持续获得线性扩展收益。
? 注意事项与最佳实践
- 不要盲目设为 runtime.NumCPU()：在容器化环境（Docker/K8s）中，runtime.NumCPU() 返回的是宿主机 CPU 数，而非容器 --cpus 限制值。应优先读取 GOMAXPROCS 环境变量，或通过 cgroup 接口获取容器实际配额。
- Go 1.21+ 支持自动调整：新版 Go 引入了 GODEBUG=schedulertrace=1 和实验性 GOMAXPROCS=auto（需 Go 1.22+），可让运行时根据负载动态调优 P 数，但生产环境仍建议显式固定以保稳定。
- I/O 密集型服务更受益：HTTP 服务本质是 I/O 密集型（网络读写、TLS 加解密），多 P 能显著提升并发连接处理能力；而纯计算密集型任务需注意 goroutine 是否真正在不同 P 上并行执行（避免因 GC 或调度延迟导致伪并行）。
掌握 GOMAXPROCS 的语义与时机，是解锁 Go 高性能服务的关键第一步——它不是“魔法开关”，而是对 Go 调度器的一次精准校准。
