Schwache Referenz

"Hallo wieder!"

„Jetzt erzähle ich Ihnen noch etwas Wunderbares: WeakReference .“

„Es sieht fast genauso aus wie SoftReference:“

// Create a Cat object
Cat cat = new Cat();

// Create a weak reference to a Cat object
WeakReference<Cat> catRef = new WeakReference<Cat>(cat);

// Now only the catRef weak reference points at the object
cat = null;

// Now the ordinary cat variable also references the object
cat = catRef.get();

// Clear the weak reference
catRef.clear();

„Eine schwache Referenz hat noch eine weitere Besonderheit.“

„Wenn ein Objekt keine gewöhnlichen Referenzen oder Soft-Referenzen, sondern nur schwache Referenzen hat, dann ist das Objekt lebendig, wird aber bei der nächsten Garbage Collection zerstört.“

„Können Sie das noch einmal sagen? Was ist der Unterschied zwischen diesen Referenzen?“

„Ein Objekt, das nur durch eine SoftReference vor dem Tod bewahrt wird, kann beliebig viele Garbage Collections überleben und wird wahrscheinlich zerstört, wenn nicht genügend Speicher vorhanden ist.“

„Ein Objekt, das nur durch eine WeakReference vor dem Tod bewahrt wird, überlebt die nächste Garbage Collection nicht. Aber bis das passiert, können Sie das Objekt erhalten, indem Sie die get()-Methode für die WeakReference aufrufen und dann seine Methoden aufrufen oder etwas anderes damit machen.“ ."

„Was ist, wenn das Objekt sowohl von einer SoftReference als auch von einer WeakReference referenziert wird?“

„Das ist ganz einfach. Wenn mindestens eine reguläre Referenz auf ein Objekt zeigt, gilt es als lebendig. Eine solche Referenz wird übrigens StrongReference genannt.“

„Wenn keine regulären Referenzen auf ein Objekt verweisen, eine SoftReference jedoch schon, dann ist es sanft erreichbar.“

„Wenn keine regulären Referenzen oder SoftReferences auf ein Objekt verweisen, eine WeakReference jedoch schon, dann ist es schwach erreichbar.“

„Denken Sie darüber nach. Eine SoftReference schützt das Objekt vor dem Löschen und stellt sicher, dass das Objekt nur gelöscht wird, wenn nicht genügend Speicher vorhanden ist. Eine WeakReference hält das Objekt bis zur nächsten Garbage Collection. Eine SoftReference bietet einen größeren Widerstand gegen das Löschen.“

„Ah. Ich glaube, ich verstehe.“

„Großartig, dann erzähle ich Ihnen von einer weiteren interessanten Sache im Zusammenhang mit WeakReferences – der WeakHashMap.“

„Klingt ernst!“

„Und noch mehr! Eine WeakHashMap ist eine HashMap, deren Schlüssel schwache Referenzen (WeakReferences) sind.“

„Das heißt, man fügt einer solchen HashMap Objekte hinzu und arbeitet mit ihnen. Business as previous.“

„Solange die Objekte, die Sie in einer WeakHashMap speichern, reguläre (starke oder weiche) Referenzen als Schlüssel haben, bleiben diese Objekte lebendig.“

„Angenommen, es gibt in der gesamten Anwendung keine Verweise mehr auf diese Objekte. Alles, was sie vor dem Aussterben bewahrt, sind ein paar WeakReferences innerhalb der WeakHashMap. Nach der nächsten Speicherbereinigung verschwinden solche Objekte aus der WeakHashMap. Von selbst. Als ob sie waren nie dort.

„Ich bin mir nicht sicher, ob ich es verstanden habe.“

„Sie speichern Objektpaare in einer WeakHashMap: einen Schlüssel und einen Wert. Die WeakHashMap verweist jedoch nicht direkt auf die Schlüssel, sondern über WeakReferences. Wenn die als Schlüssel verwendeten Objekte daher schwach erreichbar werden, werden sie beim nächsten Mal zerstört Garbage Collection. Und als Ergebnis werden ihre Werte auch automatisch aus der WeakHashMap entfernt.“

„Es ist sehr praktisch, eine WeakHashMap zu verwenden, um zusätzliche Informationen über bestimmte Objekte zu speichern.“

„Erstens ist der Zugriff auf die Informationen sehr einfach, wenn man das Objekt selbst als Schlüssel verwendet.“

„Zweitens: Wenn das Objekt zerstört wird, verschwindet es zusammen mit allen zugehörigen Daten aus der HashMap.“

"Zum Beispiel:

// Create an object to store additional information about the user
WeakHashMap<User, StatisticInfo> userStatistics = new WeakHashMap<User, StatisticInfo>();

// Put information about the user into userStatistics
User user = session.getUser();
userStatistics.put(user, new StatisticInfo (…));

// Get information about the user from userStatistics
User user = session.getUser();
StatisticInfo statistics = userStatistics.get(user);

// Remove any information about the user from userStatistics
User user = session.getUser();
userStatistics.remove(user);

1. „Innerhalb einer WeakHashMap werden Schlüssel als WeakReferences gespeichert.“
2. „Sobald das Benutzerobjekt vom Garbage Collector zerstört wird, wird die Methode „remove(user)“ implizit in der WeakHashMap aufgerufen und alle mit dem Benutzerobjekt verknüpften Informationen werden automatisch aus der WeakHashMap entfernt.“

„Das sieht nach einem leistungsstarken Werkzeug aus. Wo kann ich es verwenden?“

„Das hängt von den Umständen ab. Nehmen wir an, Sie haben einen Thread im Programm, der die Arbeit einiger Aufgaben, dargestellt durch Objekte, verfolgt und Informationen darüber in ein Protokoll schreibt. Dieser Thread könnte die überwachten Objekte in einer WeakHashMap speichern. Sobald Da die Objekte nicht benötigt werden, werden sie vom Garbage Collector gelöscht und auch die Verweise darauf werden automatisch aus der WeakHashMap entfernt.“

„Klingt interessant. Ich habe bereits das Gefühl, dass ich noch keine ernsthaften Java-Programme geschrieben habe, die solch leistungsstarke Mechanismen nutzen. Aber ich werde darauf hinarbeiten. Vielen Dank, Ellie, für diese interessante Lektion.“