web-dev-qa-db-ja.com

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からのものでなければなりません。デバッグ中は常に再開する必要があるため、非常に迷惑です。

手がかりはありますか？

javaeclipsedebuggingtomcat
206
gotch4

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

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

Eclipseの動作の設定は簡単です：
Go to Window> Preferences> Java> Debug and uncheck Suspend executionキャッチされない例外。

286
Vineet Reynolds

特定のクラスからのみスローされるRuntimeExceptionsでEclipseが壊れるのを防ぐ、より具体的なソリューションがあります。

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

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

これは、Tomcatのバージョン7.0.54および8.0.6から修正されました。 https://issues.Apache.org/bugzilla/show_bug.cgi?id=56492

23
slaurent

サーバーファイル（jspまたはJava）を変更した後にこれが頻繁に発生し、STSがアプリケーションの再ロードに問題があることに気付きました。

通常、これにより、サーバーを再起動して変更を同期させることができます。

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

ネイティブのホットスワップを削除することにより、ThreadPoolExecutorクラス内でのホットスワップの問題を解消します。

2
DaCrazyCoder