Несколько потоков всунули собственные вызовы (Java)

Мое начальное подозрение было бы то, что Вы испытываете своего рода связанный с загрузчиком класса тупик. Я воображаю, та загрузка класса должна синхронизироваться на некотором уровне, потому что информация о классе станет доступной для всего VM, не только потока, где это было первоначально загружено.

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

Я исследовал бы далее, что идет на мудрую загрузку класса. Возможно, некоторый поток использует загрузчик класса для загрузки класса из сетевого местоположения, которое является медленным/недоступным и таким образом блоки в течение действительно долгого времени, не приводя к монитору другим потокам, которые хотят загрузить класс. Исследование вывода при запуске JVM с-verbose:class могло бы быть одной вещью попробовать.

Можно ли узнать, какой поток на самом деле синхронизируется на мониторе, на котором ожидает собственный метод? По крайней мере, дамп потока, который Вы получаете от VM, когда Вы отправляете ему SIGQUIT (уничтожают-3) должен показать эту информацию, как в

"Thread-0" prio=5 tid=0x0100b060 nid=0x84c000 waiting for monitor entry [0xb0c8a000..0xb0c8ad90]
    at Deadlock$1.run(Deadlock.java:8)
    - waiting to lock <0x255e5b38> (a java.lang.Object)
...
"main" prio=5 tid=0x01001350 nid=0xb0801000 waiting on condition [0xb07ff000..0xb0800148]
    at java.lang.Thread.sleep(Native Method)
    at Deadlock.main(Deadlock.java:21)
- locked <0x255e5b38> (a java.lang.Object)

В дампах Вы отправили до сих пор, я не вижу потока, который на самом деле ожидает для блокировки определенного монитора...

Я имел подобные проблемы несколько месяцев назад и нашел, что jthread(?) утилита была неоценима. Вы даете ему идентификатор процесса для своего JAVA-приложения, и это выведет весь стек для каждого потока в Вашем процессе.

От вывода jthread я видел, что один поток пытался получить блокировку, введя монитор, и другой поток пытался ввести монитор после получения блокировки. Рецепт для мертвой блокировки.

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

Возможно, необходимо использовать другую jdk версию.
Для Вашего "приведения в замешательство один", существует запись ошибки для 1.5.0_08. Об утечке памяти сообщают (я не знаю, если это связано с Вашей проблемой):
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6469701

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