Go runtime 怎样读取进程内存统计快照

在 Go 进程内部声明一个 runtime.MemStats，把地址传给 runtime.ReadMemStats(&m)，就能取得调用时的内存分配器统计。它不是操作系统的整进程 RSS：如果旧日志把 Sys 命名为“物理内存占用”，首先要迁移的是指标口径，而不是更换读取函数。

下面只调整采样记录与解读方式，不宣称该 API 是某个新版本新增，也不要求升级 Go。代码为可运行示例，本文未执行程序、未提供实测数值。

先把内存字段的统计口径改清楚

这些字段各自回答不同问题，不能把它们相加当作“总内存”。在已有面板中修改口径时，建议新增明确命名的字段，再让消费者迁移；不要悄悄改变旧字段的含义。

用局部变量取得一次完整快照

把下列内容保存为 main.go。每次调用都新建局部变量，函数返回值副本。输出保留字节整数，便于机器处理；显示 MiB 时可在展示层使用浮点除以 1024×1024，不要在采集层截断为整数 MiB。

package main

import (
    "encoding/json"
    "fmt"
    "os"
    "runtime"
    "time"
)

// snapshot 返回独立值，不把共享变量交给多个采样者。
func snapshot() runtime.MemStats {
    var m runtime.MemStats
    runtime.ReadMemStats(&m)
    return m
}

func main() {
    // 起止时刻只标记采集窗口，不声称精确的原子时钟时间。
    started := time.Now()
    m := snapshot()
    finished := time.Now()
    record := struct {
        Started string `json:"started"`
        Finished string `json:"finished"`
        GoVersion string `json:"go_version"`
        HeapAllocBytes uint64 `json:"heap_alloc_bytes"`
        TotalAllocBytes uint64 `json:"total_alloc_bytes"`
        SysBytes uint64 `json:"runtime_sys_bytes"`
        NumGC uint32 `json:"completed_gc_cycles"`
    }{
        started.Format(time.RFC3339Nano),
        finished.Format(time.RFC3339Nano),
        runtime.Version(),
        m.HeapAlloc,
        m.TotalAlloc,
        m.Sys,
        m.NumGC,
    }
    // 输出错误交给调用环境，不伪造成功日志。
    if err := json.NewEncoder(os.Stdout).Encode(record); err != nil {
        fmt.Fprintln(os.Stderr, err)
        os.Exit(1)
    }
}

# 在保存 main.go 的目录运行；本文未实际执行。
go run main.go

程序正常结束时应输出一条 JSON 记录，具体数值由运行环境决定。核对的是键名、单位和输出是否成功，不是复制某组固定数字。采集开始和结束时间包围了读取动作，不能把结束时间解释成所有字段唯一的硬件级采样时刻。

把旧日志改成可比较的采样记录

将旧的“memory”字段拆成明确的堆对象当前量、累计分配量和运行时系统量。示例中的 JSON 记录还保留了 Go 版本与采集窗口；多实例服务应由外层日志系统补充进程启动标识和实例标识。

若要计算区间分配量，只在同一进程实例内对后一次 TotalAlloc 减去前一次。进程重启后必须重建基线；发现计数回退先检查实例身份，不能直接做无符号减法得到巨大假值。HeapAlloc 本来就可能下降，不能按累计计数器处理。两次采样之间也包含程序其他 goroutine 的分配，因此差值不能直接归因于某一个业务函数。

升级后回归采样而不是硬比数字

更换 Go 工具链或调整负载后，沿用相同字段定义与单位，再比较同一负载条件下的趋势。不要以“升级后必须读出相同字节数”作为兼容性要求；运行时实现和对象分配方式可能变化。本文没有版本专属破坏性变更可供迁移，真正需要清理的是旧系统中的错误命名和错误差值算法。

ReadMemStats 不要求先调用 runtime.GC()。主动 GC 会改变被观察的状态，不适合作为普通采集的固定前置动作。当前官方实现包含停止与恢复 Go 执行的协调，读取不是零成本操作；不要在每个请求或紧循环中采样。可按业务需求采用低频集中采集，再评估自身延迟预算，本文不给出未经测量的通用安全频率。

迁移时依次确认：消费者能识别新字段；字节单位未改变；累计量只在同一实例内比较；采集端没有共享可变 MemStats；没有强制 GC；升级前后记录了版本与负载条件。这些是读者可执行的回归动作，不是本文已经完成的测试结果。

几个容易混淆的问题

读取快照必须等待下一次 GC 吗？

不需要。API 返回的是读取时的分配器统计，不是仅在最近一次完成 GC 时才更新的堆分析快照。

多个 goroutine 能共用一个 MemStats 变量吗？

不要让多个调用者同时写同一个变量，或在读取尚未完成时访问它。每次采样使用独立局部变量；若需要把最新结果发布给其他 goroutine，应由调用方设计互斥或值传递，而不是把运行时内部协调误认为对业务共享变量的保护。

HeapAlloc 上涨就能判定泄漏吗？

不能。单点读数无法区分正常负载增长、暂未回收对象与长期保留对象；需要在可比较条件下观察多次记录。本文的快照读取也不提供具体分配调用栈。

官方 API 与字段说明：https://pkg.go.dev/runtime#ReadMemStats、https://pkg.go.dev/runtime#MemStats。读取实现：https://go.dev/src/runtime/mstats.go。