Что я могу сделать, если Java VM несколько раз падает? - PullRequest
4 голосов
/ 22 октября 2008

Какова лучшая практика для устранения сбоя виртуальной машины Java, если выполняются следующие условия:

  • Нет собственного или стороннего собственного кода. 100% чистая ява
  • Эта же программа работает на многих других системах без проблем.

PS: при сбое виртуальной машины я имею в виду, что виртуальная машина пишет файл дампа, например, hs_err_pid1234.log, и завершается.

Ответы [ 5 ]

4 голосов
/ 22 октября 2008

Прочитайте файл hs_err_pid1234.log (или как там есть имя файла журнала ошибок). Там обычно есть подсказки. Следующий шаг зависит от того, что вы обнаружите в журнале.

Да, это может быть ошибка в конкретной версии используемой вами реализации JVM, но я также видел проблемы, вызванные фрагментацией памяти в операционной системе. Например, Windows склонна прикреплять dll в неподходящих местах и ​​не может выделить непрерывный блок памяти, когда JVM запрашивает его в результате. Другие проблемы с оперативной памятью также могут проявляться в аварийных дампах этого типа.

3 голосов
/ 22 октября 2008

Обновите или замените JVM. Если у вас установлена ​​самая новая версия, попробуйте более старую или, если у вас нет последней версии, попробуйте обновить ее. Может быть, это известная проблема в вашей конкретной версии?

2 голосов
/ 22 октября 2008

Предполагается, что версия JVM на разных машинах одинакова:

Выясните, что отличает машину, на которой происходит сбой JVM. Та же OS и OS версия? У нас есть проблемы со сбоями JVM, например, в определенной версии Red Hat. И мы также обнаружили, что некоторые старые версии Red Hat не справляются с дополнительной памятью должным образом, что приводит к исчерпанию пространства подкачки. (Нашим решением было обновить RedHat).

Кроме того, программа делает точно то же самое на разных машинах? Это доступ к общей файловой системе? Смонтирована ли файловая система аналогичным образом на ваших компьютерах (SMB / NFS и т. Д.)? Что-то должно быть по-другому.

Файл журнала должен дать вам представление о том, где произошел сбой (например, malloc).

0 голосов
/ 23 октября 2008

32-битный? 64bit? Количество оперативной памяти на клиентском компьютере? процессор? Операционные системы? Посмотрите, есть ли связь между системами. Соединение может привести к подсказке. Если все остальное терпит неудачу, рассмотрите использование других главных / второстепенных версий JVM. Кроме того, если проблема только началась, можете ли вы добраться до времени (через контроль версий), когда программа не вылетала? Посмотрите журнал hs_err, вы можете получить представление о том, что вызвало сбой. Это может быть версия какой-то другой клиентской библиотеки, которую использует JVM. Наконец, запустите программу в debug / profile, и, возможно, перед сбоем вы увидите некоторые симптомы (при условии, что вы можете продублировать их)

0 голосов
/ 22 октября 2008

Посмотрите на следы стека в файле дампа, так как он должен рассказать вам, что происходило, когда произошел сбой.

Помимо копки в файл дампа hs_err, я бы также отправил его Sun или тому, кто сделал вашу JVM (я думаю, что есть инструкции, как это сделать вверху файла?). Это не может повредить.

...