Аргументы JVM, связанные с OutOfMemoryError

JVM предоставила полезные аргументы для работы с OutOfMemoryError. В этой статье мы хотели бы выделить эти аргументы JVM. Это может пригодиться вам при устранении неполадок OutOfMemoryError. Эти аргументы JVM:

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

Давайте подробно обсудим эти аргументы JVM в этой статье.

(1). -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath
Дамп кучи — это, по сути, снимок памяти. Он содержит подробную информацию об объектах, которые присутствуют в памяти, фактические данные, которые присутствуют в этих объектах, ссылки, происходящие из этих объектов. Дамп кучи является жизненно важным артефактом для устранения проблем с памятью.

Чтобы диагностировать OutOfMemoryError или любую проблему, связанную с памятью, нужно было бы захватить дамп кучи прямо в данный момент или за несколько мгновений до того, как приложение начнет испытывать OutOfMemoryError. Трудно вручную захватить дамп кучи в нужный момент, потому что мы не будем знать, когда будет выброшен OutOfMemoryError. Однако сбор дампов кучи можно автоматизировать, передав следующие аргументы JVM при запуске приложения в командной строке:

-XX:+HeapDumpOnOutOfMemoryError и -XX:HeapDumpPath={HEAP-DUMP-FILE-PATH}
Пример:

-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/сбои/my-heap-dump.hprof
В ‘-XX:HeapDumpPath’ вам нужно указать путь к файлу, в котором должен храниться дамп кучи.

Когда вы передаете эти два аргумента JVM, дампы кучи будут автоматически захвачены и записаны в указанный путь к файлу при возникновении ошибки OutOfMemoryError.

После захвата дампов кучи вы можете использовать такие инструменты, как HeapHero, Затмение MAT для анализа дампов кучи.

(2). -XX:OnOutOfMemoryError
Вы можете настроить JVM для вызова любого скрипта при возникновении ошибки OutOfMemoryError. В большинстве случаев OutOfMemoryError не приводит к сбою приложения. Однако лучше перезапустить приложение, как только произойдет OutOfMemoryError. Потому что OutOfMemoryError потенциально может оставить приложение в нестабильном состоянии. Запросы, обслуживаемые из нестабильного экземпляра приложения, могут привести к ошибочному результату.

Пример:

-XX:OnOutOfMemoryError=/scripts/restart-myapp.sh
Когда вы передаете этот аргумент, JVM будет вызывать сценарий «/scripts/restart-myapp.sh» всякий раз, когда выдается OutOfMemoryError. В этом скрипте вы можете написать код для корректного перезапуска приложения.

(3). -XX:+CrashOnOutOfMemoryError
Когда вы передаете этот аргумент, JVM завершит работу сразу после того, как будет выброшен OutOfMemoryError. Помимо выхода, JVM создает текстовые и двоичные файлы сбоев (если включены файлы ядра). Но лично я бы не предпочел настраивать этот аргумент, потому что мы всегда должны стремиться к изящному выходу. Резкий выход может поставить под угрозу транзакции, которые находятся в движении.

Я запустил приложение, которое генерирует OutOfMemoryError с этим аргументом ‘-XX:+CrashOnOutOfMemoryError’. Я мог видеть, как JVM сразу же завершает работу, когда выдается OutOfMemoryError. Ниже было сообщение в стандартном потоке вывода:

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
#
# JRE version: Java(TM) SE Runtime Environment (8.0_181-b13) (build 1.8.0_181-b13)
# 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
#
# An error report file with more information is saved as:
# C:\workspace\tier1app-svn\trunk\buggyapp\hs_err_pid26064.log
#
# If you would like to submit a bug report, please visit:
#   
#

Из сообщения видно, что файл hs_err_pid создается в «C:\workspace\tier1app-svn\trunk\buggyapp\hs_err_pid26064.log». hs_err_pid содержит информацию о сбое. Вы можете использовать такие инструменты, как быстрая нить для анализа файла hs_err_pid. Но большую часть времени информация, представленная в hs_err_pid, очень проста. Этого недостаточно для устранения неполадок OutOfMemoryError.

(4). -XX:+ExitOnOutOfMemoryError
Когда вы передаете этот аргумент, JVM завершит работу сразу после того, как будет выброшен OutOfMemoryError. Вы можете передать этот аргумент, если хотите завершить приложение. Но лично я бы не предпочел настраивать этот аргумент, потому что мы всегда должны стремиться к изящному выходу. Резкий выход может поставить под угрозу транзакции, которые находятся в движении.

Я запустил ту же программу утечки памяти с этим аргументом JVM «-XX:+ExitOnOutOfMemoryError». В отличие от ‘-XX:+CrashOnOutOfMemoryError’, этот аргумент JVM не создает никакого текстового/двоичного файла. JVM только что вышел.