Caffeine: multiple caffeine instances

Created on 28 Nov 2018  路  2Comments  路  Source: ben-manes/caffeine

Is caffeine a lightweight cache? Can id use multiple caffeine instances in my system , eg. hundreds?

Most helpful comment

Yes.

Caffeine is a fancy ConcurrentHashMap that includes eviction policies and other aspects towards caching. It avoids doing nasty things like creating its own threads, accessing files, registering into JMX that caching frameworks tend to do. The right way to think and use this library is that its a Map, so its familiar and just another utility like Guava. It doesn't have any additional lifecycle - it's just a ConcurrentMap.

There will be memory overhead because its ConcurrentHashMap plus additions, but we try to be kind by code generating to optimal classes for the given configuration (avoid excess per-entry fields) and lazy initializing. The space overheads, such as the LRU lists, is what you'd expect from a slightly beefier Map. The wiki page, memory overhead, provides a very rough estimate as JVM details make it inaccurate, but good enough for back-of-the-envelope discussions.

All operations are amortized O(1) time complexity, both user-facing and internal. So it will not degrade by having thousands of caches or one massive cache. Since read concurrency exceeds user needs, we steal a little overhead from it in order to utilize eviction & expiration policies that O(1) time.

I have seen successful usages with one large cache and others with thousands (e.g. per http request). A few issues here and there that we resolved, but nothing major for quite a while now.

All 2 comments

Yes.

Caffeine is a fancy ConcurrentHashMap that includes eviction policies and other aspects towards caching. It avoids doing nasty things like creating its own threads, accessing files, registering into JMX that caching frameworks tend to do. The right way to think and use this library is that its a Map, so its familiar and just another utility like Guava. It doesn't have any additional lifecycle - it's just a ConcurrentMap.

There will be memory overhead because its ConcurrentHashMap plus additions, but we try to be kind by code generating to optimal classes for the given configuration (avoid excess per-entry fields) and lazy initializing. The space overheads, such as the LRU lists, is what you'd expect from a slightly beefier Map. The wiki page, memory overhead, provides a very rough estimate as JVM details make it inaccurate, but good enough for back-of-the-envelope discussions.

All operations are amortized O(1) time complexity, both user-facing and internal. So it will not degrade by having thousands of caches or one massive cache. Since read concurrency exceeds user needs, we steal a little overhead from it in order to utilize eviction & expiration policies that O(1) time.

I have seen successful usages with one large cache and others with thousands (e.g. per http request). A few issues here and there that we resolved, but nothing major for quite a while now.

Thanks!

Was this page helpful?
0 / 5 - 0 ratings