Go runtime/metrics.Read 怎么复用 Sample 切片减少采集分配

周期采集 Go 运行时指标时，真正容易产生重复开销的地方往往不是 metrics.Read 这一行，而是每轮都重新创建并填充 []metrics.Sample。正确的做法是先确定要采集的指标名称，把它们放进固定长度的切片，后续重复调用 metrics.Read 时复用同一组元素。

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

复用的核心是“复用 Sample 容器，不复用正在被另一 goroutine 读取的结果”。同一采集器可以跨轮次使用一组切片；并发采集则要给每个任务独立的底层数组，必要时再深拷贝 histogram 等指针型结果。

• 先准备指标名，再按固定长度创建 []metrics.Sample。
• 每轮只调用 metrics.Read(samples)，不要在循环里反复 make。
• 读取结果前判断 Value.Kind()，未知名称对应 KindBad。

先把指标名称和 Sample 容器分开准备

metrics.Sample 由 Name 和 Value 组成。调用 Read 前，名称必须已经放入切片；调用后，运行时填充每个元素的 Value。因此可以把“准备容器”放到采集器初始化阶段，把“读取值”留在定时循环里。

package main

import (
	"fmt"
	"runtime/metrics"
)

type Collector struct {
	samples []metrics.Sample
}

func NewCollector(names []string) *Collector {
	// 初始化阶段只分配一次容器，并保存每个样本对应的指标名。
	samples := make([]metrics.Sample, len(names))
	for i, name := range names {
		samples[i].Name = name // Read 会按 Name 填充对应的 Value。
	}
	return &Collector{samples: samples}
}

func (c *Collector) Read() {
	// 每轮复用同一个底层数组，避免按采集周期重复 make。
	metrics.Read(c.samples)
	for _, sample := range c.samples {
		// 未支持的指标会得到 KindBad，不能直接调用 Uint64 或 Float64。
		if sample.Value.Kind() == metrics.KindBad {
			fmt.Printf("skip unsupported metric: %s\n", sample.Name)
			continue
		}
		fmt.Printf("%s: %v\n", sample.Name, sample.Value.Kind())
	}
}

这里的复用对象是切片的底层存储，而不是把上一次采集结果永久保存下来。每次 Read 都会覆盖对应的 Value；如果业务要把结果交给异步处理，应在交接前复制需要的数据。

用固定长度切片批量读取，按 Kind 取出值

如果指标集合是明确的，固定长度的 make 比在每一轮用 append 逐步扩容更直观。批量读取后，先看 Kind 再调用对应方法：KindUint64 使用 Uint64，KindFloat64 使用 Float64，直方图则使用 Float64Histogram。

type Snapshot struct {
	HeapObjects uint64
	Goroutines  uint64
	HeapGoal    uint64
}

func (c *Collector) Snapshot() (Snapshot, error) {
	// Read 会覆盖 c.samples 的 Value，因此本方法要在同一采集器上串行调用。
	metrics.Read(c.samples)
	var out Snapshot
	for i := range c.samples {
		sample := &c.samples[i]
		switch sample.Name {
		case "/gc/heap/objects:objects":
			if sample.Value.Kind() != metrics.KindUint64 {
				return Snapshot{}, fmt.Errorf("unexpected kind for %s", sample.Name) // 防止错误类型调用导致 panic。
			}
			out.HeapObjects = sample.Value.Uint64()
		case "/sched/goroutines:goroutines":
			if sample.Value.Kind() == metrics.KindUint64 {
				out.Goroutines = sample.Value.Uint64() // 只读取与指标约定一致的类型。
			}
		case "/gc/heap/goal:bytes":
			if sample.Value.Kind() == metrics.KindUint64 {
				out.HeapGoal = sample.Value.Uint64()
			}
		}
	}
	return out, nil
}

固定长度并不意味着指标名称永远不变。如果程序希望跟随不同 Go 版本的支持集合，应先根据 metrics.All() 选择需要的描述，再一次性重建 Sample 切片；不要在正在读取的切片上同时改名。

把复用封装在采集器里，隔离并发读取

官方文档允许多个 Read 并发执行，但各次调用的参数不能共享底层内存。换句话说，复用适合“同一个采集器的多轮串行调用”，不适合把一个全局 samples 切片交给多个 goroutine。

type Worker struct {
	collector *Collector
}

func (w *Worker) Collect() Snapshot {
	// 由调度器保证同一个 Worker 不会被并发调用，保护可复用的底层数组。
	snapshot, err := w.collector.Snapshot()
	if err != nil {
		return Snapshot{} // 采集失败时返回空快照，由上层决定是否告警。
	}
	return snapshot
}

func newWorkers(names []string, n int) []*Worker {
	workers := make([]*Worker, n)
	for i := range workers {
		// 每个 Worker 都有独立 Collector，避免 Read 参数共享底层内存。
		workers[i] = &Worker{collector: NewCollector(names)}
	}
	return workers
}

如果采集结果要异步发送，不能只把 metrics.Value 或 histogram 指针塞进队列后继续下一轮读取。需要保留的数值应先提取到自有结构体；histogram 的 Buckets 和 Counts 则按业务需要复制，避免后续复用影响已交出的数据。

什么时候应该重建切片

有三种情况不宜强行复用原切片：采集指标集合发生变化、并发调用无法保证独立底层数组、以及下游需要长期持有本轮结果。前两种情况应重建容器，最后一种情况应复制结果，而不是把可变的采集器内部状态暴露出去。

常见问题

复用 Sample 切片会让 Value 自动累加吗？

不会。每次 Read 是按当前运行时状态重新填充 Value；是否累加、求速率或保留历史，要由调用方另行保存上一份快照。

未知指标是否应该直接调用 Uint64？

不应该。名称不在 metrics.All() 中时，Value 会是 KindBad。先判断 Kind，再调用对应取值方法。

能不能把同一个 Sample 切片放进 sync.Pool？

可以把对象池作为更大的生命周期设计，但归还前必须确保没有读者继续使用它，并且每次取出后重新确认指标名称和长度。对于固定串行采集，直接让采集器持有一组切片通常更简单。

总结一下：把指标名和 Sample 切片在初始化阶段准备好，周期任务中重复调用 metrics.Read；用 Value.Kind() 守住类型边界；并发场景为每个采集器分配独立底层数组，需要跨轮次保存时复制结果。这样才能把切片复用带来的分配收益和数据安全同时保留下来。