1.在存在heap.dump文件的情况下重新启动服务器是否会完全清除堆内存区域？
当JVM启动/重新启动时，堆将始终为空。
JVM启动时不会读取堆转储文件。它的存在与否无关紧要。
1.新的错误是否是由于前一个heap.dump文件未清除造成的？
不。见上文。
消息说JVM再次OOME，但是JVM不愿意（或者不能）覆盖现有的转储文件，所以你没有得到一个新的堆转储。
1.有哪些可能性会这么快得到上述错误？
一般来说，bug（可能在您的应用程序中）或堆太小。或两者兼而有之。原因包括以下几点：

• 一个有缺陷的（或设计不良的）应用程序可能会创建内存中的数据结构，这些数据结构过大/使用过多的内存。
• 一个有错误的应用程序可能会有内存泄漏，这意味着GC无法回收不再需要的对象。如果你的应用程序在崩溃前运行了几周，内存泄漏应该是主要的嫌疑人。
• 如果您将堆大小设置得太小，不适合应用程序正在解决的 * 问题 *，那么您将得到OOME。
• 如果在垃圾收集上花费了太多的时间，你会得到“超过GC开销限制”的OOME的味道。这通常是堆“接近”满的标志......并且GC在最后一次尝试中重复运行以保持应用程序继续运行。（“垃圾收集死亡螺旋”）。

这个问题的“根本原因”很可能是以前的问题之一。

• 边缘情况：
• 如果应用程序过度或不适当地使用终结器、清理器、Reference对象等，GC的引用处理线程可能无法跟上，导致OOME。
• 对于某些GC，分配一个非常大的数组可能会导致OOME，因为在GC运行后没有足够的 * 连续 * 可用空间。
• 可能是堆大小太大，主机无法处理;即RAM和/或交换空间不足。

如果不详细检查应用程序并查看堆转储和OOME中的堆栈跟踪，就不可能更具体。
这个Q&A可能有帮助，但我不认为它回答了你的问题：

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