goroutine启动耗时稳定在1–2微秒量级，实测基于runtime.nanotime()循环创建10万个空goroutine取均值；首几个略高因运行时初始化，p本地队列满时延迟升至约10微秒。
goroutine 启动时间到底多快？
实测数据表明，现代 Go（1.20+）在主流 x86_64 机器上，单个 go f() 的平均启动耗时稳定在 1–2 微秒 量级。这个数字不是理论值，而是基于 runtime.nanotime() 在循环中创建 10 万 goroutine 并取均值得到的实测结果。
关键点在于：这个开销几乎与 goroutine 执行体内容无关——哪怕 f() 是个空函数，成本也基本一致。真正影响启动速度的是栈分配策略和调度器入队路径。
- 首次创建 goroutine 会触发运行时内存池初始化，略微拉高首几个的耗时
- 若当前 P 的本地队列已满（默认容量 256），新 goroutine 会被打乱后批量推入全局队列，此时涉及锁操作，延迟上升至 ~10 微秒级
- 频繁创建+立即退出的短命 goroutine（如每请求启一个）会显著增加 GC 扫描压力，这不是启动慢，但会让整体吞吐下降
每个 goroutine 占多少内存？
初始栈大小确实是 2KB，但这是误导性起点。实际常驻内存远不止于此——运行时还需为每个 goroutine 分配 g 结构体（约 300–400 字节）、栈结构元信息、以及 GC 标记辅助字段。实测 10 万个空 goroutine 占用 RSS 约 450MB，即平均 ~4.5KB/个。
更关键的是栈增长机制：一旦执行中触发栈分裂（如递归调用或大局部变量），会分配新栈页（通常 2KB 或 4KB），旧栈不会立即释放，要等 GC 回收。这意味着峰值内存可能远超初始估算。
- 阻塞型 goroutine（如
time.Sleep或 channel 等待）仍持有完整栈，不释放 - 大量 goroutine 持有指向堆对象的指针，会拖慢 GC mark 阶段，尤其在 Go 1.22 前的 STW 期间
-
debug.SetGCPercent(-1)临时禁用 GC 可用于压测定位是否是 GC 成为瓶颈
GOMAXPROCS 对 goroutine 启动有影响吗？
没有直接影响。设置 GOMAXPROCS 只改变 P 的数量，而 goroutine 创建本身不依赖 P 数量。但间接影响显著：P 太少时，本地队列容易积压，导致更多 goroutine 被挤进全局队列；P 太多（比如设成 128）又会造成 M 频繁切换、缓存行失效加剧，反而降低单个 goroutine 的实际执行效率。
典型误判是认为“提高 GOMAXPROCS 就能更快启动 goroutine”——其实它只影响后续调度吞吐，不影响 go 关键字那一刻的成本。
- IO 密集型服务可适度上调（如
runtime.GOMAXPROCS(runtime.NumCPU()*2)），但不宜超过逻辑 CPU 数的 2 倍 - CPU 密集型任务应保持默认（等于物理核心数），避免上下文切换开销反超收益
- 用
pprof.Lookup("goroutine").WriteTo()定期采样，比盲目调参更可靠
什么时候该怀疑 goroutine 启动成了瓶颈？
极少情况。真正卡住的从来不是启动动作本身，而是启动之后的资源争抢或调度延迟。典型信号包括：
- pprof 中
runtime.mcall或runtime.gopark占比突增，说明大量 goroutine 在排队等待运行 - 观察
/debug/pprof/sched输出，若schedlatencyus（从就绪到开始执行的延迟）持续 > 100μs，说明 P 队列过载或 M 不足 - 系统级指标显示线程数（
ps -T -p $PID | wc -l）远超GOMAXPROCS，意味着频繁创建 M 来处理阻塞系统调用
这时候该看的不是“怎么让 go 更快”，而是“为什么这些 goroutine 启动后迟迟不干活”——大概率是 channel 阻塞、锁竞争或 netpoll 延迟导致的调度饥饿。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
