Когда JVM падает (segfaults) во время сбора мусора, как я могу узнать, что собиралось?

Я получаю segfaults в своей JVM примерно на той же фазе приложения, но с разными стеками стека в отчете о сбое. Однако это всегда происходит во время GC.

Поскольку авария происходит во всех трех JVM, которые я пробовал (OpenJDK 6, Oracle 1.6.0_25 и 1.7.0) и с двумя GC каждый (Parallel Collector и CMS), и это происходит вокруг одной и той же области приложения, я Если бы я мог найти то, что собирался собирать GC, я мог бы заметить некоторые особенности моего кода, которые приводят к этому сбою.

  • Существуют ли какие-либо методы кодирования, которые, как известно, проблематичны для GC?
  • Какие методы доступны для диагностики этой проблемы?
  • Могу ли я сделать какие-либо обоснованные предположения о том, где в моем приложении эта проблема срабатывает?
  • Какие параметры (GC tuning) можно воспроизвести, чтобы уменьшить проблему?
  • Есть ли способ обнаружить (возможно) проблемные данные в дампе кучи?

Ответы

Ответ 1

Это произойдет, если у вас есть библиотека JNI, которая неправильно обрабатывает память. Проблема не проявляется сразу. Однако, когда GC выполняется, он сканирует всю память, отключает поврежденную ссылку и убивает JVM. т.е. коррупция могла произойти в любое время после последнего полного GC.

Ответ 2

  • Сегрегаторы имеют определенные коды ошибок в начале дампа http://en.wikipedia.org/wiki/Segmentation_fault

  • Вы можете использовать Thread.dumpStackTrace, чтобы узнать, что происходит в этом приложении Если вы точно знаете, где ваше приложение замерзает или замерзает после определенного действия или события, вы можете CTRL + разорвать окна или CTRL + \, чтобы получить дамп потока, и посмотреть, что происходит.

  • Вместо того, чтобы смутно угадывать, вы можете прокомментировать некоторые разделы кода, чтобы узнать, какой цикл или объект или буфер или строка занимает слишком много времени.

  • В зависимости от вашей ситуации вы можете рассмотреть некоторые конкретные инструменты.

Ответ 3

  • Я предлагаю вам получить как дамп потока, так и кучу дампа, вы можете сделать это либо из командной строки, используя инструмент, например Visual VM
  • Я думаю, что куча кучи, являющаяся снимком JVM-памяти, предоставит информацию о живых объектах и ​​их распределениях. Если вы анализируете кучу с помощью Visual VM, она предоставляет подробный отчет обо всех объектах в куче
  • Я бы посоветовал вам собрать коллекцию GC в своем приложении для подробного анализа и анализа с помощью инструмента, такого как tagtraum
  • Если вы можете прикрепить JVM-профайлер, который может предоставить много информации или если у вас есть общее представление о рабочем потоке, который вызывает проблема тогда просто профиль, который в изоляции

Ответ 4

Мы также столкнулись с аналогичной проблемой. Не было никакой картины, которую мы могли бы видеть, и это было довольно случайным, но происходило либо на GC, либо на Full GC. Для нас это оказалось проблемой с модулями ОЗУ. Мы идентифицировали его с помощью MemTest86 + на сервере Ubuntu.