In anderen Sprachen lesen: Englisch Português 中文

Es gibt viele Debugger-Tutorials, in denen Sie lernen, wie Sie Zeilenhaltepunkte festlegen, Werte protokollieren oder Ausdrücke auswerten. Während Ihnen dieses Wissen allein viele Tools zum Debuggen Ihrer Anwendung bietet, können reale Szenarien etwas komplizierter sein und einen fortgeschritteneren Ansatz erfordern.

In diesem Artikel erfahren Sie, wie Sie ohne große Vorkenntnisse über das Projekt den Code finden, der einen Absturz der Benutzeroberfläche verursacht, und den fehlerhaften Code im Handumdrehen beheben.

Das Problem

Wenn Sie dem Beispiel folgen möchten, klonen Sie zunächst dieses Repository: https://github.com/flounder4130/debugger-example

Angenommen, Sie haben eine komplexe Anwendung, die abstürzt, wenn Sie eine Aktion ausführen. Sie wissen, wie Sie den Fehler reproduzieren können, aber die Schwierigkeit besteht darin, dass Sie nicht wissen, welcher Teil des Codes für diese Funktionalität verantwortlich ist.

In unserer Beispielanwendung tritt der Absturz auf, wenn Sie auf die Schaltfläche N klicken. Allerdings ist es nicht so einfach, den Code zu finden, der für diese Aktion verantwortlich ist:

Sehen wir uns an, wie wir den Debugger verwenden können, um es zu finden.

Methodenhaltepunkte

Der Vorteil von Methoden-Breakpoints gegenüber Zeilen-Breakpoints besteht darin, dass sie in ganzen Klassenhierarchien verwendet werden können. Wie ist das in unserem Fall nützlich?

Wenn Sie sich das Beispielprojekt ansehen, werden Sie feststellen, dass alle Aktionsklassen mit einer einzigen Methode von der Action-Schnittstelle abgeleitet werden: perform().

Durch das Festlegen eines Methodenhaltepunkts für diese Schnittstellenmethode wird die Anwendung jedes Mal angehalten, wenn eine der abgeleiteten Methoden aufgerufen wird. Um einen Methodenhaltepunkt festzulegen, klicken Sie auf die Zeile, die die Methode deklariert.

Starten Sie die Debugging-Sitzung und klicken Sie auf die Schaltfläche N. Die Anwendung wird auf ActionImpl14 angehalten. Jetzt wissen wir, wo sich der Code befindet, der dieser Schaltfläche entspricht.

Obwohl wir uns in diesem Artikel auf die Fehlersuche konzentrieren, kann Ihnen diese Technik auch viel Zeit sparen, wenn Sie verstehen möchten, wie etwas in einer großen Codebasis funktioniert.

Anwendung pausieren

Der Ansatz mit Methodenhaltepunkten funktioniert gut, aber er basiert auf der Annahme, dass wir etwas über die übergeordnete Schnittstelle wissen. Was ist, wenn diese Annahme falsch ist oder wir diesen Ansatz aus einem anderen Grund nicht verwenden können?

Nun, wir können es sogar ohne Haltepunkte machen. Klicken Sie auf die Schaltfläche N und wechseln Sie zu IntelliJ IDEA, während die Anwendung hängt. Wählen Sie im Hauptmenü Ausführen | Debugging-Aktionen | Programm pausieren.

Die Anwendung wird angehalten, sodass wir den aktuellen Status der Threads auf der Registerkarte Threads und Variablen untersuchen können. Dies gibt uns eine Vorstellung davon, was die Anwendung in diesem Moment tut. Da es hängt, können wir die Methode identifizieren, die die Blockierung verursacht, und sie bis zur Aufrufstelle zurückverfolgen.

Dieser Ansatz hat einige Vorteile gegenüber einem traditionelleren Thread-Dump, auf die wir in Kürze eingehen werden. Es stellt Ihnen beispielsweise Informationen zu Variablen in komfortabler Form zur Verfügung und ermöglicht Ihnen die Steuerung der weiteren Programmausführung.

Tipp: Weitere Tipps und Tricks mit Programm anhalten finden Sie unter Debuggen ohne Haltepunkte und Debugger.godMode()

Thread-Dumps

Schließlich können wir einen Thread-Dump verwenden, der nicht unbedingt eine Debugger-Funktion ist. Es ist unabhängig davon verfügbar, ob Sie den Debugger verwenden.

Klicken Sie auf die Schaltfläche N. Während die Anwendung abstürzt, gehen Sie zu IntelliJ IDEA. Wählen Sie im Hauptmenü Ausführen | Debugging-Aktionen | Thread-Dump abrufen.

Erkunden Sie die verfügbaren Threads auf der linken Seite und in AWT-EventQueue sehen Sie, was das Problem verursacht.

Der Nachteil von Thread-Dumps besteht darin, dass sie nur eine Momentaufnahme des Programmstatus zum Zeitpunkt ihrer Erstellung liefern. Sie können Thread-Dumps nicht verwenden, um Variablen zu untersuchen oder die Programmausführung zu steuern.

In unserem Beispiel müssen wir nicht auf einen Thread-Dump zurückgreifen. Ich möchte diese Technik jedoch dennoch erwähnen, da sie in anderen Fällen nützlich sein kann, beispielsweise wenn Sie versuchen, eine Anwendung zu debuggen, die ohne den Debug-Agenten gestartet wurde.

Verstehe das Problem

Unabhängig von der Debugging-Technik kommen wir zu ActionImpl14. In dieser Klasse wollte jemand die Arbeit in einem separaten Thread erledigen, verwechselte jedoch Thread.start() mit Thread.run(), wodurch Code im selben Thread wie der aufrufende Code ausgeführt wird.

Der statische Analysator von IntelliJ IDEA warnt uns sogar zur Entwurfszeit davor:

Eine Methode, die viel Arbeit leistet (oder in diesem Fall viel schläft), wird im UI-Thread aufgerufen und blockiert ihn, bis die Methode beendet ist. Aus diesem Grund können wir in der Benutzeroberfläche eine Zeit lang nichts tun, nachdem wir auf die Schaltfläche N geklickt haben.

HotSwap

Da wir nun die Fehlerursache gefunden haben, beheben wir das Problem.

Wir könnten das Programm stoppen, den Code neu kompilieren und ihn dann erneut ausführen. Allerdings ist es nicht immer sinnvoll, die gesamte Anwendung erneut bereitzustellen, nur weil eine kleine Änderung vorgenommen wurde.

Machen wir es auf die intelligente Art und Weise. Korrigieren Sie zunächst den Code mithilfe der vorgeschlagenen Schnellkorrektur:

Sobald der Code fertig ist, klicken Sie auf Ausführen | Debugging-Aktionen | Geänderte Klassen neu laden. Eine Sprechblase erscheint und bestätigt, dass der neue Code in der VM angekommen ist.

Gehen wir zurück zur Anwendung und prüfen Sie. Durch Klicken auf die Schaltfläche N stürzt die Anwendung nicht mehr ab.

Tipp: Bedenken Sie, dass HotSwap seine Grenzen hat. Wenn Sie an erweiterten HotSwap-Funktionen interessiert sind, ist es möglicherweise eine gute Idee, einen Blick auf erweiterte Tools wie DCEVM oder JRebel zu werfen

Zusammenfassung

Anhand unserer Überlegungen und einiger Debugger-Funktionen konnten wir den Code finden, der einen Absturz der Benutzeroberfläche in unserem Projekt verursacht hat. Anschließend korrigierten wir den Code, ohne Zeit mit der Neukompilierung und Neuverteilung zu verschwenden, was in realen Projekten langwierig sein kann.

Ich hoffe, dass Sie die beschriebenen Techniken nützlich finden. Teilen Sie mir Ihre Meinung mit!

Wenn Sie an weiteren Artikeln zum Thema Debuggen und Profiling interessiert sind, schauen Sie sich einige meiner anderen Artikel an:

• Debugger.godMode() – Eine JVM-Anwendung mit dem Debugger hacken
• Fehlerbehebung beim langsamen Debugger
• Was stimmt nicht mit createDirectories()? - Leitfaden zur CPU-Profilerstellung
• Debug ohne Haltepunkte

Bleiben Sie dran für mehr!