Что может быть причиной дампов потоков JVM, которые показывают потоки, ожидающие блокировки на мониторе, но у мониторов нет соответствующих потоков блокировки?
Java 1.5_14 в Windows 2003




Это просто дикая догадка, но может ли поток блокировать себя, дважды пытаясь получить блокировку? Возможно, вам поможет, если вы разместите какой-нибудь код.
Да, обычно у каждого заблокированного монитора должен быть поток-владелец. Возможно, ваш дамп стека был неполным (слишком длинным) или, возможно, выгрузка не была последовательной. Я мог представить, что это не останавливает мир, поэтому заблокированный монитор сбрасывается, но поток, которому принадлежит блокировка, освобождает его, прежде чем он будет сброшен (это всего лишь предположение).
Можете ли вы где-нибудь загрузить дамп в виде текстового файла для облегчения поиска и сообщить нам, на какой монитор вы смотрите.
Использует ли ваш код при каких-либо изменениях какой-либо JNI? (т.е. вы используете какой-либо собственный код, запущенный с Java?).
Мы видели подобное поведение, но JDK 1.6.0_05. Кажется, что приложение находится в тупике, но Jstack показывает потоки, ожидающие блокировки, которую не удерживают другие потоки. У нас есть код JNI, так что, возможно, мы что-то испортили.
Мы не нашли решения для этого, и проблема воспроизводится только на 1 машине.
Эти ожидающие потоки ждут вечно или в конце концов продолжаются?
В последнем случае блокировка может быть удержана сборщиком мусора.
Вы можете добавить аргументы -verbose:gc with -XX:+PrintGCDetails в свою командную строку java, чтобы получать информацию о возникновении GC. Если активность gc совпадает с вашими замедлениями, это может указывать на то, что это проблема.
Вот какой-то информация о вывозе мусора.
В конечном итоге они продолжаются через несколько минут. Как я могу подтвердить, удерживается ли он сборщиком мусора. Стоит ли ожидать увидеть поток сборщика мусора в дампе потока?
Сегодня у меня была аналогичная проблема, и она также связана с доступом к статическим ресурсам.
Краткая версия заключается в том, что класс внес изменения графического интерфейса в статический блок и за пределами потока AWT-EventQueue, которые были заблокированы AWT TreeLock, затем EventQueue сделал ссылку на заблокированный класс, что заставило его ждать монитор загрузчика классов для этого класса.
Ключевым замечанием здесь является то, что блокировка для загрузчика классов не отображалась как заблокированная в дампе потока.
Полный ответ можно найти в этой теме.
Вы пробовали обновиться до Java 1.6? Ошибка может быть вашей проблемой, если вы используете только версию 1.5.
У тебя есть свалка, которую мы могли увидеть?