Go runtime.NumGoroutine 统计值为什么会突然下降

先说结论：runtime.NumGoroutine() 返回的是调用时刻仍然存在的 goroutine 数量，不是进程启动以来创建过的总数。某一轮采样下降，通常说明临时任务结束了，或者采样时刻刚好跨过了多个 goroutine 的退出点；只有在持续采样后仍然出现异常增长、退出路径不完整或 profile 中堆积在同一等待点，才值得按泄漏方向继续查。

官方文档：https://pkg.go.dev/runtime#NumGoroutine

runtime.NumGoroutine 读到的是调用时刻的当前存在量

官方定义很直接：它返回“当前存在”的 goroutine 数量。这里的“当前”是调用发生的那个瞬间，所以每次调用得到的都是一个状态读数。一个 goroutine 从 go 语句创建出来后会进入运行或等待状态；函数返回、调用 runtime.Goexit，或因所在任务结束而退出后，它就不再属于当前存在量。

因此，创建了 100 个短任务并不意味着之后一直会看到“基础数量 + 100”。如果采样发生在任务启动前、任务运行中和任务结束后，三个读数自然可能不同。调用方也不需要把这个值理解为累计计数器，它更适合回答“此刻大约有多少 goroutine 还活着”。

package main

import (
    "fmt"
    "runtime"
    "time"
)

func sample(label string) {
    // 只记录调用瞬间的当前存在量，不把它当成累计创建数。
    fmt.Printf("%s: %d\\n", label, runtime.NumGoroutine())
}

func main() {
    sample("启动任务前")
    done := make(chan struct{})
    go func() {
        // 用信号控制短任务的退出，便于观察数量变化的来源。
        defer close(done)
        time.Sleep(20 * time.Millisecond)
    }()
    sample("任务运行中")
    

为什么第二次采样会下降

最常见的原因是短任务自然结束。批量处理、超时控制、一次性通知和临时 worker 都可能在很短时间内创建并退出 goroutine。第一次调用发生在它们还活着时，第二次调用发生在它们已经返回后，读数下降是正常的生命周期变化。

第二个原因是采样窗口不同。NumGoroutine 不是一个带历史快照的趋势接口；调用过程与其他 goroutine 的创建、阻塞、唤醒和退出是并发发生的。即使业务逻辑没有改变，两个相邻采样点之间也可能恰好跨过退出边界。

第三个原因是把不同进程、不同测试用例或不同服务实例的读数放在一起比较。应先确认采样来自同一个进程，并记录采样时间、实例标识和触发场景，否则“下降”可能只是观测对象变了。

连续采样怎样区分正常波动与 goroutine 堆积

排查时不要只打印一次。可以按固定间隔记录一段时间，把每次读数与业务事件放在同一条日志上下文里。短任务对应的数量通常会回落到稳定区间；泄漏嫌疑则表现为基线持续抬高，或者退出后仍有一批 goroutine 长时间停在相同的等待栈。

package main

import (
    "fmt"
    "runtime"
    "runtime/pprof"
    "os"
    "time"
)

func observe() {
    ticker := time.NewTicker(500 * time.Millisecond)
    defer ticker.Stop() // 观察结束时释放 ticker，避免留下定时器资源。
    for range ticker.C {
        // 连续记录当前数量，才能区分一次波动和持续趋势。
        fmt.Printf("goroutines=%d\\n", runtime.NumGoroutine())
    }
}

func dumpGoroutines() {
    // profile 用来查看 goroutine 当前停在哪里，不等同于 NumGoroutine 的计数。
    profile := pprof.Lookup("goroutine")
    if profile == nil {
        return
    }
    _ = profile.WriteTo(os.Stdout, 1) // 调试时把栈摘要写到标准输出。
}

当数量回落且 profile 中没有长期重复的等待栈时，优先检查业务任务是否按预期结束；当数量持续抬高时，再沿着 profile 中反复出现的 channel 接收、锁等待、网络读取或缺少关闭信号的位置检查退出路径。WaitGroup 计数没有归零、消费者没有退出、定时器或重试循环没有停止，才是更具体的排查线索。

排查时最容易出现的三个误判

• 把下降当成 GC 释放。goroutine 数量和堆内存是不同指标；不要用内存曲线替代 goroutine 生命周期判断。
• 把一次高值当成泄漏。启动阶段、批量请求和压测都会制造短时峰值，应先看回落后的基线。
• 只看数量不看栈。数量告诉你“还有多少”，profile 才能帮助定位“停在哪里”。两者要与业务退出信号一起解释。

一个实用的判断顺序是：确认采样对象相同，再看多次读数是否回到稳定区间；若没有回落，记录 goroutine profile 并按重复栈归类；最后回到创建点和退出点，检查是否有明确的关闭、取消或等待配对。

结论

runtime.NumGoroutine 下降通常只是当前存在量减少，不能单凭这个现象判断异常。把一次读数升级为连续采样，把数量趋势和 goroutine profile 结合起来，再核对任务的退出路径，才能区分正常波动与真正的 goroutine 堆积。

常见问题

NumGoroutine 能否用来判断 goroutine 泄漏？

它只能提供数量线索，不能单独下结论。需要观察一段时间的基线、业务负载和 profile 栈，确认是否有持续增长且无法回落的等待对象。

为什么同一段程序每次打印的数量不一样？

因为打印本身也是一次采样，其他 goroutine 可能在两个调用之间启动、阻塞或退出。将采样放在明确的业务事件附近，并用多次记录看趋势，比比较两个孤立数字更可靠。