"Now I'm going to tell you about one more wonderful thing: WeakReference."
"It looks almost the same as 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();
"A weak reference has another special feature."
"If an object doesn't have ordinary references or soft references, but only weak references, then the object is alive, but it will be destroyed at the next garbage collection."
"Can you say that again? What's the difference between these references?"
"An object kept from death only by a SoftReference can survive as many garbage collections as you like and will probably be destroyed if there is insufficient memory."
"An object kept from death only by a WeakReference won't survive the next garbage collection. But until that happens, you can get the object by calling the get() method on the WeakReference and then call its methods or doing something else with it."
"What if the object is referenced by both a SoftReference and a WeakReference?"
"That's simple. If at least one regular reference points to an object, it is considered alive. By the way, such a reference is called a StrongReference."
"If no regular references point to an object, but a SoftReference does, then it is softly reachable."
"If no regular references or SoftReferences point to an object, but a WeakReference does, then it is weakly reachable."
"Think about it. A SoftReference protects the object from being deleted and ensures that the object will be deleted only if there is insufficient memory. A WeakReference holds the object until the next garbage collection. A SoftReference offers greater resistance to deletion."
"Ah. I think I understand."
"Great, then I'll tell you about another interesting thing involving WeakReferences — the WeakHashMap."
"And then some! A WeakHashMap is a HashMap whose keys are weak references (WeakReferences)."
"That is, you add objects to such a HashMap and work with them. Business as usual."
"As long as the objects that you store in a WeakHashMap have regular (strong or soft) references as keys, these objects will be alive."
"But suppose there are no more references to these objects in the entire application. All that keeps them from dying is a few WeakReferences inside the WeakHashMap. After the next garbage collection, such objects will disappear from the WeakHashMap. By themselves. As if they were never there."
"I'm not sure I understood."
"You store pairs of objects in a WeakHashMap: a key and a value. But the WeakHashMap doesn't reference the keys directly, but rather through WeakReferences. Therefore, when the objects used as keys become weakly reachable, they are destroyed at the next garbage collection. And as a result, their values are also automatically removed from the WeakHashMap."
"It's very convenient to use a WeakHashMap to store additional information about certain objects."
"First of all, accessing the information is very easy if you use the object itself as the key."
"Second, if the object is destroyed, it disappears from the HashMap along with all the associated data."
// 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);
- "Inside a WeakHashMap, keys are stored as WeakReferences."
- "As soon as the user object is destroyed by the garbage collector, the remove(user) method is implicitly called inside the WeakHashMap and any information associated with the user object is removed from the WeakHashMap automatically."
"This looks like a powerful tool. Where can I use it?"
"That depends on the circumstances. Let's say you have a thread in the program that tracks the work of some tasks, represented by objects, and writes information about them to a log. This thread could store the monitored objects in a WeakHashMap. As soon as the objects are not needed, the garbage collector deletes them, and the references to them are also automatically removed from the WeakHashMap."
"Sounds interesting. I already feel like I haven't yet written any serious Java programs that take advantage of such powerful mechanisms. But I'll work toward that. Thanks a lot, Ellie, for such an interesting lesson."