11.2 Schwache Referenzen und Cleaner 
Die Referenzen auf Objekte, die wir im Alltag um uns herum haben, heißen starke Referenzen, weil die automatische Speicherbereinigung niemals ein benutztes Objekt freigeben würde. Neben den starken Referenzen gibt es jedoch auch schwache Referenzen, die es dem GC erlauben, die Objekte zu entfernen. Was erst einmal verrückt klingt, wird dann interessant, wenn es um die Implementierung von Caching-Datenstrukturen geht: Ist das Objekt im Cache, ist das schön und der Zugriff schnell; ist das Objekt nicht im Cache, dann ist das auch in Ordnung, und der Zugriff dauert etwas länger. Wir können schwache Referenzen also gut verwenden, um im Cache liegende Objekte aufzubauen, die die automatische Speicherbereinigung wegräumen darf, wenn es im Speicher knapp wird.
Schwache Referenzen interagieren also in einer einfachen Weise mit der automatischen Speicherbereinigung, und dafür gibt es im java.base-Modul im Paket java.lang.ref ein paar Typen. Es gibt spezielle Behälter, die ein Objekt referenzieren, aber von der automatischen Speicherbereinigung geleert werden können.
-
SoftReference<T>: ein Behälter für softly reachable Objekte. Die Objekte werden vom GC spät freigegeben, wenn die JVM kurz vor einem OutOfMemoryError steht.
-
WeakReference<T>: ein Behälter für weakly reachable Objekte. Die Objekte werden vom GC schon relativ früh beim ersten GC freigegeben.
-
PhantomReference<T>: ein Behälter, der immer leer ist, aber dazu dient, mitzubekommen, wenn der GC sich von einem Objekt trennt
-
Reference<T>: abstrakte Basisklasse für die »reference objects« von PhantomReference, SoftReference, WeakReference
Die Behälter selbst werden vom GC nicht entfernt und landen in einer ReferenceQueue<T>. Über die Queue lässt sich feststellen, welche Reference-Behälter leer sind und z. B. aus einer Datenstruktur entfernt werden können: Leere Behälter sind nutzlos und können nicht recycelt werden.
Ein weiterer Typ im Paket ist seit Java 9 Cleaner, der eine Alternative zur Finalisierung ist. Beim Cleaner lässt sich eine Operation (vom Typ Cleaner.Cleanable) anmelden, die immer dann aufgerufen wird, wenn die automatische Speicherbereinigung zuschlägt und das Objekt nicht mehr erreichbar ist. Intern greift die Klasse auf PhantomReference zurück.
[zB] Beispiel
Lege einen Punkt an, und registriere einen Cleaner. Rege danach durch den Gebrauch von richtig viel Speicher den GC an, der den Cleaner anstößt.
Listing 11.19 src/main/java/com/tutego/insel/lang/ref/CleanerDemo, main()
Point p = new Point( 1, 2 );
Cleaner.create().register( p, () -> System.out.println( "Punkt ist weg!" ) );
p = null;
wbyte[] bytes = new byte[ (int) Runtime.getRuntime().freeMemory() ];
Die Methode register(Object obj, Runnable action) bekommt im ersten Parameter das zu beobachtende Objekt und dann ein Runnable, wobei immer dann die run()-Methode aufgerufen wird, wenn der Cleaner aufräumt. Mit unserem Bedarf an Speicher ist daher eine Konsolenausgabe »Punkt ist weg!« wahrscheinlich. Auf keinen Fall darf die Aufräumoperation p wieder referenzieren. Auch dieses Beispiel nutzt mit dem Pfeil einen Lambda-Ausdruck, um den Code ein wenig abzukürzen.
Java ist auch eine Insel
