| A hashtable-based Map implementation with soft keys.
An entry in a SoftHashMap 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.
When a key has been discarded its entry is effectively removed from the map,
so this class behaves somewhat differently than other Map
implementations.
Both null values and the null key are supported. This class has
performance characteristics similar to those of the HashMap
class, and has the same efficiency parameters of initial capacity
and load factor.
Like most collection classes, this class is not synchronized. A
synchronized SoftHashMap may be constructed using the
Collections.synchronizedMap method.
This class is intended primarily for use with key objects whose
equals methods test for object identity using the
== operator. Once such a key is discarded it can never be
recreated, so it is impossible to do a lookup of that key in a
SoftHashMap at some later time and be surprised that its entry
has been removed. This class will work perfectly well with key objects
whose equals methods are not based upon object identity, such
as String instances. With such recreatable key objects,
however, the automatic removal of SoftHashMap entries whose
keys have been discarded may prove to be confusing.
The behavior of the SoftHashMap class depends in part upon
the actions of the garbage collector, so several familiar (though not
required) Map invariants do not hold for this class. Because
the garbage collector may discard keys at any time, a
SoftHashMap may behave as though an unknown thread is silently
removing entries. In particular, even if you synchronize on a
SoftHashMap instance and invoke none of its mutator methods, it
is possible for the size method to return smaller values over
time, for the isEmpty method to return false and
then true, for the containsKey method to return
true and later false for a given key, for the
get method to return a value for a given key but later return
null, for the put method to return
null and the remove method to return
false for a key that previously appeared to be in the map, and
for successive examinations of the key set, the value set, and the entry set
to yield successively smaller numbers of elements.
Each key object in a SoftHashMap is stored indirectly as
the referent of a soft reference. Therefore a key will automatically be
removed only after the soft references to it, both inside and outside of the
map, have been cleared by the garbage collector.
Implementation note: The value objects in a
SoftHashMap are held by ordinary strong references. Thus care
should be taken to ensure that value objects do not strongly refer to their
own keys, either directly or indirectly, since that will prevent the keys
from being discarded. Note that a value object may refer indirectly to its
key via the SoftHashMap itself; that is, a value object may
strongly refer to some other key object whose associated value object, in
turn, strongly refers to the key of the first value object. One way
to deal with this is to wrap values themselves within
SoftReferences before
inserting, as in: m.put(key, new SoftReference(value)),
and then unwrapping upon each get.
version:
1.13, 02/06/02
author:
Mark Reinhold, Cédrik LIME
See Also: java.util.HashMap
See Also: java.lang.ref.SoftReference |
