与OutOfMemoryError相关的JVM参数

JVM提供了有用的参数来处理OutOfMemoryError 。 在本文中，我们将重点介绍那些JVM参数。 对OutOfMemoryError进行故障排除时，它可能对您很方便。 这些JVM参数是：

1. -XX：+ HeapDumpOnOutOfMemoryError -XX：HeapDumpPath
2. -XX：OnOutOfMemoryError
3. -XX：+ ExitOnOutOfMemoryError
4. -XX：+ CrashOnOutOfMemoryError

让我们在本文中详细讨论这些JVM参数。

XX：+ HeapDumpOnOutOfMemoryError -XX：HeapDumpPath

堆转储基本上是内存的快照。 它包含有关内存中存在的对象，这些对象中存在的实际数据，这些对象的引用的详细信息。 堆转储是解决内存问题的重要工具。

为了诊断OutOfMemoryError或任何与内存相关的问题，必须在应用程序开始遇到OutOfMemoryError的那一刻或一瞬间捕获堆转储。 很难在适当的时候手动捕获堆转储，因为我们不知道何时会抛出OutOfMemoryError。 但是，当您在命令行中启动应用程序时，可以通过传递以下JVM参数来自动捕获堆转储：

-XX:+HeapDumpOnOutOfMemoryError and -XX:HeapDumpPath={HEAP-DUMP-FILE-PATH}

例：

-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/crashes/my-heap-dump.hprof

在“ -XX：HeapDumpPath”中，您需要指定堆转储所在的文件路径。

传递这两个JVM参数时，将在抛出OutOfMemoryError时自动捕获堆转储并将其写入指定的文件路径。

一旦捕获了堆转储，就可以使用HeapHero和Eclipse MAT之类的工具来分析堆转储。

-XX：OnOutOfMemoryError

您可以将JVM配置为在抛出OutOfMemoryError时调用任何脚本。 大多数时候，OutOfMemoryError不会使应用程序崩溃。 但是，一旦发生OutOfMemoryError，最好重新启动应用程序。 因为OutOfMemoryError可能会使应用程序处于不稳定状态。 来自不稳定的应用程序实例的请求可能会导致错误的结果。

例：

-XX:OnOutOfMemoryError=/scripts/restart-myapp.sh

传递此参数时，每当抛出OutOfMemoryError时，JVM就会调用“ /scripts/restart-myapp.sh”脚本。 在此脚本中，您可以编写代码以优雅地重新启动应用程序。

(3).XX：+ CrashOnOutOfMemoryError

当您传递此参数时，JVM将在抛出OutOfMemoryError时立即退出。 除了退出，JVM还会生成文本和二进制崩溃文件(如果启用了核心文件)。 但就我个人而言，我不希望配置此参数，因为我们应始终以实现正常退出为目标。 突然退出可能/将危害正在进行的交易。

我运行了一个使用此'-XX：+ CrashOnOutOfMemoryError'参数生成OutOfMemoryError的应用程序。 当抛出OutOfMemoryError时，我可以看到JVM立即退出。 以下是标准输出流中的消息：

 Aborting due to java.lang.OutOfMemoryError: GC overhead limit exceeded
 #
 # A fatal error has been detected by the Java Runtime Environment:
 #
 # Internal Error (debug.cpp: 308 ), pid= 26064 , tid= 0x0000000000004f4c
 # fatal error: OutOfMemory encountered: GC overhead limit exceeded
 #
 .0_181-b13) (build # JRE version: Java(TM) SE Runtime Environment ( 8 .0_181-b13) (build 1.8 .0_181-b13)
 -Bit Server VM ( # Java VM: Java HotSpot(TM) 64 -Bit Server VM ( 25.181 -b13 mixed mode windows-amd64 compressed oops)
 # Failed to write core dump. Minidumps are not enabled by default on client versions of Windows # Failed to write core dump. Minidumps are not enabled by
 #
 # An error report file with more information is saved as:
 # C:workspacetier1app-svntrunkbuggyapphs_err_pid26064.log
 #
 # If you would like to submit a bug report, please visit:
 //bugreport.java.com/bugreport/crash.jsp #  http: //bugreport.java.com/bugreport/crash.jsp
 #

从该消息中，您可以看到在“ C：workspacetier1app-svntrunkbuggyapphs_err_pid26064.log”中生成了hs_err_pid文件。 hs_err_pid文件包含有关崩溃的信息。 您可以使用诸如fastThread之类的工具来分析hs_err_pid文件。 但是hs_err_pid中存在的大多数时间信息都是非常基本的。 不足以对OutOfMemoryError进行故障排除。

-XX：+ ExitOnOutOfMemoryError

传递此参数时，抛出OutOfMemoryError时，JVM将立即退出。 如果您想终止应用程序，则可以传递此参数。 但就我个人而言，我不希望配置此参数，因为我们应始终以实现正常退出为目标。 突然退出可能/将危害正在进行的交易。

我使用此'XX：+ ExitOnOutOfMemoryError'JVM参数运行了相同的内存泄漏程序。 与“ -XX：+ CrashOnOutOfMemoryError”不同，此JVM参数不会生成任何文本/二进制文件。 JVM刚刚退出。

翻译自: https://www.javacodegeeks.com/2019/10/outofmemoryerror-related-jvm-arguments.html