Umgang mit ungewollten Referenzen: ausnullen oder nicht?

Memory Leaks: ausgenullt

Angelika Langer, Klaus Kreft


Rufen wir uns noch einmal in Erinnerung, wie es zu einem Memory Leak in Java 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 Speicher frei. Wenn wir nun auf ein Objekt verweisen, von dem wir sicher sagen können, dass wir es im weiteren Kontext unseres Programms gar nicht mehr benutzen werden, haben wir ein Memory Leak. Denn das nicht mehr benötigte Objekt wird vom Garbage Collector nicht weggeräumt, weil es noch referenziert wird. Diese Referenz wird in der englischsprachigen Fachliteratur unwanted reference (also: ungewollte Referenz) genannt.

Bei unserem Garbage-Collection-Workshop auf der JAX 2012 tauchte im Zusammenhang mit ungewollten Referenzen die Frage auf, ob man eigentlich grundsätzlich alle Referenzen – wenn irgend möglich – „ausnullen“ solle. Der Kollege mache das grundsätzlich so – ob es sinnvoll sei. Mit „Ausnullen“ ist dabei gemeint, dass einer Referenz der Wert null zugewiesen wird; danach ist das vormals referenzierte Objekt unerreichbar. Ganz offensichtlich ist die Frage, wo und unter welchen Umständen man Variablen und Felder in Java ausnullen sollte, ein heiß diskutiertes Thema in agilen Projekten mit gemeinsamer Code-Ownership. Gehen wir der Frage also nach.

Ausnullen bei Stack-Variablen und Feldern

Beginnen wir mit dem Beispiel einer Stack-Variablen von einem Referenztyp, die in der main-Methode definiert wird. Nehmen wir einmal an, diese Stack-Variable stellt eine ungewollte Referenz dar, weil sie ab einem bestimmten Zeitpunkt im Programmablauf auf ein Objekt zeigt, das nicht mehr genutzt wird. Die Stack-Variable bewirkt, dass das referenzierte Objekt bis zur Beendigung des main-Threads (in unserem Fall: bis zum Ende des Programms) erreichbar bleibt. Der konkrete Beispielcode sieht so aus:

public static void main(String argv[]) { String argMsg = "first argument: " + argv[0]; System.out.println(argMsg); // Zeile 2  // der Rest des Programms, das noch lange laeuft }

Nach dem println() in Zeile 2 wird der über argMsg referenzierte String nicht mehr genutzt. argMsg ist also die ungewollte Referenz, die dafür sorgt, dass der referenzierte String bis zum Programmende lebt. Wie sieht nun die Situation aus, wenn wir die Variable argMsg ausnullen, nachdem wir sie in println() genutzt haben?

public stati...

Umgang mit ungewollten Referenzen: ausnullen oder nicht?

Memory Leaks: ausgenullt

Angelika Langer, Klaus Kreft


Rufen wir uns noch einmal in Erinnerung, wie es zu einem Memory Leak in Java 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 Speicher frei. Wenn wir nun auf ein Objekt verweisen, von dem wir sicher sagen können, dass wir es im weiteren Kontext unseres Programms gar nicht mehr benutzen werden, haben wir ein Memory Leak. Denn das nicht mehr benötigte Objekt wird vom Garbage Collector nicht weggeräumt, weil es noch referenziert wird. Diese Referenz wird in der englischsprachigen Fachliteratur unwanted reference (also: ungewollte Referenz) genannt.

Bei unserem Garbage-Collection-Workshop auf der JAX 2012 tauchte im Zusammenhang mit ungewollten Referenzen die Frage auf, ob man eigentlich grundsätzlich alle Referenzen – wenn irgend möglich – „ausnullen“ solle. Der Kollege mache das grundsätzlich so – ob es sinnvoll sei. Mit „Ausnullen“ ist dabei gemeint, dass einer Referenz der Wert null zugewiesen wird; danach ist das vormals referenzierte Objekt unerreichbar. Ganz offensichtlich ist die Frage, wo und unter welchen Umständen man Variablen und Felder in Java ausnullen sollte, ein heiß diskutiertes Thema in agilen Projekten mit gemeinsamer Code-Ownership. Gehen wir der Frage also nach.

Ausnullen bei Stack-Variablen und Feldern

Beginnen wir mit dem Beispiel einer Stack-Variablen von einem Referenztyp, die in der main-Methode definiert wird. Nehmen wir einmal an, diese Stack-Variable stellt eine ungewollte Referenz dar, weil sie ab einem bestimmten Zeitpunkt im Programmablauf auf ein Objekt zeigt, das nicht mehr genutzt wird. Die Stack-Variable bewirkt, dass das referenzierte Objekt bis zur Beendigung des main-Threads (in unserem Fall: bis zum Ende des Programms) erreichbar bleibt. Der konkrete Beispielcode sieht so aus:

public static void main(String argv[]) { String argMsg = "first argument: " + argv[0]; System.out.println(argMsg); // Zeile 2  // der Rest des Programms, das noch lange laeuft }

Nach dem println() in Zeile 2 wird der über argMsg referenzierte String nicht mehr genutzt. argMsg ist also die ungewollte Referenz, die dafür sorgt, dass der referenzierte String bis zum Programmende lebt. Wie sieht nun die Situation aus, wenn wir die Variable argMsg ausnullen, nachdem wir sie in println() genutzt haben?

public stati...

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