Go语言全局变量内存使用剖析与pprof显示异常问题咨询

问题1：是否可以对全局变量进行剖析，查看每个全局变量的内存占用情况？ #

当然可以啦！Go的工具链给咱们提供了好几种方式来追踪全局变量的内存占用情况：

• 用pprof堆剖析搞定核心数据：像你代码里的切片，它的底层数组是在堆上分配的，这部分内存会被pprof的heap profile完整捕获。你可以用go tool pprof heap命令加载生成的heap文件，然后用这些命令查看细节：
  • top：快速查看内存占用最高的代码块，能直接看到分配全局变量的那两行make操作的内存开销。
  • list main：定位到main函数的代码，每一行的内存分配情况都会标注出来，一目了然。
  • traces：追踪内存分配的完整调用链，能清晰看到全局变量的内存是在哪一步分配的。
• runtime包的细节补充：除了你用的runtime.ReadMemStats，还可以结合runtime/debug的PrintStack()做更细致的排查，但pprof无疑是生产环境最常用的工具。
• 小提醒：全局变量本身（比如切片的头信息，只有指针、长度、容量三个字段）是存在静态存储区的，这部分内存极小，pprof一般不会统计它——pprof主要关注的是堆上的大块内存，也就是切片指向的底层数组。

问题2：为什么pprof仅显示10MB的内存占用，globalByteArray2的内存占用未被统计？ #

这个问题大概率是你查看pprof数据的方式出了小问题，而非代码本身的问题。结合你的代码和输出结果，我梳理了几个可能的原因：

1. pprof默认视图的误解：
   默认情况下go tool pprof展示的是inuse_space（当前正在使用的堆内存），但如果你不小心切换到了alloc_space（累计分配的内存）或者其他统计项，就可能看到不符合预期的结果。你可以在pprof的交互模式下输入inuse_space切换到正确视图，再用top查看。

2. 采样率的视觉偏差：
   Go的pprof堆剖析是采样式的（默认每分配512KB采样一次），大内存分配几乎不会被漏掉，但如果只看某个细分统计维度，可能会有视觉上的错觉。要是想彻底排查，可以设置环境变量GODEBUG=allocfreetrace=1获取完整的内存分配追踪，但这会影响性能，只适合本地调试。

3. GC触发的小意外：
   虽然你的全局变量不会被GC回收，但在生成heap profile之前，有可能因为内存分配达到阈值触发了GC？不过从你的memoryUsage()输出看，30MB的Alloc说明GC没动这两个切片的内存。保险起见，你可以在写heap profile前手动触发GC：runtime.GC()，再生成profile试试。

4. pprof命令的使用姿势不对：
   确保用正确的命令查看，比如直接运行go tool pprof -inuse_space heap指定查看当前使用的内存，避免默认视图被修改。另外，用list main命令查看main函数的代码行，肯定能看到两次make操作对应的10MB和20MB内存分配。

还有个小细节：你的代码里没处理os.Create的错误，万一文件创建失败，profile会不完整，但从你能查看profile来看，这个可能性很低。

最后再确认下：你的两个全局变量的底层数组会一直存在到程序结束，所以pprof的heap profile肯定能统计到这30MB内存，只要用对查看方式就行。

内容的提问来源于stack exchange，提问作者Hirbod Behnam