知识卡片
诊断要回到机制
内容
性能工具只能指出现象，解释仍要回到调度、分配和 GC 机制。看到频繁 GC，要追问分配来源和对象生命周期；看到协程堆积，要追问等待协议。
参考来源
- 位置：《Go语言底层原理剖析》第21章《调试利器：特征分析与事件追踪》20.9节《实战：垃圾回收产生的性能问题》（第21章工具的实际应用案例）
- 结论依据：原文用一个真实案例说明诊断过程——先用 trace 发现"GC在30s内执行了43次"这一现象，再"查看每一次GC发生时的堆栈信息……在堆栈信息中可以查看到saveFaceToRedis函数出现了多次，其调用了makeslice函数分配内存"，最终定位到"多次分配过大的内存导致了垃圾回收频繁发生"并用 sync.Pool 复用内存解决，因此可以推出"性能工具指出现象（频繁GC），但必须回到分配来源、对象生命周期等机制才能给出解法"的结论。
- 原始内容：为了探究发生如此频繁的垃圾回收的原因，可以查看每一次GC发生时的堆栈信息，这仍然是依靠强大的trace工具实现的。从概率的角度来看，如果我们在堆栈信息中查看到在相同的函数处多次触发了GC，那么该函数大概率是有问题的……在本例中，通过查看代码发现，多次分配过大的内存导致了垃圾回收频繁发生。通过修改代码，借助标准库中sync.pool复用产生的内存，可以轻松解决该问题。