goroutine 调度变慢主因是 gomaxprocs 与系统线程数不匹配、select 中滥用 default 导致自旋、hot path 频繁创建短命 goroutine、gc 分配速率过高及调度器资源争抢。
为什么 Goroutine 调度变慢了？先看 GOMAXPROCS 和系统线程数是否匹配
Go 运行时默认把 GOMAXPROCS 设为 CPU 逻辑核数，但如果你在容器里跑、或手动改过它，就容易出现调度器“等不到 P”——比如 runtime.Gosched() 频繁触发、大量 goroutine 卡在 runnable 状态却迟迟得不到执行。
- 用
runtime.GOMAXPROCS(0)查当前值；容器中建议显式设为cpu_count（别信runtime.NumCPU()，它读的是宿主机） - 若程序有大量 I/O 等待（如 HTTP server），
GOMAXPROCS太小会导致网络轮询器（netpoller）响应延迟，反而拖慢整体吞吐 - 设得太大（比如 1000）不会提升性能，只会增加调度器维护
P的开销，实测在 4–16 之间最稳
select 里加 default 会破坏 goroutine 阻塞语义
很多人用 select 做非阻塞通信，随手加 default，结果发现 goroutine 疯狂自旋、CPU 拉满。这不是 bug，是调度器被迫反复唤醒它去检查 channel 是否就绪。
- 真正需要“轮询”时，才用
default；否则该阻塞就阻塞，让 goroutine 进入waiting状态，调度器会跳过它 - 如果 channel 可能长期无数据（比如日志队列低峰期），用
time.After配合select做超时退出，比default+time.Sleep更省调度资源 - 注意：带
default的select在空 channel 上永远不阻塞，哪怕你本意是“试试看”，它也会每纳秒都抢一次调度时间片
避免在 hot path 上创建大量短命 goroutine
像 http.HandlerFunc 里每请求起一个 goroutine 处理业务，听着合理，但实际可能压垮调度器——不是因为并发高，而是因为 goroutine 创建/销毁本身有固定开销（约 2KB 栈 + 调度器登记 + GC 元信息）。
- 用 worker pool 控制并发数，比如
semaphore.NewWeighted(10)或简单 channel 控制令牌 - 别用
go func() { ... }()包一层就完事，尤其当函数体里有闭包捕获大变量时，会阻止栈收缩，导致内存常驻 - 观察
runtime.ReadMemStats().NumGoroutine，持续 >5k 且波动剧烈，大概率是 goroutine 泄漏或滥用；用pprof/goroutine?debug=2抓堆栈
GC 停顿影响调度公平性？别只盯着 GOGC
Go 1.22+ 的 GC 停顿已很短，但频繁的 GC 仍会让调度器“失焦”：比如 STW 阶段所有 goroutine 暂停，而 mark 阶段的辅助 GC（mutator assist）又会让部分 goroutine 主动让出时间片去帮 GC 扫描，造成响应毛刺。
立即学习“go语言免费学习笔记（深入）”；
-
GOGC=100是默认值，调低（如 50）会更早触发 GC，减少单次工作量，但增加频率；对 latency 敏感服务建议设为 75–85 - 真正伤调度的是分配速率（allocs/sec），不是堆大小；用
go tool pprof -alloc_space找高频分配点，比如fmt.Sprintf、切片重复make、结构体转interface{} - GC 不会直接杀死 goroutine，但它会让 runtime 把更多时间花在标记和清扫上，间接拉长其他 goroutine 的等待时间
goroutine 调度不是黑盒，它的瓶颈往往不在 Go 代码里，而在你没意识到的系统线程绑定、channel 使用模式、或者 GC 分配节奏上。调优时先抓 pprof/scheduler，再看 runtime.ReadSchedulerStats，别光盯着 goroutine 数量。
