Java Heapdump文件要分析的最佳格式是什么？是hprof吗？

我被指派在生产环境中查找完整GC问题（垃圾收集器）的根本原因。它是随机发生的，我认为最有可能的情况是当前应用程序中存在内存泄漏。我希望从我们的生产环境（linux）中获取内存转储，并使用Eclipse内存分析器等GUI工具进行分析

要分析的堆转储文件的最佳文件格式是什么？是hprof格式吗？我将使用jmap命令获取堆转储。获取内存转储时是否需要指定“format=b”选项

下面是一个示例命令，我将指示我们的支持团队运行。（5980是一个示例pid）

如果你相信任何更好的方法，请让我知道

jmap -dump:format=b,file=hpdump.hprof 5980

---

谢谢

命令似乎很好。是的，很少有其他工具可用于分析堆转储。

---

请参阅

我无法将堆转储文件作为生产环境中的空间限制。分析直方图文件也让我一事无成。相反，我能够找到GC日志分析器工具， 这有助于分析在一年中某些确定的日子导致完全GC问题的GC日志

---

绘制的GC日志图揭示了整个故事。在每个场景中都可以观察到内存消耗的快速增长，从某个事件开始，只需不到10分钟的时间就可以获得最大内存。我计算了初始上升点的时间戳，并和服务器日志中相应的时间戳进行了比较。这有力地证明了在上升开始时服务器日志中经常出现的某些进程

考虑让他们定期运行jstat并绘制结果。看看它是否真的是不可预测的。此外，使用-XX:+HeapDumpOnOutOfMemoryError运行时，JVM将在关键时刻创建转储。第三，在开发服务器上运行这些工具以了解结果。更好的方法是运行jvisualvm。分析这样的内存转储是否需要额外的硬件支持？有时Eclipse内存分析器崩溃。内存转储越大，分析起来就越笨拙。因此，如果您以前建议简单地增加内存以查看是否有帮助，现在请他们向您发送OOM错误发生时产生的巨大转储，那么分析仪在内存较少的机器上进行分析时可能会遇到困难。分析此类内存转储是否需要额外的硬件支持？有时Eclipse内存分析器崩溃。分析内存泄漏问题总是很棘手的，我使用了一些商业工具，提供了许多选项来识别这些问题。遵循最佳实践来防止内存泄漏总是好的。