Abstract base class and factory for caches. A cache is a key-value mapping.
It has properties that make it more suitable for caching than a Map.
The factory methods can be used to obtain two different implementations.
They have the following properties:
. keys and values reside in memory
. keys and values must be non-null
. maximum size. Replacements are made in LRU order.
. optional lifetime, specified in seconds.
. safe for concurrent use by multiple threads
. values are held by either standard references or via SoftReferences.
SoftReferences have the advantage that they are automatically cleared
by the garbage collector in response to memory demand. This makes it
possible to simple set the maximum size to a very large value and let
the GC automatically size the cache dynamically depending on the
amount of available memory.
However, note that because of the way SoftReferences are implemented in
HotSpot at the moment, this may not work perfectly as it clears them fairly
eagerly. Performance may be improved if the Java heap size is set to larger
value using e.g. java -ms64M -mx128M foo.Test
Cache sizing: the memory cache is implemented on top of a LinkedHashMap.
In its current implementation, the number of buckets (NOT entries) in
(Linked)HashMaps is always a power of two. It is recommended to set the
maximum cache size to value that uses those buckets fully. For example,
if a cache with somewhere between 500 and 1000 entries is desired, a
maximum size of 750 would be a good choice: try 1024 buckets, with a
load factor of 0.75f, the number of entries can be calculated as
buckets / 4 * 3. As mentioned above, with a SoftReference cache, it is
generally reasonable to set the size to a fairly large value.
Abstract base class and factory for caches. A cache is a key-value mapping. It has properties that make it more suitable for caching than a Map.
The factory methods can be used to obtain two different implementations. They have the following properties:
. keys and values reside in memory
. keys and values must be non-null
. maximum size. Replacements are made in LRU order.
. optional lifetime, specified in seconds.
. safe for concurrent use by multiple threads
. values are held by either standard references or via SoftReferences. SoftReferences have the advantage that they are automatically cleared by the garbage collector in response to memory demand. This makes it possible to simple set the maximum size to a very large value and let the GC automatically size the cache dynamically depending on the amount of available memory.
However, note that because of the way SoftReferences are implemented in HotSpot at the moment, this may not work perfectly as it clears them fairly eagerly. Performance may be improved if the Java heap size is set to larger value using e.g. java -ms64M -mx128M foo.Test
Cache sizing: the memory cache is implemented on top of a LinkedHashMap. In its current implementation, the number of buckets (NOT entries) in (Linked)HashMaps is always a power of two. It is recommended to set the maximum cache size to value that uses those buckets fully. For example, if a cache with somewhere between 500 and 1000 entries is desired, a maximum size of 750 would be a good choice: try 1024 buckets, with a load factor of 0.75f, the number of entries can be calculated as buckets / 4 * 3. As mentioned above, with a SoftReference cache, it is generally reasonable to set the size to a fairly large value.
@author Andreas Sterbenz