© Excellent backgrounds/Shutterstock.com
Java Magazin
Memory Leaks vorbeugen

Memory Leaks vorbeugen

Der vorangegangene Teil dieser Reihe zu Memory Leaks in Java ging der Frage nach, wie Memory Leaks entstehen [1], [2], [3] und mit welchen Techniken und Tools man nach ihnen suchen kann [4], [5]. Dieses Mal wollen wir uns Weak References genauer ansehen. Mit ihrer Hilfe ist es möglich, Situationen zu vermeiden, in denen Memory Leaks entstehen können.

Angelika Langer, Klaus Kreft


Gehen wir noch einmal zurück zu dem Beispiel eines Memory Leaks, das wir ausführlich im ersten Artikel zum Thema Memory Leaks diskutiert haben [1]. In dem Beispiel haben wir einen rudimentären Server auf Basis der mit Java 7 eingeführten AsynchronousSocketChannels implementiert. Das Memory Leak entstand dadurch, dass wir im Server für jeden neuen Client Verwaltungsinformationen in einer Map gespeichert und diese clientspezifischen Map-Einträge nicht nach der Beendigung der Kommunikation mit den jeweiligen Clients wieder gelöscht haben. Es ist offensichtlich, dass sich die Map mit jedem neuen Client vergrößert. Erzeugt man also in einem Testprogramm viele Clients hintereinander, so stürzt der Server irgendwann mit einem OutOfMemoryError ab. Der Sourcecode zu dem Beispiel sowie verschiedene alternative Korrekturen finden sich unter [6].

Wie wir in dem darauf folgenden Artikel [2] diskutiert haben, ist diese Situation relativ typisch für ein Memory Leak, das zu einem OutOfMemoryError führt. Es gibt in Java häufig Verwaltungen, in die man Objekte eintragen und aus denen man letztere, wenn sie nicht mehr benötigt werden, auch wieder löschen muss. Ein weiteres Beispiel, das wir uns dazu angesehen haben, ist die Verwaltung der Callbacks, die man als AWT Event Listener einhängt.

In unserer Artikelserie sind wir bisher so verblieben, dass es Aufgabe des Benutzers ist, solche Verwaltungen korrekt zu verwenden. Das heißt, er muss darauf achten, dass er jedes Objekt, das er in eine solche Verwaltung eingetragen hat, auch zum angemessenen Zeitpunkt wieder löscht. Wenn er sich nicht daran hält, hat er als Konsequenz das entstandene Memory Leak und den eventuell folgenden Programmabsturz aufgrund eines OutOfMemoryError zu verantworten.

Ungewollte Referenzen und Weak References

In diesem Artikel wollen wir nun sehen, ob derjenige, der die Verwaltung implementiert und bereitstellt, nicht auch etwas tun kann, was dazu führt, dass es erst gar nicht zu Memory Leaks kommen kann. Schön wäre es doch, wenn der Benutzer sich gar nicht um das Löschen kümmern müsste, weil dies automatisch erledigt wird.

Um zu verstehen, wie so etwas gehen könnte, rufen wir uns noch einmal in Erinnerung, wie es genau zu einem Memory Leak kommt. Der Garbage Collector ermittelt ausgehend von so genannten Root References, welche Objekte in einem Java-Programm referenziert und damit erreichbar sind. Alle nicht erreichbaren Objekte räumt der Garbage Collector bei der Garbage Collection weg und gibt ihren Sp...

Java Magazin
Memory Leaks vorbeugen

Memory Leaks vorbeugen

Der vorangegangene Teil dieser Reihe zu Memory Leaks in Java ging der Frage nach, wie Memory Leaks entstehen [1], [2], [3] und mit welchen Techniken und Tools man nach ihnen suchen kann [4], [5]. Dieses Mal wollen wir uns Weak References genauer ansehen. Mit ihrer Hilfe ist es möglich, Situationen zu vermeiden, in denen Memory Leaks entstehen können.

Angelika Langer, Klaus Kreft


Gehen wir noch einmal zurück zu dem Beispiel eines Memory Leaks, das wir ausführlich im ersten Artikel zum Thema Memory Leaks diskutiert haben [1]. In dem Beispiel haben wir einen rudimentären Server auf Basis der mit Java 7 eingeführten AsynchronousSocketChannels implementiert. Das Memory Leak entstand dadurch, dass wir im Server für jeden neuen Client Verwaltungsinformationen in einer Map gespeichert und diese clientspezifischen Map-Einträge nicht nach der Beendigung der Kommunikation mit den jeweiligen Clients wieder gelöscht haben. Es ist offensichtlich, dass sich die Map mit jedem neuen Client vergrößert. Erzeugt man also in einem Testprogramm viele Clients hintereinander, so stürzt der Server irgendwann mit einem OutOfMemoryError ab. Der Sourcecode zu dem Beispiel sowie verschiedene alternative Korrekturen finden sich unter [6].

Wie wir in dem darauf folgenden Artikel [2] diskutiert haben, ist diese Situation relativ typisch für ein Memory Leak, das zu einem OutOfMemoryError führt. Es gibt in Java häufig Verwaltungen, in die man Objekte eintragen und aus denen man letztere, wenn sie nicht mehr benötigt werden, auch wieder löschen muss. Ein weiteres Beispiel, das wir uns dazu angesehen haben, ist die Verwaltung der Callbacks, die man als AWT Event Listener einhängt.

In unserer Artikelserie sind wir bisher so verblieben, dass es Aufgabe des Benutzers ist, solche Verwaltungen korrekt zu verwenden. Das heißt, er muss darauf achten, dass er jedes Objekt, das er in eine solche Verwaltung eingetragen hat, auch zum angemessenen Zeitpunkt wieder löscht. Wenn er sich nicht daran hält, hat er als Konsequenz das entstandene Memory Leak und den eventuell folgenden Programmabsturz aufgrund eines OutOfMemoryError zu verantworten.

Ungewollte Referenzen und Weak References

In diesem Artikel wollen wir nun sehen, ob derjenige, der die Verwaltung implementiert und bereitstellt, nicht auch etwas tun kann, was dazu führt, dass es erst gar nicht zu Memory Leaks kommen kann. Schön wäre es doch, wenn der Benutzer sich gar nicht um das Löschen kümmern müsste, weil dies automatisch erledigt wird.

Um zu verstehen, wie so etwas gehen könnte, rufen wir uns noch einmal in Erinnerung, wie es genau zu einem Memory Leak kommt. Der Garbage Collector ermittelt ausgehend von so genannten Root References, welche Objekte in einem Java-Programm referenziert und damit erreichbar sind. Alle nicht erreichbaren Objekte räumt der Garbage Collector bei der Garbage Collection weg und gibt ihren Sp...

Neugierig geworden?


   
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang