Мы изо всех сил пытались диагностировать причину ошибки OutOfMemoryError, возникшей на одном из наших рабочих серверов. Наши попытки воспроизвести проблему в тестах на выдержку пока не увенчались успехом, и мы рассматриваем возможность включения -XX:+HeapDumpOnOutOfMemoryError на наших производственных серверах, так что если это повторится снова, по крайней мере, у нас будут какие-то данные.
Разумно ли включать этот параметр на производственных серверах?
Взгляните в документация:
B.1.2 -XX: + опция HeapDumpOnOutOfMemoryError
В
-XX:+HeapDumpOnOutOfMemoryErrorПараметр командной строки указывает виртуальной машине HotSpot создать дамп кучи, когда выделение из кучи Java или постоянное создание не может быть выполнено. С этой опцией нет накладных расходов, поэтому это может быть полезно для производственных систем гдеOutOfMemoryErrorзанимает много времени, чтобы всплыть на поверхность.Вы также можете указать эту опцию во время выполнения на вкладке MBeans в утилите jconsole.
Дамп кучи находится в
HPROFдвоичный формат, поэтому его можно анализировать с помощью любых инструментов, которые могут импортировать этот формат. Например, инструмент jhat можно использовать для элементарного анализа дампа.
-XX:+HeapDumpOnOutOfMemoryError flag не вызывает проблем с производительностью или безопасностью во время выполнения. Флаг проверяется только после OutOfMemoryError случилось.
Вы можете указать фактический путь, по которому сохраняется файл, используя соответствующий -XX:HeapDumpPath флаг. (Независимо от того, где сохранен файл, убедитесь, что файловая система и / или процесс Java имеют необходимую конфигурацию разрешений, чтобы иметь возможность писать туда.)