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

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: HeapDumpPath’ вам нужно указать путь к файлу, где должен храниться дамп кучи.

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

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

(2). -XX: OnOutOfMemoryError

Вы можете настроить JVM для вызова любого скрипта, когда выбрасывается OutOfMemoryError. В большинстве случаев OutOfMemoryError не приводит к сбою приложения. Тем не менее, лучше перезапустить приложение, как только OutOfMemoryError произойдет. Потому что OutOfMemoryError потенциально может оставить приложение в нестабильном состоянии. Запросы, обслуживаемые нестабильным экземпляром приложения, могут привести к ошибочному результату.

Пример:

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

(3) .XX + CrashOnOutOfMemoryError

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

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

Из сообщения вы можете увидеть файл hs_err_pid, который будет сгенерирован в «C: workspacetier1app-svntrunkbuggyapphs_err_pid26064.log». Файл hs_err_pid содержит информацию о сбое. Вы можете использовать такие инструменты, как fastThread, для анализа файла hs_err_pid. Но в большинстве случаев информация, представленная в hs_err_pid, очень проста. Этого недостаточно для устранения неполадок OutOfMemoryError.

(4). -XX: + ExitOnOutOfMemoryError

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

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