拓冰网站优化 
Go 开发中最难排查的问题之一不是 panic而是 Goroutine Leak。一个 Goroutine 泄漏不会导致程序崩溃。它只是一直存在——可能阻塞在 channel、等待 Mutex、或者卡在 WaitGroup。随着时间推移Goroutine 数量越来越多内存越来越大GC 压力越来越高服务越来越慢。很多线上事故最后定位出来都是 Goroutine 泄漏。过去我们通常依赖runtime.NumGoroutine()或者pprof.Lookup(goroutine)看看 Goroutine 有没有持续增长。但是这些方法只能告诉你“Goroutine 变多了”却不知道“到底是哪几个 Goroutine 再也醒不过来了”。Go 1.26 引入了一个实验特性goroutineleak profile它第一次能够告诉你哪些 Goroutine 已经永久泄漏。这篇文章我们看看它到底是怎么工作的。为什么 Goroutine 会泄漏很多人理解 Goroutine 泄漏就是“Goroutine 一直没有退出”其实并不准确。真正的问题是这个 Goroutine 已经永远没有机会退出。funcmain(){ch:make(chanstruct{})gofunc(){-ch fmt.Println(exit)}()}程序结束之前这个 Goroutine 一直等待-ch。但如果没人发送、没人 close它会一直阻塞。但这里只是“阻塞”还不能称之为“泄漏”因为仍然可以执行close(ch)或ch - struct{}{}让它恢复运行。真正的泄漏是什么funcleak(){ch:make(chanstruct{})gofunc(){-ch}()time.Sleep(time.Second)}很多人第一次看觉得和刚才没区别其实区别巨大。函数返回以后局部变量ch已经消失整个程序已经没有任何地方保存这个 Channel。也就是说没有任何 Goroutine 还能找到这个 Channel没人发送、没人 close、没人唤醒。等待这个 Channel 的 Goroutine永远醒不过来。这才是真正意义上的Goroutine Leak。为什么以前检测不了pprof 能看到goroutine profile例如goroutine 235 waiting channel receive问题来了如果线上有 30000 个 Goroutine你怎么知道哪个是真泄漏、哪个只是等待数据库或 RPCpprof 只能告诉你“现在阻塞了”却不知道“未来还能不能恢复”。这是最大的区别。Go 1.26 是怎么做到的答案只有一个词GC 可达性分析Reachability Analysis很多人知道 GC 会扫描对象却不知道 Go Runtime 本身已经知道哪些对象还活着、哪些已经没人引用。例如main()→ch→goroutine。如果main()返回了那么ch已经没有任何 Root 可以访问GC 会认为这个 channel 不可达。Go 1.26 新增了一步GC 扫描结束以后Runtime 会检查有没有 Goroutine 正在等待一个已经不可达的同步对象。如果有直接标记为Leak。这个过程几乎没有额外性能开销因为 GC 已经完成了所有扫描Runtime 只是多看了一眼。一个简单的实验开启实验功能GOEXPERIMENTgoroutineleakprofile go run .funcleak(){ch:make(chanstruct{})gofunc(){-ch}()time.Sleep(time.Second)}funcmain(){leak()time.Sleep(5*time.Second)pprof.Lookup(goroutineleak).WriteTo(os.Stdout,1)}输出goroutineleak profile: total 1 main.leak.func1 main.go:12这里最重要的信息不是total 1而是main.go:12。Runtime 已经直接告诉你泄漏发生在哪一行。相比传统 goroutine profile不再需要人工分析几十页堆栈。它和 Goroutine Profile 有什么区别goroutinegoroutineleak当前有哪些 Goroutine哪些 Goroutine 永远不会恢复包括正常阻塞只包含真正泄漏需要人工分析Runtime 自动判断适合性能分析适合排查内存泄漏一句话概括goroutine profile 告诉你“现在在等什么”goroutineleak profile 告诉你“以后也等不到了”。它是不是万能答案不是。varchmake(chanstruct{})funcmain(){gofunc(){-ch}()select{}}这里 channel 一直存在全局变量GC 会认为可达所以goroutineleak不会报告。虽然业务角度它可能也是永远阻塞但 Runtime 无法证明未来不会close(ch)因此不会误报。什么时候值得开启目前GOEXPERIMENTgoroutineleakprofile仍属于实验特性更适合本地开发、单元测试、压力测试CI 自检需谨慎。不建议直接依赖它作为线上监控手段因为 API 和行为仍可能在正式版本中发生变化。总结Go 过去一直能够告诉我们 Goroutine 有多少却无法判断哪些 Goroutine 已经“死亡但未退出”。goroutineleakProfile 的出现第一次将GC 可达性分析与并发调试结合起来它不是统计 Goroutine而是判断 Goroutine 是否还存在恢复执行的可能。它并不能发现所有 Goroutine 泄漏例如等待全局 Channel 的场景仍然无法识别但对于最常见的局部 Channel、Mutex、WaitGroup 等同步对象生命周期结束后导致的永久阻塞它能够直接定位到具体代码位置大幅降低排查成本。对于 Go 开发者来说这个特性真正重要的不是新增了一个 Profile而是 Runtime 开始具备了主动识别并发泄漏的能力。这意味着未来 Go 在并发调试方面很可能会从“提供信息”逐步演进到“帮助定位问题”这也是 Go Runtime 调试能力的一次重要升级。 Go 1.26 新特性：终于可以自动检测 Goroutine 泄漏了
Go 开发中最难排查的问题之一不是 panic而是 Goroutine Leak。一个 Goroutine 泄漏不会导致程序崩溃。它只是一直存在——可能阻塞在 channel、等待 Mutex、或者卡在 WaitGroup。随着时间推移Goroutine 数量越来越多内存越来越大GC 压力越来越高服务越来越慢。很多线上事故最后定位出来都是 Goroutine 泄漏。过去我们通常依赖runtime.NumGoroutine()或者pprof.Lookup(goroutine)看看 Goroutine 有没有持续增长。但是这些方法只能告诉你“Goroutine 变多了”却不知道“到底是哪几个 Goroutine 再也醒不过来了”。Go 1.26 引入了一个实验特性goroutineleak profile它第一次能够告诉你哪些 Goroutine 已经永久泄漏。这篇文章我们看看它到底是怎么工作的。为什么 Goroutine 会泄漏很多人理解 Goroutine 泄漏就是“Goroutine 一直没有退出”其实并不准确。真正的问题是这个 Goroutine 已经永远没有机会退出。funcmain(){ch:make(chanstruct{})gofunc(){-ch fmt.Println(exit)}()}程序结束之前这个 Goroutine 一直等待-ch。但如果没人发送、没人 close它会一直阻塞。但这里只是“阻塞”还不能称之为“泄漏”因为仍然可以执行close(ch)或ch - struct{}{}让它恢复运行。真正的泄漏是什么funcleak(){ch:make(chanstruct{})gofunc(){-ch}()time.Sleep(time.Second)}很多人第一次看觉得和刚才没区别其实区别巨大。函数返回以后局部变量ch已经消失整个程序已经没有任何地方保存这个 Channel。也就是说没有任何 Goroutine 还能找到这个 Channel没人发送、没人 close、没人唤醒。等待这个 Channel 的 Goroutine永远醒不过来。这才是真正意义上的Goroutine Leak。为什么以前检测不了pprof 能看到goroutine profile例如goroutine 235 waiting channel receive问题来了如果线上有 30000 个 Goroutine你怎么知道哪个是真泄漏、哪个只是等待数据库或 RPCpprof 只能告诉你“现在阻塞了”却不知道“未来还能不能恢复”。这是最大的区别。Go 1.26 是怎么做到的答案只有一个词GC 可达性分析Reachability Analysis很多人知道 GC 会扫描对象却不知道 Go Runtime 本身已经知道哪些对象还活着、哪些已经没人引用。例如main()→ch→goroutine。如果main()返回了那么ch已经没有任何 Root 可以访问GC 会认为这个 channel 不可达。Go 1.26 新增了一步GC 扫描结束以后Runtime 会检查有没有 Goroutine 正在等待一个已经不可达的同步对象。如果有直接标记为Leak。这个过程几乎没有额外性能开销因为 GC 已经完成了所有扫描Runtime 只是多看了一眼。一个简单的实验开启实验功能GOEXPERIMENTgoroutineleakprofile go run .funcleak(){ch:make(chanstruct{})gofunc(){-ch}()time.Sleep(time.Second)}funcmain(){leak()time.Sleep(5*time.Second)pprof.Lookup(goroutineleak).WriteTo(os.Stdout,1)}输出goroutineleak profile: total 1 main.leak.func1 main.go:12这里最重要的信息不是total 1而是main.go:12。Runtime 已经直接告诉你泄漏发生在哪一行。相比传统 goroutine profile不再需要人工分析几十页堆栈。它和 Goroutine Profile 有什么区别goroutinegoroutineleak当前有哪些 Goroutine哪些 Goroutine 永远不会恢复包括正常阻塞只包含真正泄漏需要人工分析Runtime 自动判断适合性能分析适合排查内存泄漏一句话概括goroutine profile 告诉你“现在在等什么”goroutineleak profile 告诉你“以后也等不到了”。它是不是万能答案不是。varchmake(chanstruct{})funcmain(){gofunc(){-ch}()select{}}这里 channel 一直存在全局变量GC 会认为可达所以goroutineleak不会报告。虽然业务角度它可能也是永远阻塞但 Runtime 无法证明未来不会close(ch)因此不会误报。什么时候值得开启目前GOEXPERIMENTgoroutineleakprofile仍属于实验特性更适合本地开发、单元测试、压力测试CI 自检需谨慎。不建议直接依赖它作为线上监控手段因为 API 和行为仍可能在正式版本中发生变化。总结Go 过去一直能够告诉我们 Goroutine 有多少却无法判断哪些 Goroutine 已经“死亡但未退出”。goroutineleakProfile 的出现第一次将GC 可达性分析与并发调试结合起来它不是统计 Goroutine而是判断 Goroutine 是否还存在恢复执行的可能。它并不能发现所有 Goroutine 泄漏例如等待全局 Channel 的场景仍然无法识别但对于最常见的局部 Channel、Mutex、WaitGroup 等同步对象生命周期结束后导致的永久阻塞它能够直接定位到具体代码位置大幅降低排查成本。对于 Go 开发者来说这个特性真正重要的不是新增了一个 Profile而是 Runtime 开始具备了主动识别并发泄漏的能力。这意味着未来 Go 在并发调试方面很可能会从“提供信息”逐步演进到“帮助定位问题”这也是 Go Runtime 调试能力的一次重要升级。