手动调用 runtime.GC() 几乎总是错误的，仅适用于进程退出前终态清理或超大临时对象批处理后且经 pprof 确认的极少数场景。
runtime.GC() 什么时候该手动触发
手动调用 runtime.GC() 几乎总是错的。Go 的垃圾回收器是并发、自适应的，会根据堆增长速率和 CPU 利用率自动调度。强行触发不仅不能“立刻释放内存”，反而会阻塞所有 goroutine（STW 阶段），拖慢响应，还可能干扰 GC 的预测节奏，导致后续更频繁的回收。
只有极少数场景可考虑：进程退出前做一次终态清理（如 CLI 工具），或在长期运行服务中完成一次超大临时对象批处理后（比如解压并解析一个 2GB JSON 文件），且已通过 pprof 确认该次操作产生了大量可立即回收的存活期极短的对象。
- 不要在 HTTP handler 里调用 —— 并发请求下会引发 GC 飙升和延迟毛刺
- 不要用它“解决内存泄漏”——泄漏必须靠
pprof heap定位根因，不是靠多 GC - 调用后不保证内存立即归还给操作系统；是否返还取决于
runtime/debug.SetGCPercent()和底层 mmap 行为
如何安全获取 goroutine 数量和栈信息
runtime.NumGoroutine() 返回的是当前存在的 goroutine 总数，包括正在运行、就绪、阻塞（如 channel wait、syscall、time.Sleep）的所有状态。它开销极小，适合监控告警（比如 >5000 就发钉钉），但不能用于逻辑判断，因为数字随时在变，且无法区分“健康”和“卡死”的 goroutine。
真正需要诊断时，应该用 runtime.Stack() 抓快照：
立即学习“go语言免费学习笔记（深入）”；
buf := make([]byte, 2<<20) // 2MB 缓冲
n := runtime.Stack(buf, true) // true = 打印所有 goroutine
log.Printf("goroutines dump:\n%s", buf[:n])注意：runtime.Stack() 在高并发下可能因缓冲不足而截断，建议预估最大栈总长（单 goroutine 栈通常几 KB，但 panic 堆栈可能很长），并检查返回值 n 是否等于 len(buf)。
- 生产环境避免无条件调用
runtime.Stack(nil, true)（分配未知大小内存，易 OOM） - 不要用
NumGoroutine()实现“等待所有 goroutine 结束”逻辑——该用sync.WaitGroup或context - 调试时可用
go tool trace替代反复抓 Stack，更准、更轻量
修改 GOMAXPROCS 有什么实际影响
runtime.GOMAXPROCS(n) 控制的是“可同时执行用户代码的操作系统线程数”，不是 CPU 核心数，也不是 goroutine 并发上限。它的作用是设置 P（Processor）的数量，每个 P 绑定一个 OS 线程（M），负责调度 G（goroutine）。
默认值是机器的逻辑 CPU 数（runtime.NumCPU()），大多数情况无需改动。改小会导致 P 不足，goroutine 排队等待，尤其在大量 I/O + CPU 混合负载时吞吐下降；改大会增加线程切换和调度器开销，对 GC STW 时间也有间接影响。
- 容器环境（如 k8s）中，若 cgroup 限制了 CPU quota，应显式设为
math.Min(n, runtime.NumCPU())，否则 Go 可能申请远超配额的线程 - 设为 1 不等于“单线程”——goroutine 仍可并发（通过 channel、network、timer 等非阻塞调度），只是无法并行执行 CPU 密集型任务
- 动态调整（如根据负载伸缩）收益极低，且可能引发调度抖动；上线前固定一个合理值即可
为什么 runtime.ReadMemStats 总是比 top 看到的 RSS 小
runtime.ReadMemStats() 返回的是 Go 运行时视角的内存统计：包括堆分配（Alloc）、堆总申请量（TotalAlloc）、堆对象数（NumGC）等，但不包含运行时自身代码、全局变量、cgo 分配、mmap 映射的匿名内存、以及未归还给操作系统的空闲堆页。而 top 的 RSS（Resident Set Size）是内核统计的物理内存占用，覆盖全部。
典型差值来源：runtime 保留的 heap free list、未触发 scavenge 的空闲 span、cgo 调用 C 库分配的内存（如 C.malloc）、以及 plugin 加载的符号表。
- 想看真实内存压力，优先看
MemStats.Sys - MemStats.HeapSys（非堆开销），再结合/proc/PID/smaps分析 anon-rss - 不要用
MemStats.Alloc直接对比监控图表中的“内存使用率”——它只反映活跃堆对象，不是进程总驻留内存 - 如果
MemStats.Sys持续上涨但Alloc稳定，大概率是 cgo 泄漏或 mmap 未释放（如unsafe.Slice+syscall.Mmap忘记Munmap）
事情说清了就结束。
