応答しないアプリケーションをデバッグする

他の言語で読む: English Português 中文

行ブレークポイントの設定、値のログ記録、または式の評価方法を説明するデバッガー チュートリアルが多数あります。この知識だけでもアプリケーションをデバッグするための多くのツールが得られますが、実際のシナリオはもう少し複雑で、より高度なアプローチが必要になる場合があります。

この記事では、プロジェクトに関する事前知識があまりなくても、UI クラッシュの原因となるコードを特定し、その場で壊れたコードを修正する方法を学びます。

問題

例に従う場合は、まずこのリポジトリのクローンを作成します: https://github.com/flounder4130/debugger-example

何らかのアクションを実行するとクラッシュする複雑なアプリケーションがあるとします。エラーを再現する方法はわかっていますが、問題は、コードのどの部分がこの機能を担当しているのかがわからないことです。

このサンプル アプリでは、ボタン N をクリックするとクラッシュが発生します。ただし、このアクションを実行するコードを見つけるのはそれほど簡単ではありません:

デバッガーを使用してそれを見つける方法を見てみましょう。

メソッドのブレークポイント

メソッド ブレークポイントの行ブレークポイントに対する利点は、クラス階層全体で使用できることです。これは私たちの場合にどのように役立ちますか?

サンプル プロジェクトを見ると、すべてのアクション クラスが単一のメソッド Perform() を使用して Action インターフェイスから派生していることがわかります。

このインターフェイス メソッドにメソッド ブレークポイントを設定すると、派生メソッドのいずれかが呼び出されるたびにアプリケーションが一時停止されます。メソッド ブレークポイントを設定するには、メソッドを宣言する行をクリックします。

デバッグ セッションを開始し、ボタン N をクリックします。アプリケーションは ActionImpl14 で一時停止されます。これで、このボタンに対応するコードがどこにあるかが分かりました。

この記事ではバグの発見に重点を置いていますが、このテクニックは、大規模なコードベースで何かがどのように動作するかを理解したいときにも大幅に時間を節約できます。

アプリケーションを一時停止する

メソッド ブレークポイントを使用したアプローチはうまく機能しますが、親インターフェイスについて何かを知っているという前提に基づいています。この仮定が間違っていたり、他の理由でこのアプローチを使用できない場合はどうなりますか?

そうですね、ブレークポイントなしでも実行できます。 ボタン N をクリックし、アプリケーションがハングしている間に IntelliJ IDEA に移動します。メイン メニューから、実行 | を選択します。 アクションのデバッグ | プログラムを一時停止します.

アプリケーションが一時停止され、スレッドと変数 タブでスレッドの現在の状態を調べることができます。これにより、アプリケーションがその時点で何をしているのかがわかります。ハングしているため、ブロックの原因となっているメソッドを特定し、呼び出しサイトまで追跡できます。

このアプローチには、従来のスレッド ダンプに比べていくつかの利点があります。これについては後ほど説明します。たとえば、変数に関する情報を便利な形式で提供し、プログラムのさらなる実行を制御できるようにします。

ヒント:プログラムの一時停止に関するその他のヒントとテクニックについては、ブレークポイントを使用しないデバッグと Debugger.godMode()

を参照してください。

スレッドダンプ

最後に、スレッド ダンプを使用できます。これは厳密にはデバッガ機能ではありません。デバッガを使用しているかどうかに関係なく利用できます。

ボタン N をクリックします。アプリケーションがクラッシュしている間に、IntelliJ IDEA に移動します。メイン メニューから、実行 | を選択します。 アクションのデバッグ | スレッド ダンプを取得.

左側で使用可能なスレッドを調べると、AWT-EventQueue で問題の原因がわかります。

スレッド ダンプの欠点は、スレッド ダンプが作成された時点のプログラムの状態のスナップショットしか提供しないことです。スレッド ダンプを使用して変数を調べたり、プログラムの実行を制御したりすることはできません。

この例では、スレッド ダンプに頼る必要はありません。ただし、このテクニックは、デバッグ エージェントなしで起動されたアプリケーションをデバッグしようとする場合など、他の場合にも役立つ可能性があるため、それでも言及しておきたいと思いました。

問題を理解する

デバッグ手法に関係なく、ActionImpl14 に到達します。このクラスでは、誰かが別のスレッドで作業を行うつもりでしたが、Thread.start() と、呼び出し元のコードと同じスレッドでコードを実行する Thread.run() を混同しました。

IntelliJ IDEA の静的アナライザーは、設計時にこれについて警告します。

負荷の高い作業を行う (この場合は長時間スリープする) メソッドが UI スレッドで呼び出され、メソッドが終了するまでブロックされます。そのため、ボタン N をクリックした後、しばらく UI で何もできなくなります。

ホットスワップ

エラーの原因が判明したので、問題を修正しましょう。

プログラムを停止し、コードを再コンパイルして、再度実行することもできます。ただし、小さな変更が加えられたからといって、アプリケーション全体を再デプロイすることが常に賢明であるとは限りません。

賢い方法でやりましょう。まず、提案されているクイックフィックスを使用してコードを修正します。

コードの準備ができたら、[実行] をクリックします。 アクションのデバッグ | 変更されたクラスを再ロードします。バルーンが表示され、新しいコードが VM に到着したことが確認されます。

アプリに戻って確認してみましょう。 ボタン N をクリックしてもアプリがクラッシュしなくなりました。

ヒント: ホットスワップには制限があることに注意してください。拡張 H​​otSwap 機能に興味がある場合は、DCEVM や JRebel

などの高度なツールを検討してみると良いでしょう。

まとめ

私たちの推論といくつかのデバッガー機能を使用して、プロジェクト内で UI クラッシュの原因となっているコードを特定することができました。その後、実際のプロジェクトでは時間がかかる可能性がある再コンパイルと再配布に時間を無駄にすることなく、コードの修正を進めました。

ここで説明したテクニックがお役に立てば幸いです。ご意見をお聞かせください!

デバッグとプロファイリングに関連する他の記事に興味がある場合は、私の他の記事をいくつかチェックしてください:

• Debugger.godMode() – デバッガーを使用して JVM アプリケーションをハックします
• 遅いデバッガーのトラブルシューティング
• createDirectories() の何が問題ですか? - CPU プロファイリングのガイド
• ブレークポイントを使用しないデバッグ

今後の続報をお楽しみに!

以上が応答しないアプリケーションをデバッグするの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。