When would you use a WeakHashMap or a WeakReference?

Question

The use of weak references is something that I've never seen an implementation of so I'm trying to figure out what the use case for them is and how the implementation would work. When have you needed to use a WeakHashMap or WeakReference and how was it used?

Archiepiscopal

Related Question with good answers: Why do we need weak reference in java and What's the difference between SoftReference and WeakReference in Java? – Arboriculture

Similar: Usage of WeakHashMap? – Arboriculture

Answer 1

One problem with strong references is caching, particular with very large structures like images. Suppose you have an application which has to work with user-supplied images, like the web site design tool I work on. Naturally you want to cache these images, because loading them from disk is very expensive and you want to avoid the possibility of having two copies of the (potentially gigantic) image in memory at once.

Because an image cache is supposed to prevent us from reloading images when we don't absolutely need to, you will quickly realize that the cache should always contain a reference to any image which is already in memory. With ordinary strong references, though, that reference itself will force the image to remain in memory, which requires you to somehow determine when the image is no longer needed in memory and remove it from the cache, so that it becomes eligible for garbage collection. You are forced to duplicate the behavior of the garbage collector and manually determine whether or not an object should be in memory.

Understanding Weak References, Ethan Nicholas

Heyes

Wouldn't SoftReferences be better in this case, i.e. references which are only collected when memory starts running out. – Sero

I'm a bit confused... let's say that i have a SWT Image cache. SWT images need to be DISPOSED through the dispose() method to release SO Resources. If i use a WeakHashMap to store them, show exactly will the GC dispose the object? – Boney

@Boney the GC would use a finalizer on any other object. It seems like SWT doesn't like it when you do that, so I don't think you can manage operating system resources with a WeakHashMap. – Heyes

@marcolopes, (I'll assume that your GC guarantees a call to finalize before it reclaims memory.) If dispose is done in the cache finalizer, all is well. If dispose is something you have to manually call, then either 1) extend the class and put dispose in the finalizer, or 2) use phantomreference to track and run dispose accordingly. Option 2 is better (avoids resurrection bugs, and gives you the ability to run dispose on another thread), but option 1 is easier to implement without helperclasses. – Debris

Article now at web.archive.org/web/20061130103858/http://weblogs.java.net/blog/… – Hurricane

I think WeakReferences and SoftReferences are too non-deterministic to be useful for general purpose caches. What GC strategy you use would severely affect the behavior of your cache. So this approach doesn't seem to be very useful. – Alforja

Answer 2

WeakReference versus SoftReference

One distinction to be clear on is the difference between a WeakReference and a SoftReference.

Basically a WeakReference will be GC-d by the JVM eagerly, once the referenced object has no hard references to it. A SoftReferenced object on the other hand, will tend to be left about by the garbage collector until it really needs to reclaim the memory.

A cache where the values are held inside WeakReferences would be pretty useless (in a WeakHashMap, it is the keys which are weakly referenced). SoftReferences are useful to wrap the values around when you want to implement a cache which can grow and shrink with the available memory.

Doting

"A cache where the values are held inside WeakReferences would be pretty useless" I totally disagree. – Paganism

@trinithis - erm, I don't really know what to say. Why is a cache whose values disappear the moment you are not referencing them a useful thing, exactly? – Doting

For something like memoization, a cache that loosely holds its cached values could be useful. – Paganism

@ThomasEding I still don't get it. The only time a cache seems useful is when there are no other references to it... If you have references to it, what do you need a cache for? – Assignment

@ThomasEding, Softref tells the environment "store this until you have no memory". Weakref tells the environment "store this until GC runs". There is frankly no use case for weakref unless you are debugging/profiling the GC itself. If you want a memory-sensitive cache, use softref. If you don't want a cache, then don't cache it! Where does weakref come in? – Debris

On the other hand, a jvm may not treat weakref as "store this until GC runs", but "store this until you have no memory, taking into account the memory softref needs". In such a jvm then, weakref is simply softref-level-2. In other words, its a hackish way of getting such a jvm to doing softref leveling for you so that you don't have to implement the softref leveling code yourself. But once you need more than 2 levels of softref, you would still have to write the code yourself. – Debris

@Pacerier: I had no idea SoftReferences exist. They seem much more useful. – Paganism

@Assignment "If you have references to it, what do you need a cache for?" So other places in code can easily look up the same thing. Say I've got an image on disk, one that might be used in several different particle systems, systems that don't know about each other.... loose coupling. But you could keep such images in a cache based on their file path for example. – Skyway

@Pacerier: I still don't see a problem with WeakHashMap as a cache. Enlighten me. Java lacks C++ destructors and rigid object lifetime control (a feature, it eliminates a class of bugs, memory leaks (or at least makes them rarer))... but that can make cleanup of things not directly handled by GC error prone. Weak/Soft reference-based caches too seem to eliminate a (much smaller) class of bugs. Wherein lies the problem? – Skyway

There is nothing wrong with WeakHashMap as a cache - who said that there was? – Doting

Answer 3

One Common use of WeakReferences and WeakHashMaps in particular is for adding properties to objects. Occasionally you want to add some functionality or data to an object but subclassing and/or composition are not an option in that case the obvious thing to do would be to create a hashmap linking the object you want to extend to the property you want to add. then whenever you need the property you can just look it up in the map. However, if the objects you are adding properties to tend to get destroyed and created a lot, you can end up with a lot of old objects in your map taking up a lot of memory.

If you use a WeakHashMap instead the objects will leave your map as soon as they are no longer used by the rest of your program, which is the desired behavior.

I had to do this to add some data to java.awt.Component to get around a change in the JRE between 1.4.2 and 1.5, I could have fixed it by subclassing every component I was interested int (JButton, JFrame, JPanel....) but this was much easier with much less code.

Stefaniestefano

how does the WeakHashMap know "they are no longer used by the rest of your program"? – Snitch

A weak hasmap uses weak references for its keys. When an object is only referenced through weak references the garbage collector will 'notify' the owner of the weak reference (in this case the WeaHashMap). I would read up on WeakReferences and ReferenceQueues in the javadocs to understand how these objects interact with the garbage collector. – Stefaniestefano

thanks luke, can you provide simple code for you obove description? – Batista

Thus, weakreference only makes sense in Java because of Java's quirky API where some classes cannot be extended. – Debris

Answer 4

Another useful case for WeakHashMap and WeakReference is a listener registry implementation.

When you create something which wants to listen to certain events, usually you register a listener, e.g.

manager.registerListener(myListenerImpl);

If the manager stores your listener with a WeakReference, that means you don't need to remove the register e.g. with a manager.removeListener(myListenerImpl) because it will be automatically removed once your listener or your component holding the listener becomes unavailable.

Of course you still can manually remove your listener, but if you don't or you forget it, it will not cause a memory leak, and it will not prevent your listener being garbage collected.

Where does WeakHashMap come into the picture?

The listener registry which whishes to store registered listeners as WeakReferences needs a collection to store these references. There is no WeakHashSet implementation in the standard Java library only a WeakHashMap but we can easily use the latter one to "implement" the functionality of the first one:

Set<ListenerType> listenerSet =
    Collections.newSetFromMap(new WeakHashMap<ListenerType, Boolean>());

With this listenerSet to register a new listener you just have to add it to the set, and even if it is not removed explicitly, if the listener is no longer referenced, it will be removed automatically by the JVM.

Hereinafter

The problem with using weakHashSets for listener list is that anonymous listener instances created in register() will be lost easily, which would be unexpected by the user. It is safer to hold stronger references to listeners from managers instead, and rely on caller to do the right thing instead. – Typo

For listener registry implementation : All registered listeners will be collected/destroyed on next GC kick ? For example, while firing all listener's onSomethingHappened() method, what happens if GC kicked ? – Basque

@icza, I can't believe people are still peddling this myth. This is a completely wrong answer. You might as well say another useful case for WeakHashMap is whenever you need a HashMap of objects. So wow you don't have to manually do hashmap.remove ever because items are automagically removed once the obj is out of scope! Literally magic! Such an ugly magic hack is a complete facepalm. – Debris

@Pacerier: I've followed your links from other comments in JavaScript land all the way down here, and still not quite understand why listener registry implementation with WeakMap is a myth. For example, if WebSocket clients should be bound with some listeners on them via registry service, it seems logical to store socket objects as a keys in WeakMap (to prevent them from hanging in memory after connection close, say, on error) and being able to retrieve all their listeners if needed. So, could you please state, what is exactly wrong with that approach? – Vd

@Debris I too fail to understand your objection. In a Publish-Subscribe or Event Bus scenario, a collection of weak references makes perfect sense to me. The subscribing object is permitted to go out of scope and head to garbage collection without any need to formally unsubscribe. That process of unsubscribing can be especially complicated if a third-party object was responsible for the initial subscription without the subscribing object’s knowledge. A collection of WeakReference greatly simplifies the code base and avoids needless bugs related to failing to unsubscribe. What downside? – Arboriculture

@Debris wat about creating a strong reference to the anonimous or missing observer if still exists before calling it?, it should fix the bug of immediatly calling them after a tick or similar case – Redwing

Answer 5

This blog post demonstrates the use of both classes: Java: synchronizing on an ID. The usage goes something like this:

private static IdMutexProvider MUTEX_PROVIDER = new IdMutexProvider();

public void performTask(String resourceId) {
    IdMutexProvider.Mutex mutext = MUTEX_PROVIDER.getMutex(resourceId);
    synchronized (mutext) {
        // look up the resource and do something with it
    }
}

IdMutextProvider provides id-based objects to synchronize on. The requirements are:

• must return a reference to the same object for concurrent use of equivalent IDs
• must return a different object for different IDs
• no release mechanism (objects are not returned to the provider)
• must not leak (unused objects are eligible for garbage collection)

This is achieved using an internal storage map of type:

WeakHashMap<Mutex, WeakReference<Mutex>>

The object is both key and value. When nothing external to the map has a hard reference to the object, it can be garbage collected. Values in the map are stored with hard references, so the value must be wrapped in a WeakReference to prevent a memory leak. This last point is covered in the javadoc.

Toreutics

Answer 6

If you for example want to keep track of all objects created of a certain class. To still allow these objects to be garbage collected, you keep a list/map of weak references to the objects instead of the objects themselves.

Now if someone could explain phantom-references to me, I'd be happy...

Sero

One use: PhantomReferences allow you to determine exactly when an object was removed from memory. They are in fact the only way to determine that. (weblogs.java.net/blog/enicholas/archive/2006/05/…) – Heyes

Actually it's not removed until you explicitly clear it. "Unlike soft and weak references, phantom references are not automatically cleared by the garbage collector as they are enqueued. An object that is reachable via phantom references will remain so until all such references are cleared or themselves become unreachable." – Gash

@jontro, But it has already been finalized, all members are gone. Effectively, it's a blank obj. See https://mcmap.net/q/75955/-why-are-phantom-references-not-cleared-as-they-are-enqueued/632951 – Debris

Answer 7

As stated above, weak reference are held for as long as a strong reference exists.

An example usage would be to use WeakReference inside listeners, so that the listeners are no longer active once the main reference to their target object is gone. Note that this does not mean the WeakReference is removed from the listeners list, cleaning up is still required but can be performed, for example, at scheduled times. This has also the effect of preventing the object listened to from holding strong references and eventually be a source of memory bloat. Example: Swing GUI components refering a model having a longer lifecycle than the window.

While playing with listeners as described above we rapidly realised that objects get collected "immediately" from a user's point of view.

Prescript

Thanks useful answer. But i'm wondering, in that case, should listeners be registered(referenced) strongly ? – Basque

This answer is completely wrong. Elaboration: #155224 – Debris

@Debris - for WeakReferences your comment is completely wrong! – Arabian

Answer 8

One real world use I had for WeakReferences is if you have a single, very large object that's rarely used. You don't want to keep it in memory when it's not needed; but, if another thread needs the same object, you don't want two of them in memory either. You can keep a weak reference to the object somewhere, and hard references in the methods that use it; when the methods both finish, the object will be collected.

Steel

This is a softreference, not a weakreference. See https://mcmap.net/q/74967/-when-would-you-use-a-weakhashmap-or-a-weakreference – Debris

Answer 9

I did a google code search for "new WeakHashMap()".

I got a bunch of matches from the GNU classpath project and

1. Apache xbean Project : WeakHashMapEditor.java
2. Apache Lucene project : CachingWrapperFilter.java

Wikiup

Answer 10

you can use weakhashmap to implement a resource-free caching for expansive object creation.

but note that it is not desireable to have mutable objects. i used it to cache query results (which take about 400 ms to execute) to a text-search engine, which is rarely updated.

Jase

You're talking about a softreference, not a weakreference. See https://mcmap.net/q/74967/-when-would-you-use-a-weakhashmap-or-a-weakreference – Debris