Получить обнаружение взаимоблокировки из запущенной программы или дампа в Java

2

У меня есть часть запущенного java-программного обеспечения, которое застряло. Я хотел бы получить представление внутри, но понятия не имею, как это сделать.

Есть ли какой-нибудь инструмент, который я могу дать PID, и он скажет мне, где находится каждый поток, и, возможно, несколько значений переменных? Я запускаю linux.

Я более или менее знаю, что вызывает проблему, но есть еще несколько возможных случаев, поэтому точное определение было бы неплохо.

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

Любые идеи?

  • 0
    Можете ли вы включить удаленную отладку в следующий раз? то есть stackoverflow.com/questions/138511/…
Теги:
jvm
deadlock
dump
memory-dump

3 ответа

9
Лучший ответ

На самом деле вы можете попытаться использовать visualvm + его мониторинг плагин. Вы также сможете сделать дамп потока, просмотреть трассировки стека стека ant их состояния. Вы также можете использовать jconsole для обнаружения взаимоблокировок. Оба инструмента являются частью JDK. Изображение 174551

Здесь есть дополнительная информация об использовании visualvm для анализа потоков.

4

Вы можете взять свалку потока. Вы можете использовать kill -3 PID, где PID - это идентификатор вашего процесса. Это приведет к тому, что дамп потока будет выводиться на стандартный вывод вашей программы.

Это покажет вам, что делает каждый поток, но не даст вам никакой информации о переменных. Несмотря на это, потоки резьбы действительно полезны. Я бы начал там. Если вы все еще не можете исправить эту проблему, вы можете использовать что-то вроде jmap (инструмент JVM, бесплатно, но сложнее в использовании) или YourKit (платный продукт, но очень хороший), чтобы сделать снимок памяти и изучить переменные.

Некоторая информация о jmap: Профилирование памяти Java с помощью jmap и jhat

  • 0
    kill -3 PID, похоже, ничего не делает. JVM все еще жив после этого. Как это может быть?
  • 2
    kill -3 на самом деле не убивает JVM, он просто посылает сигнал для запуска дампа потока. Дамп потока будет идти к стандартному выводу JVM (не вывод std команды kill). Просто убедитесь, что вы записываете вывод std в файл. Как у вас работает программа? Это автономное приложение или вы работаете на сервере приложений, таком как Tomcat? Например, если вы используете Tomcat, вывод std находится в файле logs / catalina.out. Если вы работаете автономно, вы можете передать свой стандартный вывод в какой-то файл, запустив ваше приложение примерно так: «java -jar myjar.jar> output.log». Надеюсь это поможет.
0

В недавних JVM (OpenJDK/Oracle Java 7 или выше), если вы берете кучу кучи (используя либо VisualVM, либо jmap), он также содержит дамп стеков всех текущих запущенных потоков, со ссылками на соответствующие объекты в куче. Затем вы можете просмотреть стеки, открыв дамп кучи в VisualVM.

Ещё вопросы

Сообщество Overcoder
Наверх
Меню