Debuggen Sie nicht reagierende Anwendungen

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 dieses Wissen allein Ihnen 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 Beispiel-App kommt es zum Absturz, wenn Sie auf den Button N klicken. Allerdings ist es nicht so einfach, den Code zu finden, der für diese Aktion verantwortlich ist:

Mal sehen, 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 gesamten Klassenhierarchien verwendet werden können. Wie nützlich ist das in unserem Fall?

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, basiert jedoch 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 & Variablen überprüfen 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 Ausführung des Programms.

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.

Durchsuchen 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 wollte 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(), das Code im selben Thread wie der aufrufende Code ausführt.

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 abgeschlossen 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 entdeckt 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.

Lass es uns auf die intelligente Art und Weise tun. Korrigieren Sie zunächst den Code mit 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 App und überprüfen es. Durch Klicken auf die Schaltfläche N stürzt die App 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() – Hacken Sie eine JVM-Anwendung mit dem Debugger
• Fehlerbehebung beim langsamen Debugger
• Was stimmt nicht mit createDirectories()? - Leitfaden zur CPU-Profilerstellung
• Debuggen ohne Haltepunkte

Bleiben Sie dran für mehr!

Das obige ist der detaillierte Inhalt vonDebuggen Sie nicht reagierende Anwendungen. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!