Eine Anleitung zum Verwalten des Java-Speichers (und zum Speichern Ihres Codes)

Anmerkung des Übersetzers: Der Wunsch, die Notiz zu übersetzen, kam früh an einem Junimorgen auf, nachdem ich sie im Halbschlaf in einem U-Bahn-Wagen gelesen hatte. Zielgruppe: Personen, die ihre ersten Schritte in der Welt von Java machen und aufgrund ihres grundlegenden technischen Hintergrunds oder Wunsches sehr daran interessiert sind, unter die Haube von Java zu kommen und alle „elektrodynamischen“ Prozesse zu erlernen. Ich bin sicher, dass dies für diejenigen, die dies lesen, der Ausgangspunkt für eine Reise in die Welt der Konfiguration von JVM und GC sein wird. Leichter Wind! Originalartikel hier Als Entwickler verbringen Sie unzählige Stunden damit, Fehler aus einer Java-Anwendung zu beseitigen und die Leistung dorthin zu bringen, wo sie sein muss. Beim Testen stellen Sie fest, dass die Anwendung nach und nach langsamer läuft und am Ende komplett abstürzt oder einfach nur eine schlechte Leistung zeigt. Akzeptieren Sie schließlich, dass Speicherverluste auftreten. Der Garbage Collector Java tut sein Bestes, um diese Lecks zu beheben. Aber es gibt nur eine begrenzte Menge Dinge, die man in solchen Situationen tun kann. Sie benötigen Möglichkeiten, Speicherverlustaufrufe zu identifizieren, Ursachen zu ermitteln und die Rolle des Java-Garbage Collectors bei der Auswirkung auf die Gesamtleistung der Anwendung zu verstehen.

Hauptsymptome von Java-Speicherlecks

Es gibt mehrere Symptome, die darauf hinweisen, dass eine Anwendung Probleme mit Speicherverlusten hat. Ein leichter Leistungsabfall und kein plötzlicher Anwendungsfehler deutet lediglich auf einen Speicherverlust hin. Das Problem kann jedes Mal während des Betriebs auftreten oder nur, wenn die Anwendung mit einer großen Datenmenge zu arbeiten beginnt oder Sie im Gegenteil mit der Skalierung der Anwendung beginnen. Die Anwendung wird wahrscheinlich einen Fehler wegen unzureichendem Speicher anzeigen, sobald das Leck alle verfügbaren Speicherressourcen verbraucht hat. Wenn Sie die Anwendung neu starten und auf das Beste hoffen, kommt es zu wiederholten Abstürzen, bis das Leck behoben ist. Im Allgemeinen treten Speicherlecks auf, wenn sich Objektverweise ansammeln, anstatt Speicher freizugeben. Sie belegen den gesamten verfügbaren Speicher und machen es der Anwendung unmöglich, auf die benötigten Ressourcen zuzugreifen.

Konfigurationsfehler, die als Speicherlecks erscheinen

Bevor Sie Situationen untersuchen, die Java-Speicherprobleme verursachen, und eine Analyse durchführen, müssen Sie sicherstellen, dass die Untersuchung nicht mit einem völlig anderen Problem zusammenhängt. Einige Fehler wegen unzureichendem Arbeitsspeicher treten aufgrund verschiedener Fehler auf, beispielsweise aufgrund von Konfigurationsfehlern. Möglicherweise verfügt die Anwendung nur noch über wenig Heap-Speicher oder es besteht ein Konflikt mit anderen Anwendungen auf dem System. Wenn Sie anfangen, über Probleme mit wenig Arbeitsspeicher zu sprechen, aber nicht herausfinden können, was die Ursache für das Leck ist, werfen Sie einen anderen Blick auf die Anwendung. Sie werden feststellen, dass Sie Änderungen am Finalisierungsthread vornehmen oder die Menge des permanenten Generierungsraums erhöhen müssen, bei dem es sich um einen Bereich des JVM-Speichers zum Speichern von Beschreibungen von Java-Klassen und einigen zusätzlichen Daten handelt.

Vorteile von Speicherüberwachungstools

Speicherüberwachungstools bieten einen besseren Einblick in die Nutzung verfügbarer Ressourcen durch eine Java-Anwendung. Durch die Verwendung dieser Software können Sie die Suche nach der Ursache des Problems von Speicherverlusten und anderen Leistungsstörungen einen Schritt weiter eingrenzen. Die Tools gibt es in mehreren Kategorien, und Sie müssen möglicherweise verschiedene Anwendungen verwenden, um herauszufinden, wie Sie das Problem richtig kennzeichnen und was schief gelaufen ist, selbst wenn Sie mit Speicherlecks zu tun haben. Heap-Dump-Dateien liefern die notwendigen Informationen zur Analyse des Java-Speichers. In diesem Fall müssen Sie zwei Tools verwenden: eines zum Generieren einer Dump-Datei und eines zur detaillierten Analyse. Diese Lösung bietet detaillierte Informationen darüber, was mit der Anwendung passiert. Sobald das Tool die Orte möglicher Probleme lokalisiert und den Bereich eingrenzt, um den genauen Ort des Vorfalls zu ermitteln. Und dieser Zeitraum ist die Zeit des längsten und deprimierendsten Teils von Versuch und Irrtum. Der Speicheranalysator weist auf mehrere Probleme in Ihrem Code hin, Sie sind sich jedoch nicht ganz sicher, auf welche Probleme Ihre Anwendung stößt. Wenn immer noch derselbe Fehler auftritt, beginnen Sie von vorne und arbeiten Sie an einem anderen möglichen Fehler. Nehmen Sie jeweils eine Änderung vor und versuchen Sie, den Fehler zu duplizieren. Sie müssen die Anwendung einige Zeit laufen lassen, um die Fehlerbedingungen zu duplizieren. Wenn beim ersten Test ein Speicherverlust auftritt, stellen Sie sicher, dass Sie die Anwendung einem Lasttest unterziehen. Eine Anwendung funktioniert möglicherweise mit einer kleinen Datenmenge einwandfrei, kann jedoch bei der Arbeit mit einer großen Datenmenge erneut dieselben Fehler auslösen. Wenn derselbe Fehler weiterhin auftritt, müssen Sie von vorne beginnen und nach einer anderen möglichen Ursache suchen. Speicherüberwachungstools beweisen ihre Nützlichkeit, sobald die Anwendung vollständig betriebsbereit ist. Sie können die JVM-Leistung aus der Ferne überwachen und Fehlersituationen proaktiv erkennen, bevor ein Entwickler sich mit dem Problem befasst und historische Leistungsdaten sammelt, um seine Programmiertechniken in Zukunft zu verbessern und zu sehen, wie Java unter hoher Last funktioniert. Viele Lösungen umfassen „Gefahren“-Alarmmodi oder andere ähnliche Modi, sodass der Entwickler sofort erkennen kann, was schief läuft. Jeder Entwickler möchte nicht, dass eine kritische Anwendung während der Produktion abstürzt und während der Ausfallzeit der Anwendung einen Verlust von Zehntausenden oder Hunderttausenden von Dollar verursacht. Speicherüberwachungstools verkürzen daher die Reaktionszeit des Entwicklers. Mit Speicherüberwachungsanwendungen können Sie den Diagnoseprozess sofort starten, anstatt Sie zum Kunden zu bitten, wo Ihnen niemand genau sagen kann, welcher Fehler aufgetreten ist oder welchen Fehlercode die Anwendung generiert hat. Wenn Sie häufig mit Speicher- und Leistungsproblemen Ihrer Java-Anwendung konfrontiert werden, sollten Sie sich eingehend mit dem Testprozess befassen. Identifizieren Sie jeden Schwachpunkt im Entwicklungsprozess und ändern Sie Ihre Teststrategien. Beraten Sie sich mit Kollegen und vergleichen Sie Ihre Testansätze mit bestehenden Best Practices. Manchmal müssen Sie einen kleinen Codeabschnitt überarbeiten und dann eine nachhaltige Wirkung auf die gesamte Anwendung erzielen.

Rolle des Garbage Collectors bei Java-Speicher und Speicherlecks

Garbage Collector in Java spielt eine Schlüsselrolle für die Anwendungsleistung und Speichernutzung. Es sucht nach unbenutzten (toten) Objekten und löscht diese. Diese Objekte belegen keinen Speicher mehr, sodass Ihre Anwendung weiterhin die Ressourcenverfügbarkeit gewährleistet. Manchmal gibt die Anwendung dem GC nicht genügend Zeit oder Ressourcen, um tote Objekte zu entfernen, und diese sammeln sich an. Es kann vorkommen, dass aktiv auf Objekte zugegriffen wird, von denen Sie glauben, dass sie tot sind. Der Garbage Collector kann dagegen nichts tun, weil ... Sein automatisierter Speicherverwaltungsmechanismus umgeht aktive Objekte. Normalerweise arbeitet der Garbage Collector autonom, Sie müssen sein Verhalten jedoch anpassen, um auf schwerwiegende Speicherprobleme zu reagieren. Allerdings kann GC selbst Leistungsprobleme verursachen.

GC-Bereiche

Der Garbage Collector trennt Objekte in verschiedene Bereiche, um die Montage zu optimieren. Young Generation zeigt Objekte, die schnell aussterben. Der Müllsammler arbeitet oft in diesem Bereich, wenn er aufräumen muss. Objekte, die nach Erreichen eines bestimmten Zeitraums am Leben bleiben, werden auf die alte Generation übertragen. Im Old-Generation-Bereich bleiben Objekte lange erhalten und werden vom Sammler nicht so oft entfernt. Wenn der Collector jedoch im Bereich ausgeführt wird, durchläuft die Anwendung einen umfangreichen Vorgang, bei dem der Collector lebende Objekte durchsucht, um Müll zu bereinigen. Infolgedessen befinden sich Anwendungsobjekte im endgültigen permanenten Generierungsbereich. Typischerweise umfassen diese Objekte die erforderlichen JVM-Metadaten. Die Anwendung erzeugt bei der permanenten Generierung nicht viel Müll, benötigt aber einen Collector, um Klassen zu entfernen, wenn die Klassen nicht mehr benötigt werden.

Zusammenhang zwischen Garbage Collector und Antwortzeit

Unabhängig von der Ausführungspriorität der Anwendungsthreads stoppt der Garbage Collector diese, ohne auf den Abschluss zu warten. Dieses Phänomen wird als „Stop the World“-Ereignis bezeichnet. Der Young-Generation-Bereich des Garbage Collectors hat einen geringen Einfluss auf die Leistung, es treten jedoch Probleme auf, wenn der GC eine intensive Bereinigung durchführt. Sie geraten in eine Situation, in der der Minor-GC der jungen Generation ständig läuft oder die alte Generation in einen unkontrollierten Zustand gerät. In einer solchen Situation müssen Sie die Frequenz der jungen Generation mit der Leistung in Einklang bringen, die eine Vergrößerung dieser Kollektorfläche erfordert. Die Bereiche „Permanente Generation“ und „Alte Generation“ des Garbage Collectors haben erhebliche Auswirkungen auf die Anwendungsleistung und die Speichernutzung. Bei diesem großen Müllbeseitigungsvorgang wird der Haufen durchsucht, um tote Objekte auszusortieren. Der Vorgang dauert länger als ein kleiner Build und die Auswirkungen auf die Leistung können länger dauern. Wenn die Scrubbing-Intensität hoch und der Bereich der alten Generation groß ist, wird die Leistung der gesamten Anwendung aufgrund von „Stop the World“-Ereignissen beeinträchtigt. Um die Garbage Collection zu optimieren, muss überwacht werden, wie oft ein Programm ausgeführt wird, welche Auswirkungen es auf die Gesamtleistung hat und wie Anwendungseinstellungen angepasst werden können, um die Häufigkeit der Überwachung zu reduzieren. Möglicherweise müssen Sie dasselbe Objekt identifizieren, das mehr als einmal platziert wurde, ohne dass sich die Anwendung von der Platzierung abgrenzen muss, oder Sie müssen möglicherweise die Komprimierungspunkte finden, die das gesamte System zurückhalten. Um das richtige Gleichgewicht zu finden, müssen Sie genau auf alles achten, von der CPU-Auslastung bis hin zu Ihren Garbage-Collector-Zyklen, insbesondere wenn die junge und alte Generation nicht im Gleichgewicht sind. Die Behebung von Speicherlecks und die Optimierung der Garbage Collection tragen dazu bei, die Leistung einer Java-Anwendung zu verbessern. Sie jonglieren buchstäblich mit vielen beweglichen Teilen. Aber mit dem richtigen Ansatz zur Fehlerbehebung und den richtigen Analysetools, die für umfassende Transparenz sorgen, werden Sie das Licht am Ende des Tunnels erreichen. Andernfalls kommt es zu Leistungsproblemen. Eine sorgfältige Speicherplatzierung und -überwachung spielen in einer Java-Anwendung eine entscheidende Rolle. Sie müssen die vollständige Kontrolle über die Interaktion zwischen Speicherbereinigung, Objektentsorgung und Leistung übernehmen, um Ihre Anwendung zu optimieren und Fehler aufgrund von unzureichendem Arbeitsspeicher zu vermeiden. Überwachungstools helfen Ihnen, den Überblick über potenzielle Probleme zu behalten und Trends bei der Speichernutzung aufzuzeigen, sodass Sie einen proaktiven Ansatz zur Fehlerbehebung verfolgen können. Speicherlecks zeigen oft, dass die übliche Fehlerbehebung wirkungslos ist, insbesondere wenn Sie auf falsche Konfigurationsparameterwerte stoßen. Die Lösung speicherbezogener Probleme kann Ihnen jedoch dabei helfen, Vorfälle, die Ihnen im Weg stehen, schnell zu vermeiden. Die Perfektion von Java-Speicheroptimierung und GC erleichtert Ihren Entwicklungsprozess erheblich.