Отладчик Eclipse всегда блокирует ThreadPoolExecutor без каких-либо явных исключений, почему?

Question

Я работаю над своими обычными проектами на Eclipse, это приложение J2EE, созданное с помощью Spring, Hibernate и так далее. Я использую Tomcat 7 для этого (без особой причины, я не использую никаких новых функций, я просто хотел попробовать это). Каждый раз, когда я отлаживаю свое приложение, случается, что отладчик Eclipse выскакивает, как будто он достиг точки останова, но это не так, фактически он останавливается на исходном файле Java, который является ThreadPoolExecutor. На консоли нет трассировки стека, она просто останавливается. Затем, если я нажимаю на резюме, оно продолжается, и приложение работает отлично. Вот что показано в окне отладчика:

Daemon Thread ["http-bio-8080"-exec-2] (Suspended (exception RuntimeException)) 
    ThreadPoolExecutor$Worker.run() line: 912   
    TaskThread(Thread).run() line: 619

Я действительно не могу объяснить это, потому что я вообще не использую ThreadPoolExecutor. Должно быть что-то из Tomcat, Hibernate или Spring. Это очень раздражает, потому что мне всегда приходится возобновлять работу во время отладки.

Есть какие-нибудь подсказки?

Answer 1

Опубликованная трассировка стека указывает на то, что в потоке демона обнаружена исключительная ситуация RuntimeException. Обычно это не выполняется во время выполнения, если только первоначальный разработчик не обнаружил и не обработал исключение.

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

Настройка поведения Eclipse проста:
Перейдите к Окно > Предпочтения > Java > Отладка и снимите флажок Приостановите выполнение на невыполненных исключениях .

Answer 2

Существует более конкретное решение, которое предотвращает взлом Eclipse на RuntimeException s, генерируемых только из данного класса.

1. Добавить новую точку останова исключения с точки зрения отладки
2. Перейти к свойствам
3. Перейти к Фильтрация
4. В «Ограничить выбранные местоположения» нажмите « Добавить класс »
5. Добавить java.util.concurrent.ThreadPoolExecutor
6. Снимите флажок , означая, что они будут игнорироваться

Answer 3

Это поведение запускается tomcat при перезагрузке веб-приложения. Это часть функции tomcat «защита от утечки памяти» , которая (помимо прочего) заставляет обновлять свои потоки.

Это исправлено в версиях 7.0.54 и 8.0.6 tomcat: https://issues.apache.org/bugzilla/show_bug.cgi?id=56492

Answer 4

Я заметил, что это часто происходит после изменения файлов сервера (jsp или java), и у STS возникают проблемы с перезагрузкой приложения.

Обычно это приводит к перезапуску сервера, чтобы синхронизировать изменения.

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

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