存在heap.dump文件的服务器重启是否完全清除堆内存区域？

Question

我们的 Java 应用程序在 RHEL 8.5 操作系统平台上运行良好。在我们的应用程序中，我们提供了足够的堆空间，即“2048m”。尽管如此，我们在 2023 年 1 月遇到了一个 heap.dump 文件。我们分析了 heap.dump 文件，发现这是一个 NACACK 错误。

之后，在不删除 heap.dump 文件的情况下，我们只是重新启动了服务器，我们的应用程序开始正常工作。几周后，我们又遇到了另一个问题，

java.lang.OutOfMemoryError: GC overhead limit exceeded
Dumping heap to /XYZ/jboss/server/log/heap.dump ...
Unable to create /XYZ/jboss/server/log/heap.dump: File exists.

请找到以下查询，

1. 在存在heap.dump文件的情况下重启服务器是否会完全清除堆内存区域？
2. 新的错误是不是因为之前的heap.dump文件没有清除？
3. 有什么可能这么快得到上面的错误？

谢谢。

Answer 1

1. 在存在heap.dump文件的情况下重启服务器是否会完全清除堆内存区域？

没有。 JVM 启动时不会读取堆转储文件。

2. 新的错误是不是因为之前的heap.dump文件没有清除？

没有。见上文。

警告消息的全部意思是 JVM OOME'd again and it's willing (or able) to overwrite the existing dump file.

3. 有什么可能这么快得到上面的错误？

总的来说，错误（可能在您的应用程序中）或堆太小。或两者。原因包括：

• 有缺陷（或设计不佳）的应用程序可以创建过大/使用大量内存的内存数据结构。

• 有缺陷的应用程序可能存在内存泄漏，这意味着 GC 无法回收不再需要的对象。如果您的应用程序在崩溃前运行了几周，内存泄漏应该是主要嫌疑人。

• 如果您为应用程序正在解决的问题设置的堆大小太小，您将得到 OOMEs。

• 如果垃圾收集花费了太多time，您将获得 OOME 的“超出 GC 开销限制”的味道。这通常是堆 nearly 满的标志......并且 GC 在最后一次尝试中重复运行以保持应用程序继续运行。 （“垃圾收集死亡螺旋”。）

  这根本原因很可能是以前的原因之一。

• 边缘情况：

  • 如果应用程序过度或不恰当地使用终结器、清理器、

    Reference

    对象等，GC 的引用处理线程可能无法跟上导致 OOME。

  • 对于某些 GC，分配一个非常大的数组可能会 OOME，因为在 GC 运行后没有足够的连续可用空间。

  • 可能是堆大小太大主机无法处理；即 RAM 和/或交换空间不足。

如果不详细检查您的应用程序并查看 OOME 的堆转储和堆栈跟踪，就不可能更具体。

这个问答可能有帮助，但我不认为它回答了你的问题：

• Error java.lang.OutOfMemoryError: GC overhead limit exceeded