go单进程无法仅靠堆协程吃满多核，关键在gomaxprocs控制并行度而非协程数；io密集型任务受netpoller单线程限制，即使gomaxprocs设高也难利用多核。
Go单进程无法靠“堆协程”就吃满多核，关键在调度器是否能并行执行——这由 GOMAXPROCS 控制，而非协程数量本身。
为什么开了100个goroutine却只跑一个核
Go 1.5+ 默认把 GOMAXPROCS 设为 runtime.NumCPU()，但如果你的程序没做任何 CPU 密集型工作（比如全是 time.Sleep、net.Conn.Read 或 channel 阻塞），那所有 goroutine 仍可能被调度到同一个 OS 线程上“并发”执行，而不是“并行”运行。
- goroutine 是调度单位，不是执行单位；真正跑在 CPU 核上的，是 OS 线程（M）
-
GOMAXPROCS控制的是“可同时执行 Go 代码的 P（逻辑处理器）数量”，它限制了并行上限 - IO 密集型任务（如 HTTP 处理）天然受限于 netpoller 架构：整个进程只有一个轮询线程，即使
GOMAXPROCS=32，epoll_wait也只在一个线程里调
如何确认当前 GOMAXPROCS 是否生效
别猜，直接查。在 main 入口加两行：
fmt.Printf("GOMAXPROCS = %d, NumCPU = %d\n", runtime.GOMAXPROCS(0), runtime.NumCPU())
注意：runtime.GOMAXPROCS(0) 是读取当前值，不是设为 0；设为 0 会 panic。
- 如果输出是
GOMAXPROCS = 1，说明被显式改过或运行在旧版 Go（ - 如果输出是
GOMAXPROCS = 8但 top 里 CPU% 始终集中在一个核，大概率是程序没真正并行——比如所有 goroutine 都在等同一个 mutex，或都在刷日志锁 - Linux 下可用
ps -T -p $(pgrep yourprog) | wc -l查实际 OS 线程数，应接近GOMAXPROCS值（但不严格相等，因 runtime 会按需创建 M）
CPU密集型任务必须满足的三个条件
想让多核真正转起来，光开 goroutine + 调大 GOMAXPROCS 不够，还得让每个 goroutine 干“真活”：
- 任务不能被锁阻塞：避免多个 goroutine 争抢同一把
sync.Mutex，否则它们排队串行执行 - 不能依赖共享内存做同步：用 channel 拆分输入/输出边界，让每个 goroutine 拿到独立数据块（如
[][]int分片） - 计算必须足够重：单个 goroutine 运行时间太短（
示例：对一个大 slice 求和，错误写法是让所有 goroutine 累加到同一个 sum 变量；正确做法是每个 goroutine 算自己的分段，最后用 channel 收集再合并。
网络服务场景下多核利用率低的真实原因
HTTP server、gRPC server 这类 IO 密集型服务，在单进程内很难靠调高 GOMAXPROCS 提升吞吐——因为 Go 的 netpoller 是全局单实例，所有连接事件都由一个 OS 线程驱动。
-
runtime.LockOSThread()对提升网络性能无效，反而容易卡死 - 试图用 goroutine 绕过这个限制（比如自己起多个
http.Server监听不同端口）也没用：只要共用一个进程，底层还是走同一个 poller - 生产环境真实解法是多进程：用
SO_REUSEPORT（Linux）或前端负载均衡分发请求，每个 Go 进程独占一组 CPU 核与 NUMA 内存节点
单进程多协程模型适合“高并发、低计算、强 IO”的场景；一旦出现 CPU 成为瓶颈，就得跨进程，而不是继续往一个进程里塞 goroutine。
