Go 语言中 runtime.Stack 追踪 Goroutine 堆栈-Golang-PHP中文网

runtime.Stack常返回空或截断堆栈，因其默认仅捕获当前goroutine且缓冲区仅4KB；需传足够大buf（如64KB）并设第二参数为true才获取全部goroutine完整堆栈。

go 语言中 runtime.stack 追踪 goroutine 堆栈

runtime.Stack 为什么经常返回空或截断的堆栈？

因为 runtime.Stack 默认只捕获当前 goroutine 的堆栈，且默认缓冲区大小仅 4KB —— 多数嵌套调用稍深就会被截断。如果你在主 goroutine 或一个刚启动的轻量 goroutine 中调用它，很可能只看到几行 runtime 初始化代码，甚至返回 0 字节。

实操建议：

传入 buf 必须足够大（例如 make([]byte, 64*1024)），否则返回值是实际写入长度，小于 buf 长度即表示被截断
第二个参数设为 true 才会打印所有 goroutine 堆栈；设为 false 只抓当前 goroutine
别在 defer 中无条件调用它 —— 若 panic 已发生，部分 goroutine 可能已退出，堆栈不可靠

如何安全获取所有 goroutine 的完整堆栈用于诊断死锁？

死锁场景下，runtime.Gosched() 不起作用，但 runtime.Stack 仍可工作 —— 关键是避免依赖运行时调度器状态。最稳妥的方式是提前预留大 buffer，并在信号 handler 或独立 goroutine 中触发。

示例片段（非阻塞式采集）：

buf := make([]byte, 2*1024*1024) // 2MB 足够覆盖数千 goroutine
n := runtime.Stack(buf, true)
if n == len(buf) {
    // 仍可能截断，但概率极低；可 warn 或 fallback 到更小粒度采样
}
log.Printf("dumped %d bytes of goroutine stacks", n)

注意：runtime.Stack 是同步操作，若在高并发关键路径频繁调用，会导致显著停顿（尤其 all=true 时需遍历全部 goroutine 结构体）。生产环境建议仅在 SIGQUIT、pprof /debug/pprof/goroutine?debug=2 等受控入口使用。

使用Go语言搭建家庭相册系统-相关课件

下载

与 pprof 的 goroutine profile 对比：该选哪个？

runtime.Stack 返回的是即时、带源码行号的文本堆栈（类似 panic 输出），而 pprof.Lookup("goroutine").WriteTo 输出的是采样摘要（默认只含正在运行/阻塞的 goroutine，且无文件名和行号）。

选择依据：

查「此刻谁卡在 select/channel 上」→ 用 runtime.Stack(buf, true)，看完整阻塞点
查「长期存在但不该存在的 goroutine 泄漏」→ 用 pprof.Lookup("goroutine").WriteTo + diff 多次快照
想集成到 HTTP 接口暴露堆栈 → 直接复用 /debug/pprof/goroutine?debug=2，它底层就调了 runtime.Stack，且已处理好 buffer 和 charset