Java кажется зависшей

Question

Я уже довольно давно использую Java Service wrapper в пользовательском приложении, и оно работает нормально.С момента обновления нашего приложения до новой версии в последние несколько дней JVM начала зависать, а затем wrapper печатает это в журнале:JVM выглядит зависшей:Время ожидания сигнала от JVM истекло.

Затем он автоматически завершает работу JVM и снова запускает приложение.Это происходит примерно через 10 часов работы, что просто усложняет отладку.

Конечно, я собираюсь ознакомиться с изменениями, которые мы внесли, но не было внесено никаких серьезных изменений, которые, как я подозреваю, вызвали бы такого рода проблемы.

Куда я могу обратиться, чтобы попытаться выяснить, что происходит?Отладочные сообщения из приложения не указывают ни на что интересное.Если JVM просто выходит из строя, она обычно создает дамп, что может помочь в ее отладке, но она зависает, поэтому дамп не создается.Если я сделаю так, чтобы служба не перезапускалась автоматически, могу ли я что-нибудь сделать, чтобы получить некоторую полезную информацию из JVM перед ее перезапуском?

Мне кажется, что JVM не должна зависать из-за типичных ошибок программирования.С чем вы сталкивались раньше, что могло привести к зависанию JVM?

Answer 1

У меня было несколько разных версий библиотеки в classpath (JBPM).С помощью wrapper вы можете использовать подстановочные знаки для включения jars.Однако будьте осторожны с этим, так как вы можете случайно включить больше, чем следует.

Вот статья IBM, в которой содержится информация о зависает отладка в Java.В основном это говорит о том, что есть две вещи, которые могут вызвать зависания:

1. Бесконечный цикл,
2. Тупик.

С тех пор мне приходилось отлаживать другие зависшие проблемы.В Linux вы можете отправить JVM сигнал QUIT, чтобы заставить его выполнить дамп потока на консоль.Это действительно помогает понять, в чем проблема.Используйте эту команду, чтобы сделать это:убить -БРОСИТЬ КУРИТЬ

Редактировать 13.06.2017

В эти дни я использую jmap, включенный в JDK, для выгрузки всей памяти программы.Затем я использую Eclipse Memory Analyzer, чтобы увидеть точное состояние программы на момент ее сбоя.Вы можете просмотреть список активных потоков, а затем проверить переменные в каждом фрейме стека.

/usr/java/latest/bin/jmap -dump:file=/tmp/app-crash.hprof <PID>

Где PID - это идентификатор процесса java-процесса.

Answer 2

Прочтите подробнее о свойство wrapper.ping.timeout.Программное обеспечение-оболочка время от времени взаимодействует с вашей виртуальной машиной, чтобы убедиться, что она работает.Если эта связь по какой-либо причине завершается сбоем, оболочка считает процесс зависшим и пытается перезапустить его.

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

Answer 3

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

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

(Редактировать на основе комментария)

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

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

Answer 4

В какой среде вы находитесь?Операционная система, версия JVM, аппаратная архитектура?

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