Go 的 runtime 包仅提供进程内存统计快照和 GC 指标，无法获取系统级 CPU 使用率或总内存容量；需通过 /proc/stat 或 gopsutil 获取 CPU 使用率，容器中应读取 cgroup 限制而非 runtime.NumCPU()。
Go 程序如何用 runtime 获取 CPU 和内存使用量
Go 标准库的 runtime 包能拿到当前进程的**内存统计快照**和**GC 相关指标**，但无法直接获取系统级 CPU 使用率（比如 72%）或总内存容量。它只告诉你“我的 goroutine 和堆用了多少”，不是“这台机器还有多少资源剩”。
实操建议：
-
runtime.ReadMemStats(&ms)是最常用方式，ms.Alloc是当前已分配并仍在使用的字节数，ms.Sys是 Go 向 OS 申请的总内存（含未释放的），ms.NumGC可判断 GC 频次是否异常升高 - 别依赖
ms.HeapSys或ms.TotalAlloc做实时告警阈值——它们是累计值或包含碎片，波动大；更适合趋势分析 - 每秒调用
ReadMemStats多次没意义，本身有锁且开销不小；建议 5–30 秒采样一次
为什么 runtime.MemStats 里的 Alloc 和 HeapInuse 差很多
这是常见困惑点：Alloc 是活跃对象占用的堆内存，而 HeapInuse = HeapAlloc + heap 碎片 + mspan/mcache 等运行时结构体开销。两者差值正常，尤其在大量小对象分配后。
关键区别：
Conventional Git
下载
Conventional Commits v1.0.0 分支、工作树命名及提交信息规范，适用于 GitHub 与 GitLab 项目，用于创建分支和命名工作树等场景。
立即学习“go语言免费学习笔记（深入）”；
-
Alloc：可被 GC 清理掉的对象实际占的内存，接近“应用层感知的内存用量” -
HeapInuse：运行时向堆管理器（mheap）申请、尚未归还 OS 的内存页总量，含元数据和内部碎片 -
HeapReleased为 0 不代表内存泄漏——Go 默认不主动把空闲页还给 OS（除非设置GODEBUG=madvdontneed=1）
想监控系统 CPU 使用率？得绕开 runtime
runtime 没提供 CPU percent 或 system uptime 这类 OS 层指标。必须调用系统接口或借助第三方库。
推荐做法：
- Linux 下读
/proc/stat计算 jiffies 差值（轻量、无依赖），示例逻辑如下：
cpu, _ := os.ReadFile("/proc/stat")
// 解析第一行 "cpu [user nice system idle ...]"，两次采样做 delta
- 跨平台需求强就用
github.com/shirou/gopsutil/v3/cpu，注意CPUInfo()是静态信息（型号/核数），要实时使用率得用CPUPercent(0, false) - 避免在 HTTP handler 里直接调
gopsutil——它会 fork+exec 或读多文件，可能阻塞；应单独 goroutine 定期采集并缓存
生产环境监控容易忽略的三个细节
很多人搭完基础指标就上线，结果告警不准或资源误判：
- 容器环境下
runtime.NumCPU()返回的是宿主机 CPU 数，不是 cgroups 限制值；需读/sys/fs/cgroup/cpu.max（cgroup v2）或/sys/fs/cgroup/cpu/cpu.cfs_quota_us（v1）来获配额 -
runtime.ReadMemStats不包含 goroutine 栈内存（stack memory），这部分在ms.StackSys单独统计，但默认栈大小 2KB，高并发时可能显著 - 如果用
pprof抓 heap profile，注意debug.SetGCPercent(-1)会禁用 GC，导致Alloc持续上涨——仅用于诊断，切勿长期开启
