Go问答技术文章
-
GOMEMLIMIT 是 Go runtime 的软内存上限，设置后 RSS 仍可能上涨。本文用 runtime/metrics 区分当前上限、runtime 账本、存活堆和容器 RSS，排查 cgo、mmap、GC 周期与容器余量。422 收藏 -
runtime/metrics 适合读取 Go 运行时定义的指标，expvar 适合发布应用自己维护的公开变量。本文用采样、名称兼容和版本边界说明两者怎么选。357 收藏 -
Go runtime/metrics 采样太频繁时，先区分 Read、快照处理和导出成本，再通过复用 Sample、筛选指标和异步批量上报降低开销。354 收藏 -
Go runtime/metrics 读不到自定义名称时，先检查 runtime.Version() 和 metrics.All()，确认完整指标名、单位与版本支持集合，再把业务自定义指标交给独立采集层。404 收藏 -
Go pprof 里的 CPU、mutex 和 block profile 关注的不是同一件事。本文用一个采集窗口说明三者的开关、命令、栈位置和适用边界，帮助你判断到底是 CPU 忙还是 goroutine 在等锁、等通道。250 收藏 -
Go 的 block profile 记录的是同步原语上的阻塞时间，不只包含 Mutex。本文教你从等待栈区分 Mutex、RWMutex、WaitGroup 和 channel，并用 mutex profile 找到真正持锁的代码。378 收藏 -
Go mutex profile 没有热点时，先用 runtime.SetMutexProfileFraction(-1) 读取开关，再确认采样比例、竞争窗口和 pprof 进程；本文还区分 mutex profile 与 block profile 的排查边界。151 收藏 -
Go 基准测试开启内存分配报告后，结果变化不一定代表业务代码变慢。本文从计时边界、b.ReportAllocs、B/op、allocs/op 和重复运行入手，区分真实分配与测量噪声。384 收藏 -
Go 的 testing.AllocsPerRun 数值变化大时，先排查初始化、输入状态复用、并行测试和后台分配，再决定增加 runs 还是改用 benchmark。本文按测量边界、稳定输入和指标分工给出一套可执行的检查顺序。223 收藏 -
Go benchmark 结果忽高忽低，常见原因不是被测函数本身，而是初始化落在计时区间、分配统计未分开或运行噪声未被重复确认。本文用 testing.B 说明 StopTimer、ResetTimer、ReportAllocs 和 -count 的配合方式。368 收藏 -
Go covermode 的选择取决于是否并发以及是否需要可靠执行次数：串行包/函数覆盖率用 set，并发计数或 -race 场景用 atomic。139 收藏 -
Go 覆盖率统计到函数并不代表每个分支都执行。本文用表驱动测试区分包覆盖率、函数覆盖率和代码块报告，定位没有命中的分支。195 收藏 -
go test -coverprofile 默认只分析正在测试的包。要把模块内子包纳入同一份报告，需要同时指定测试包列表和 -coverpkg=./...，再用 go tool cover 查看函数或 HTML 报告。178 收藏 -
Go fuzz 最小化输入仍无法复现时，先核对失败日志中的 FuzzXxx/哈希、testdata corpus 路径和参数类型，再排查时间、随机数、全局状态与外部依赖，最后把稳定 corpus 固化为回归测试。236 收藏 -
Go fuzz 运行很慢时，先用 -run 和 -fuzz 只选一个目标，再用 -fuzztime 限制探索预算；语料保留能覆盖不同入口的种子，失败输入最小化另用 -fuzzminimizetime 控制，并按机器压力调整 -parallel。256 收藏