Examples of org.zkoss.util.CacheMap

• org.zkoss.util.CacheMap
  The cache map. The key-to-value mappings hold in this map is temporary. They are removed when GC demanding memory and a criteria is met. The criteria is whether the mapping is old enough (called lifetime), or the upper bound is hit (called max-size).

  The criteria can be changed by overriding {@link #canExpunge}. When to check the criteria can be changed by overriding {@link #shallExpunge}.

  If the criteria is totally independent of GC, you could override {@link #newQueue} to return null. Then, {@link #shallExpunge}always returns true (rather than when GC is activated) -- of course, you could override {@link #shallExpunge}, too.

  It is different from WeakHashMap:

  • The mapping might be removed even if the key is hold somewhere (i.e., strong reachable).
  • The mapping might not be removed when GC demanding memory if the criteria doesn't meet.
  • It is not serializable.

  Like other maps, it is not thread-safe. To get one, use java.util.Collections.synchronizedMap.

  Implementation Note: there is another version of CacheMap that uses WeakReference for each value (refer to obsolete). The drawback is that all mapping will be queued and need to be examined, because GC tends to release all reference at once.

  We don't use PhantomReference because it is still required to re-create the reference after enqueued. @author tomyeh

Related Classes of org.zkoss.util.CacheMap