Как мне диагностировать и предотвращать сбои JVM?

Question

Что я должен делать (как программист на Java, который ничего не знает о внутренностях JVM), когда сталкиваюсь с аварийным завершением JVM?

В частности, как бы вы создали воспроизводимый контрольный пример? Что я должен искать в базе данных ошибок Sun (или IBM)? Какую информацию я могу получить из созданных файлов журнала (например, hs_err_pidXYZ.log)?

Answer 1

Если сбой происходит только на одной конкретной машине, запустите memtest . Я видел повторяющиеся сбои JVM только два раза, и в обоих случаях виновником оказалась аппаратная проблема, а именно неисправная RAM

Answer 2

1. По моему опыту, они почти всегда вызваны нативным кодом, использующим JNI, мой или чей-то другой. Если вы можете, попробуйте перезапустить без собственного кода, чтобы посмотреть, сможете ли вы его воспроизвести.

2. Иногда стоит попробовать с , когда JIT-компилятор выключен , если ваша ошибка легко воспроизводима.

3. Как уже отмечали другие, неисправное оборудование также может быть причиной этого, я видел это как для памяти, так и для видеокарт (когда сбой был в свинг-коде). Попробуйте запустить аппаратную диагностику, наиболее подходящую для вашей системы.

4. Поскольку сбои JVM редки, я бы сообщил об этом Sun. Это можно сделать в их базе данных ошибок . Используйте категорию Java SE, подкатегория jvm_exact или jit.

5. В Unix / Linux вы можете получить дамп ядра. Под окнами JVM обычно сообщает вам, где хранится журнал того, что произошло. Эти файлы часто дают некоторую подсказку, но могут отличаться от JVM до JVM. Sun предоставляет полную информацию об этих файлах на их сайте . или IBM файлы можно анализировать с помощью Java Core Analyzer и Java heapdump Analyzer от IBM alphaworks.

6. К сожалению, отладчики Java в моем опыте, как правило, причиняют больше вреда, чем помощи. Однако подключение отладчика для конкретной ОС (например, Visual Studio) может помочь, если вы знакомы с чтением трассировок стека C.

Попытка получить воспроизводимый контрольный пример - трудная задача. Если у вас есть большой объем кода, который всегда (или почти всегда) дает сбой, это проще, просто медленно удаляйте части, пока он продолжает падать, получая как можно меньший результат. Если у вас нет воспроизводимого тестового кода, то это очень сложно. Я бы посоветовал получить подсказки из моего пронумерованного выбора выше.

Answer 3

Sun документирует подробности журнала аварий здесь . Есть также хороший учебник, написанный здесь здесь , если вы хотите разобраться в грязных деталях (кажется, что вы этого не делаете)

Однако, как упоминал комментатор, сбой JVM является довольно редким и серьезным событием, и в этой ситуации стоит обратиться в службу поддержки Sun или IBM.

Answer 4

На веб-сайте Oracle есть отличная страница для устранения проблем такого типа.

Проверьте соответствующие разделы для:

• зависшие процессы (например, jstack утилита)
• Диагностика после смерти

Answer 5

Когда происходит сбой JVM iBM, он может записать в файл /tmp/dump_locations, где перечислены все файлы heapdump или javacore, которые он записал.

Эти файлы можно анализировать с помощью Java Core Analyzer и Java heapdump Analyzer от IBM alphaworks.