Go runtime.GoroutineProfile 返回数量变化时怎么重试

runtime.GoroutineProfile 返回的数量在两次调用之间发生变化时，正确做法是始终检查第二个返回值 ok：若为 false，说明切片仍然太小，函数没有修改目标切片，应根据这次返回的新 n 重新分配并再次调用。重试必须同时设置次数上限和记录数上限，不能无限循环。

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

第一次调用只用于估算当前记录数；真正可信的是成功调用返回的 n, true。成功后使用 records[:n]，失败时丢弃本轮切片并按新数量重试。

为什么第一次得到的 n 不能直接当最终数量

常见写法是先传入 nil 切片得到数量，再创建等长切片：

// 第一次调用只查询当前需要的记录数。
n, _ := runtime.GoroutineProfile(nil)
records := make([]runtime.StackRecord, n)

// 第二次调用期间 goroutine 数量可能已经变化。
n, ok := runtime.GoroutineProfile(records)

问题在于查询和采集不是同一个不可分割操作。两次调用之间，其他 goroutine 可以创建或退出。官方契约明确规定：

• 当 len(p) >= n 时，函数把记录复制到 p，返回 n, true。
• 当 len(p) 时，函数不会修改 p，返回新的 n, false。
• 因此 ok=false 不是“拿到部分结果”，而是“本轮没有可用快照”。

三种方案怎么选

这个问题容易被写成“切片不够就再分配”，但实际选择取决于你最终要什么结果。

如果只是排查线上 goroutine 堆积并保存快照，优先考虑 runtime/pprof。只有确实需要结构化 StackRecord，例如在程序内做受控聚合时，才值得直接处理 GoroutineProfile 的重试。

推荐的有界重试写法

下面的函数加入了三项保护：初始容量余量、最大重试次数、最大记录数。余量可以减少高并发程序里“刚分配完又不够”的概率；上限则避免异常环境下持续扩容。

package gprofile

import (
    "fmt"
    "runtime"
)

const (
    maxAttempts = 5
    maxRecords  = 200_000
)

// headroom 在当前数量上增加 25% 和至少 16 条余量。
func headroom(n int) int {
    extra := n / 4
    if extra  maxRecords {
        return nil, fmt.Errorf(
            "goroutine profile needs %d records, limit is %d",
            needed,
            maxRecords,
        )
    }

    size := headroom(needed)
    if size > maxRecords {
        size = maxRecords
    }

    for attempt := 1; attempt  maxRecords {
            return nil, fmt.Errorf(
                "goroutine profile grew to %d records, limit is %d",
                n,
                maxRecords,
            )
        }

        size = headroom(n)
        if size > maxRecords {
            size = maxRecords
        }
    }

    return nil, fmt.Errorf(
        "goroutine profile kept changing after %d attempts",
        maxAttempts,
    )
}

每一轮都创建新切片，而不是假设失败切片里有部分有效数据。官方文档保证容量不足时 p 不会改变，但新切片的写法更直观，也避免后续代码误读旧内容。

为什么要加余量，而不是只按返回的 n 分配

严格按 n 分配是正确但偏乐观的策略：如果系统正在快速创建 goroutine，下一次调用仍可能发现容量不足。加入小比例余量不会改变正确性，只是用可控内存换取更高的一次成功概率。

余量并非越大越好。选择时看三项约束：

• 调用频率：偶发诊断可以接受一次额外分配，周期性采集要更关注内存抖动。
• 服务规模：已知 goroutine 数量稳定时，25% 加固定小余量通常足够表达策略；不要把示例常量当成通用标准。
• 失败预算：超过记录上限或重试上限时，应返回错误并由调用方降级，而不是继续扩大内存。

什么时候应该直接用 runtime/pprof

Go 官方文档明确提示，大多数客户端应使用 runtime/pprof，而不是直接调用 GoroutineProfile。如果目标是把快照写入文件、响应体或诊断缓冲区，可以这样做：

package gprofile

import (
    "fmt"
    "io"
    "runtime/pprof"
)

// WriteSnapshot 把标准 goroutine profile 写给调用方提供的 Writer。
func WriteSnapshot(w io.Writer, debug int) error {
    profile := pprof.Lookup("goroutine")
    if profile == nil {
        return fmt.Errorf("goroutine profile is unavailable")
    }

    // debug=0 写压缩协议格式；debug=1 写可读旧文本格式。
    if err := profile.WriteTo(w, debug); err != nil {
        return fmt.Errorf("write goroutine profile: %w", err)
    }
    return nil
}

debug=2 对预定义的 goroutine profile 有特殊含义，会输出类似程序因未恢复 panic 终止时的 goroutine 堆栈形式。若后续要交给 pprof 工具，选择 debug=0；若是人工快速阅读，才考虑文本模式。

不适合的重试方式

只看 n，不看 ok

当 ok=false 时，目标切片没有被写入。即使返回的 n 看起来合理，也不能把当前切片当作部分结果。

用 runtime.NumGoroutine 代替第一次查询

NumGoroutine 返回调用时存在的 goroutine 数量，但它不是 GoroutineProfile 的容量协商接口。既然目标函数已经返回所需记录数，就应以它的 n 为准。

循环直到成功但没有上限

在 goroutine 数量持续增长的进程中，无上限循环可能反复分配大切片。诊断代码同样要有资源边界，超过预算时返回明确错误。

每次固定翻倍

固定翻倍简单，但可能比返回的实际需求多分配很多。更稳妥的做法是从新 n 出发增加小余量，同时应用硬上限。

决策清单

• 需要 []runtime.StackRecord：使用有界重试的 GoroutineProfile。
• 需要标准剖析文件或写入 Writer：使用 pprof.Lookup("goroutine").WriteTo。
• 只需要临时可读文本：评估 runtime.Stack。
• ok=false：丢弃本轮结果，按新 n 扩容。
• ok=true：只使用 records[:n]。
• 超过次数或容量上限：返回错误，让调用方记录、降级或稍后重试。

常见问题

第二次调用的 n 比第一次小怎么办？

只要 ok=true，使用 records[:n] 即可，多出来的容量只是预留空间，不属于结果。

失败后能继续使用原切片吗？

容量不足时官方契约说明目标切片不会被修改，但它也不包含本轮快照。最清楚的做法是丢弃它，按新数量重新分配。

重试期间得到的是同一个时刻的快照吗？

不是。goroutine 集合可以在调用之间变化。成功返回表示该次调用获得了可容纳的完整记录集，不代表和最初查询时刻完全一致。

最大记录数应该设多少？

应根据服务规模、诊断频率和可接受内存预算决定。示例中的常量用于展示边界设计，不是所有项目都应照搬的固定值。

处理 GoroutineProfile 的关键不是预测 goroutine 数量，而是遵守 n, ok 契约：失败就按新数量有界重试，成功就截取 [:n]，只需要标准诊断快照时则优先使用 runtime/pprof。