在生产环境中是否应该使用HeapDumpBeforeFullGC？

Question

3

完全垃圾回收（full gc）发生后，我们可能想知道它是如何发生的。如果没有堆转储，我认为很难做到，但在生产环境中，我们通常无法及时获取。因此，当我的应用程序在线运行时，我想使用HeapDumpBeforeFullGC。

我的问题是，在生产环境中是否应该使用HeapDumpBeforeFullGC？它会带来一些不良影响吗（如果我们不考虑磁盘使用）？或者我们是否有其他有效的方法可以找出生产环境中导致完全垃圾回收的原因？

谢谢！

- gatesking

你是否遇到过频繁发生Full GC并且难以诊断的问题？ - the8472

是的，这些问题很难在测试环境中重现。所以我希望有一种诊断它们的方法。 - gatesking

好的，它不仅占用磁盘空间，还需要时间来制作。并记住那句老话，“如果它没有坏，就不要试图修复它”。只有在您认为确实存在问题时才使用该选项。 - Holger

@Holger 这意味着当发生 full gc 时，我们只能在测试环境中尝试重现它？你有什么建议来处理这个问题吗？我想要一种更有效的方法来找出 full gc 发生的原因。谢谢！ - gatesking

不，当你知道有一个问题只能在生产环境中重现时，我会说，在生产环境中使用该选项是无法避免的，直到你收集到足够的信息。它会带来一些“不良影响”，而你清楚地知道这些影响，因此，你能够决定是否值得为了一段时间接受这些不良影响来解决问题。 - Holger

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- the8472 · Accepted Answer

如果您认为在生产环境中进行全局垃圾回收是一个问题，那么添加堆转储可能会有所帮助。但这会使全局垃圾回收的暂停时间更长。

作为替代，您可以开启详细的GC日志记录，这通常是识别一般原因（堆大小不足、泄漏、分配高峰、错误配置、交换等）的良好起点。您还可以使用不太侵入式的分析工具（例如async-profiler或jmc）来发现过度分配的情况。