Main public entry point for creating in-memory cache.
Default cache has no means to remove anything. It keeps entries forever (but they can be overriden)
Behavior can be customized with following options:
limit maximum number of elements to cache
once limit is reached older elements will be removed, typically using "last recently used" strategy
"ttl since update" for object in cache
Prevents from keeping stale objects in the cache
"ttl since last use"
Prevents from wasting memory on unused objects
ConcurrencyLevel hint is Guava-specific hint to guide the allowed concurrency among update operations.
Default value is 4 (for guava 13.0)
From Guava docs:
Used as a hint for internal sizing. The table is internally partitioned to try to permit the indicated number of
concurrent updates without contention. Because assignment of entries to these partitions is not necessarily uniform,
the actual concurrency observed may vary. Ideally, you should choose a value to accommodate as many threads as will
ever concurrently modify the table. Using a significantly higher value than you need can waste space and time,
and a significantly lower value can lead to thread contention. But overestimates and underestimates within an order
of magnitude do not usually have much noticeable impact. A value of one permits only one thread to modify the cache
at a time, but since read operations and cache loading computations can proceed concurrently, this still yields
higher concurrency than full synchronization.
Main public entry point for creating in-memory cache.
Default cache has no means to remove anything. It keeps entries forever (but they can be overriden)
Behavior can be customized with following options:
ConcurrencyLevel hint is Guava-specific hint to guide the allowed concurrency among update operations. Default value is 4 (for guava 13.0)
From Guava docs: Used as a hint for internal sizing. The table is internally partitioned to try to permit the indicated number of concurrent updates without contention. Because assignment of entries to these partitions is not necessarily uniform, the actual concurrency observed may vary. Ideally, you should choose a value to accommodate as many threads as will ever concurrently modify the table. Using a significantly higher value than you need can waste space and time, and a significantly lower value can lead to thread contention. But overestimates and underestimates within an order of magnitude do not usually have much noticeable impact. A value of one permits only one thread to modify the cache at a time, but since read operations and cache loading computations can proceed concurrently, this still yields higher concurrency than full synchronization.