Eclipseデバッガーは、明らかな例外なしに常にThreadPoolExecutorをブロックしますが、なぜですか？

私はEclipseで通常のプロジェクトに取り組んでいます。これは、Spring、Hibernateなどで作成されたJ2EEアプリケーションです。私はこのために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のいずれかである必要があります。デバッグ中に常に再開しなければならないので、非常に迷惑です。

手がかりはありますか？

ポストされたスタックトレースは、デーモンスレッドでRuntimeExceptionが発生したことを示しています。元の開発者が例外をキャッチして処理しない限り、これは通常、実行時に捕捉されません。

通常、Eclipseのデバッガーは、キャッチされなかったすべての例外について、例外がスローされた場所で実行を中断するように構成されています。例外は後で処理される場合があり、スタックフレームの下位に移動し、スレッドが終了しない場合があることに注意してください。これが、観察された動作の原因になります。

Eclipseの動作を構成するのは簡単です。[ ウィンドウ] > [ 設定] > [ Java ] > [ デバッグ]に
移動し、[ キャッチされなかった例外で実行を中断]をオフにします。

より具体的な解決策があります。これはRuntimeException、特定のクラスからのみスローされたでEclipseが壊れるのを防ぎます。

1. 新しい例外ブレークポイントを追加するデバッグの観点から
2. そのに行く プロパティにます
3. に行く フィルタリングに
4. 「選択した場所に制限」で、「クラスを追加」をクリックします。
5. 追加 java.util.concurrent.ThreadPoolExecutor
6. チェックボックスをオフにします。つまり、これらは無視されます

この動作は、WebアプリケーションがリロードされるときにTomcatによってトリガーされます。Tomcatの「メモリリーク保護」機能の一部です、（特に）スレッドの更新を強制する。

これは、現在のバージョン7.0.54とTomcatの8.0.6から固定されている。 https://issues.apache.org/bugzilla/show_bug.cgi?id=56492

これは、サーバーファイル（jspまたはjava）を変更した後に頻繁に発生し、STSがアプリケーションをリロードできないことに気づきました。

これは通常、変更を同期させるためにサーバーを再起動することになります。

JRebelの導入後-なくなったようです。したがって、デバッグモードでコードをホットスワップするときに、STSで再現可能な問題であると考えたいと思います。

ネイティブのホットスワップを削除することで、ThreadPoolExecutorクラスの内部で問題が発生する問題を排除します。