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

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

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

問題

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

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

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

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

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

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

サンプル プロジェクトを見ると、すべてのアクション クラスが単一のメソッド Perform().

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

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

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

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

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

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

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

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

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

スレッドダンプ

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

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

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

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

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

問題を理解する

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

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

重い作業を行うメソッド (この場合は長時間スリープするメソッド) が UI スレッドで呼び出され、メソッドが終了するまでブロックされます。そのため、ボタン N.

ホットスワップ

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

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

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

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

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

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

まとめ

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

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

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

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

続報をお楽しみに！