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

<p>я работаю над своими обычными проектами на eclipse, это приложение j2ee, созданное с помощью spring, hibernate и так далее. я использую tomcat 7 для этого (без особой причины, я не использую никаких новых функций, я просто хотел попробовать это). каждый раз, когда я отлаживаю свое приложение, случается, что отладчик eclipse появляется так, как будто он достиг точки останова, но это не так, на самом деле он останавливается на исходном файле java, который <code>threadpoolexecutor</code>. на консоли нет трассировки стека, она просто останавливается. затем, если я нажимаю на резюме, оно продолжается, и приложение работает отлично. вот что показано в окне отладчика:</p><pre><code>daemon thread ["http-bio-8080"-exec-2] (suspended (exception runtimeexception)) threadpoolexecutor$worker.run() line: 912 taskthread(thread).run() line: 619 </code></pre><p>я действительно не могу объяснить это, потому что я вообще не использую <code>threadpoolexecutor</code>. должно быть что-то из tomcat, hibernate или spring. это очень раздражает, потому что мне всегда приходится возобновлять работу во время отладки.</p><p>есть какие-нибудь подсказки?</p>

<p>опубликованная трассировка стека указывает на то, что runtimeexception обнаружен в потоке daemon. это обычно не выполняется во время выполнения, если исходный разработчик не уловил и не обработал исключение.</p><p>как правило, отладчик в eclipse настроен на приостановку выполнения в месте, где было сгенерировано исключение, на <em> всех необработанных исключений </em>. обратите внимание, что исключение может быть обработано позже, ниже в кадре стека и может не привести к завершению потока. это будет причиной наблюдаемого поведения.</p><p><strong>настройка поведения eclipse</strong> просто:<br> перейти к <strong>окно</strong>> <strong>предпочтения</strong>> <strong>java</strong>> <strong>отладка</strong> и снять отметку <strong>приостановить выполнение на невыясненных исключениях</strong>.</p>

<p>существует более конкретное решение, которое предотвращает взлом eclipse для <code>runtimeexception</code>s, генерируемых только из данного класса.</p><ol> <li>добавить новый <strong>точка останова исключения</strong> с точки зрения отладки</li> <li>перейти к своему <strong>свойства</strong></li> <li>перейти к <strong>фильтрация</strong></li> <li>в разделе "ограничить выбранные местоположения" нажмите "<strong>добавить класс</strong>".</li> <li>добавить <code>java.util.concurrent.threadpoolexecutor</code></li> <li><strong>снимите флажок</strong>, то есть они будут <em> игнорироваться </em></li> </ol>

<p>это поведение запускается tomcat при перезагрузке веб-приложения. это часть tomcat <a href="http://wiki.apache.org/tomcat/memoryleakprotection">функция "защиты от утечки памяти"</a> , которая (помимо прочего) заставляет обновлять свои потоки.</p><p>это теперь исправлено в версиях 7.0.54 и 8.0.6 tomcat: <a href="https://issues.apache.org/bugzilla/show\_bug.cgi?id=56492">https://issues.apache.org/bugzilla/show\_bug.cgi?id=56492</a> </p>

<p>я заметил, что это часто происходит после изменения файлов сервера (jsp или java), и у sts возникают проблемы с перезагрузкой приложения.</p><p>обычно это приводит к перезапуску сервера, чтобы синхронизировать изменения.</p><p>после введения jrebel - кажется, ушел. итак, я хотел бы подумать, что это воспроизводимая проблема в sts при горячей замене кода в режиме отладки.</p><p>удаляя нативную горячую замену, она устраняет проблему с ее разрывом внутри класса threadpoolexecutor.</p>