What is weak reference
So let’s start with weak reference.
Weak reference get this name compared with the normal reference, which is also called strong reference. Weak reference is weak enough, and can’t retain the object it refer to in the memory. But why we need a reference when we can’t guarantee we can reach this object?
Here is an example from this post:
suppose we find ourselves needing to keep track of each Widget’s serial number, but the Widget class doesn’t actually have a serial number property – and because Widget isn’t extensible, we can’t add one. No problem at all, that’s what HashMaps are for:
serialNumberMap.put(widget, widgetSerialNumber);
This might look okay on the surface, but the strong reference to widget will almost certainly cause problems. We have to know (with 100% certainty) when a particular Widget’s serial number is no longer needed, so we can remove its entry from the map. Otherwise we’re going to have a memory leak (if we don’t remove Widgets when we should) or we’re going to inexplicably find ourselves missing serial numbers (if we remove Widgets that we’re still using).
More
At previous part, we just mention ‘weak reference’. Actually, ‘weak reference’ has three different kinds(level), from stronger to weaker: soft, weak, phantom, and we will describe it now.
Soft vs Weak
SoftReferences aren’t required to behave any differently than WeakReferences, but in practice softly reachable objects are generally retained as long as memory is in plentiful supply. This makes them an excellent foundation for a cache, since you can let the garbage collector worry about both how reachable the objects are (a strongly reachable object will never be removed from the cache) and how badly it needs the memory they are consuming.
Weak vs Phantom
in theory the object could even be “resurrected” by an unorthodox finalize() method, but the WeakReference would remain dead. The difference is in exactly when the enqueuing happens. WeakReferences are enqueued as soon as the object to which they point becomes weakly reachable. This is before finalization or garbage collection has actually happened. PhantomReferences are enqueued only when the object is physically removed from memory, and the get() method always returns null specifically to prevent you from being able to “resurrect” an almost-dead object.
Usage
An example of weak reference in java library is WeakHashMap. Let’s dive into source to see how it is implemented and how it is related with weak reference.
WeakHashMap: who is weak
From document:
Hash table based implementation of the Map interface, with weak keys.
And the source code of WeakHashMap:
private static class Entry<K,V> extends
WeakReference<Object> implements Map.Entry<K,V> {
V value;
final int
Entry<K,V> next;
Entry(Object key, V value,
ReferenceQueue<Object> queue,
int hash, Entry<K,V> next) {
super(key, queue); // <-------------
// **here we send key to WeakReference**
this.value = value;
this.hash = hash;
this.next = next;
}
//...
}
So this clear some misunderstanding of WeakHashMap: key is weakly reached, not value. In other word, when key is a large class and may cause memory leak, you may need WeakHashMap. And If your value is your worry, you have to do it yourself:
HashMap<K,WeakReference<V>>
or use library like Guava:
ConcurrentMap<Long, CustomObject> graphs = new MapMaker()
.weakValues()
.makeMap();
What happen when key is reclaimed by GC
As the document say:
An entry in a WeakHashMap will automatically be removed when its key is no longer in ordinary use. More precisely, the presence of a mapping for a given key will not prevent the key from being discarded by the garbage collector, that is, made finalizable, finalized, and then reclaimed.
What the doc mean is that entry will be set null to make it available for GC.
And the source of function expungeStaleEntries():
for (Object x; (x = queue.poll()) != null; ) {
synchronized (queue) {
@SuppressWarnings("unchecked")
Entry<K,V> e = (Entry<K,V>) x;
int i = indexFor(e.hash, table.length);
Entry<K,V> prev = table[i];
Entry<K,V> p = prev;
while (p != null) {
Entry<K,V> next = p.next;
if (p == e) {
if (prev == e)
table[i] = next;
else
prev.next = next;
// Must not null out e.next;
// stale entries may be in use
// by a HashIterator
e.value = null; // Help GC
size--;
break;
}
prev = p;
p = next;
}
}
}
This code will be called when resize()/size() related job is needed.
A code snippet of code tuning in it
In the hash-based map implementation, we can find a snippet of conversion from hash code to table index as following:
/**
* Returns index for hash code h.
*/
private static int indexFor(int h, int length) {
return h & (length-1);
}
Here, we can see that they use length-1 & hash to calculate the position of a new node. In our algorithm course, we can learn that we spread the element into a array-based hash-table by hash % n. So why we can replace it with & (which is more efficient than %)?
We take some number to test it:
| n | hash | n-1 & hash | hash % n |
|---|---|---|---|
| 10 | 11 | 9 | 1 |
| 10 | 12 | 8 | 2 |
| 10 | 13 | 9 | 3 |
It seems that they are not same or even equivalent at all? Take a close look at the source code, we learn that n in xxxHashMap is always the power of 2 and n-1 & hash == hash % n will always be true.
Maybe this is the reason of choosing 2^n as length, not as some general algorithms suggest using prime number.
Usage of WeakHashMap
TheadLocal implementation also rely on this: every thread has a ThreadLocalMap which is actually a WeakHashMap<ThreadLocal<?>, Object> to store every thread’s variable. After your program doesn’t hold a reference to your ThreadLocal<?> variable, it will be recycled soon even your thread is still running. In that case, variable will not retain in memory to cause memory leaking and no need to worry about it for programmers.
Ref
Written with StackEdit.
评论
发表评论