WeakHashMap

 java.util.WeakHashMap<K, V>

下面是JDK文档中的解释。这个类简单的说就是它是Map的一个实现，特别的地方是，一个Entry是够存在，跟这个Map半毛钱关系没有。及时这个Map中引用了一个键值对，过期后，仍然会被垃圾回收期回收。对于一些缓存是很适用的。

简单的讲，由于其短暂性，很多情形会与常用的Map产生差异，需要谨慎处理。

其Entry的实现为：

private static class Entry<K,V> extends WeakReference<Object> implements Map.Entry<K,V>

Hash table based implementation ofthe Map interface, with weak keys. An entry ina WeakHashMap will automatically be removed when its key is no longerin ordinary use. More precisely, the presence of a mapping for a given key willnot prevent the key from being discarded by the garbage collector, that is,made finalizable, finalized, and then reclaimed. When a key has been discardedits entry is effectively removed from the map, so this class behaves somewhatdifferently from other Map implementations.

Both null values and the null key are supported. This class hasperformance characteristics similar to those of the HashMap class,and has the same efficiency parameters ofinitial capacity and loadfactor.

Like most collection classes, this class is not synchronized. Asynchronized WeakHashMap may be constructed using the Collections.synchronizedMap method.

This class is intended primarily for use with key objectswhose equals methods test for object identity usingthe == operator. Once such a key is discarded it can never berecreated, so it is impossible to do a lookup of that key in a WeakHashMap atsome later time and be surprised that its entry has been removed. This classwill work perfectly well with key objects whose equals methods arenot based upon object identity, such as String instances. With suchrecreatable key objects, however, the automatic removalof WeakHashMap entries whose keys have been discarded may prove to beconfusing.

The behavior of the WeakHashMap class depends in partupon the actions of the garbage collector, so several familiar (though notrequired) Map invariants do not hold for this class. Because thegarbage collector may discard keys at any time, a WeakHashMap maybehave as though an unknown thread is silently removing entries. In particular,even if you synchronize on a WeakHashMap instance and invoke none ofits mutator methods, it is possible for the size method to returnsmaller values over time, for theisEmpty method toreturn false and then true, for the containsKey methodto return true and later false for a given key, forthe get method to return a value for a given key but laterreturn null, for the put method to return null andthe remove method to return false for a key that previouslyappeared to be in the map, and for successive examinations of the key set, thevalue collection, and the entry set to yield successively smaller numbers ofelements.

Each key object in a WeakHashMap is stored indirectly asthe referent of a weak reference. Therefore a key will automatically be removedonly after the weak references to it, both inside and outside of the map, havebeen cleared by the garbage collector.

Implementation note: The value objects ina WeakHashMap are held by ordinary strong references. Thus careshould be taken to ensure that value objects do not strongly refer to their ownkeys, either directly or indirectly, since that will prevent the keys frombeing discarded. Note that a value object may refer indirectly to its key viatheWeakHashMap itself; that is, a value object may strongly refer to someother key object whose associated value object, in turn, strongly refers to thekey of the first value object. If the values in the map do not rely on the mapholding strong references to them, one way to deal with this is to wrap valuesthemselves within WeakReferences before inserting, asin: m.put(key, new WeakReference(value)), and then unwrapping uponeach get.

The iterators returned by the iterator method of thecollections returned by all of this class's "collection view methods"are fail-fast: if the map is structurally modified at any time after theiterator is created, in any way except through the iterator'sown remove method, the iterator will throw a ConcurrentModificationException.Thus, in the face of concurrent modification, the iterator fails quickly andcleanly, rather than risking arbitrary, non-deterministic behavior at anundetermined time in the future.

Note that the fail-fast behavior of an iterator cannot beguaranteed as it is, generally speaking, impossible to make any hard guaranteesin the presence of unsynchronized concurrent modification. Fail-fast iteratorsthrow ConcurrentModificationException on a best-effort basis.Therefore, it would be wrong to write a program that depended on this exceptionfor its correctness: the fail-fast behavior of iterators should be usedonly to detect bugs.

This class is a member of the Java Collections Framework.

Parameters:

<K> thetype of keys maintained by this map

<V> thetype of mapped values

Since:

1.2

Author:

DougLea

JoshBloch

MarkReinhold

See Also:

java.util.HashMap

java.lang.ref.WeakReference