go tool pprof list分析堆内存：为何数值指向仅含}的行？

问题场景 #

我使用go tool pprof的list命令分析堆内存profile时，发现内存分配数值指向仅包含}的无代码行，具体pprof输出如下：

(pprof) list getItems
Total: 259.09MB
ROUTINE ======================== ddb.(*ItemDL).getEvents in /bld/src/my-repo/ddb/item_process_dl.go

0   322.15MB (flat, cum) 124.34% of Total
     .          .    201:       ExpressionAttributeValues: expr.Values(),
     .          .    202:       //Limit:                     aws.Int64(1000),
     .          .    203:   }
     .          .    204:   if nil != lastEvaluatedKey {
     .          .    205:       params.SetExclusiveStartKey(lastEvaluatedKey)
     .   163.08MB    206:   }

// some more source code

.           .    266:          LaunchTS: qItem.LaunchTS + svcparam.TimeToBumpUp,
     .    21.01MB    267:       }

原因分析 #

• 编译器优化导致行号偏移：Go编译器编译时会做栈帧调整、代码块合并等优化，使得原本属于代码块内的内存分配指令，其调试信息被关联到了代码块结束的}行，机器码与源码行的映射关系因优化发生了偏移。
• 逃逸分配的位置调整：当代码块内的变量触发逃逸分析（需要在堆上分配内存），编译器可能会把内存分配指令放在代码块末尾，对应到源码就是}所在行。比如代码块内创建的切片、结构体实例如果发生逃逸，分配操作的位置会被调整。
• 采样精度限制：pprof是基于采样的分析工具，采样点可能刚好落在代码块结束的机器码位置，而非实际分配内存的源码行。尤其是当分配操作的机器码与}行的机器码相邻时，采样结果就会指向}。

结果解读 #

• 分配数值的真实含义：标注在}行的内存数值，是对应代码块内所有内存分配的总和，并非}本身有分配操作。比如第206行的163.08MB，实际是第204-205行代码块（或其内部调用）产生的堆内存分配总量；第267行的21.01MB对应第266行所在结构体初始化或相关操作的分配总和。
• 累积值说明：输出顶部的322.15MB是该函数的累积分配量，包含函数内所有代码块及子函数调用产生的内存分配总和。
• 定位真实分配点：需要结合上下文代码排查，比如第205行的params.SetExclusiveStartKey可能内部有内存分配，或者expr.Values()返回的对象发生逃逸；第266行的结构体初始化可能产生了需要堆分配的对象。

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