A high performance caching library for Java (by ben-manes)

Caffeine Alternatives

Similar projects and alternatives to Caffeine

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a better Caffeine alternative or higher similarity.

Suggest an alternative to Caffeine

Caffeine reviews and mentions

Posts with mentions or reviews of Caffeine. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2022-08-16.
  • DragonFlydb: Cache Design
    3 projects | | 16 Aug 2022
    It is handled by W-TinyLFU where I use this scenario as a stress test [1]. While LIRS / LIRS2 did not pass this one scenario, the quality of the work behind that policy leads me to believe it could be improved to handle that case.


  • Ask HN: What are some 'cool' but obscure data structures you know about?
    54 projects | | 21 Jul 2022
    Yeah, saves you from thundering herd problems cache does something similar by caching the future that gets returned on look-ups if the value is still being computed

  • Can someone please eli5 how the hierarchical timing wheel algorithm works?
    3 projects | | 6 Jul 2022
    I briefly described the algorithm in this article and there is a wonderful article from Kafka that goes into more depth in their general purpose implementation. My implementation is specialized and over optimized in comparison, e.g. by using bit manipulation to avoid more expensive division/modulus instructions. Tokio rewrote their timerwheel after I showed them mine, borrowing some ideas but also staying more general. Hope that helps!
  • Gradle announces Predictive Test Selection: ML for JVM-based tests
    1 project | | 19 Apr 2022
    Caffeine runs 8.9 million tests per build matrix item (jdk 11, 17, 17-arm64). It would be neat to see what a predicted run is for use on dev branches (e.g. => master).
  • Dynamic Debug Logging
    3 projects | | 16 Apr 2022
    The refresh is asynchronous in the background and has an "assumed valid" interval after it refreshes, i.e. on a refresh, it serves from cache for the next 5 minutes before the next refresh. It's sort of like stale-while-revalidate in HTTP caching.
  • Question on performance with tile-based graphics.
    2 projects | | 13 Apr 2022
    I recommend Caffeine if you don't want to do the timed hashmap implementation yourself. ( But, it's plenty easy to do.
  • Writing a concurrent LRU cache
    11 projects | | 10 Dec 2021
    oh, I see. Thanks for the clarification. The use of an access log is still quite similar to bp-wrapper. My implementation varies from their paper as well, but the core observation between all of ours is the same. I use lock-free multi-producer / single-consumer bounded ring buffers (not too dissimilar crossbeam's ArrayQueue). This is dynamically striped by the thread's id and scales linearly at ~33% of the underling concurrent hash table (so 380M ops/s on a 2015 16-core server vs 1.18B raw).
    11 projects | | 10 Dec 2021
    The access log idea seems to be a variation of bp-wrapper, as discussed in the original post. It's a neat trick to invert that as an exclusive filter rather than event replay. But as you said duplicate events causes the capacity to vary, so you are only trying to retain the hottest entries as they will be the most popular. This has the unfortunate effect of coupling the concurrency model to the policy, and in many important workloads we know that LRU under performs. I think using it as an event replay is more robust, and shouldn't be that different from your code as is. I would also warn against making performance predictions without benchmarks, because very minor mistakes can trash the results so it is best to be conservatively optimistic and scrutinize good performance for benchmark mistakes.
    11 projects | | 10 Dec 2021
    Ya, I saw concache but I looked into it and it doesn't implement what is needed. Each bucket has its own linked-list backing (hence "lock-free linked list buckets"). An LRU needs each value in each bucket to be part of one linked list I believe. After posting this I realized my line of research was failing because it was state of the art five years ago. Caffeine replaced `concurrentlinkedhashmap` in the java world (by the same author). A rust version of that is Moka. These are much more complicated than a concurrent LRU but faster (aka more state of the art). Another rust crate is Stretto which is a port of dgraph's Ristretto (in go). The question becomes is it worth it to essentially port `concurrentlinkedhashmap` to have a great concurrent LRU when there are more state of the art caches out there.
  • go-generics-cache: An in-memory key:value store/cache library for Go Generics
    9 projects | | 16 Nov 2021
    For anything cache related, I usually refer to Caffeine from java and its closest relative in go:
  • Show HN: Caffeine, minimum viable back end for prototyping
    9 projects | | 16 Nov 2021
    And also a (very efficient) Java cache library
  • A list of Java cache providers
    3 projects | | 31 Oct 2021
    Caffeine: W-TinyLFU
  • A list of cache providers
    1 project | | 31 Oct 2021
    Caffeine is a high performance, near optimal caching library. For more details, see our user’s guide and browse the API docs for the latest release.
  • Reassessing TestNG vs. Junit
    6 projects | | 20 Sep 2021
    Looking at OpenJDK's Vector testing and it seems to have a lot of duplication. A powerful feature of TestNG/JUnit5 is that you can control the data provider by inspecting the method's metadata and attach listeners to perform common validation. Caffeine runs millions of test cases by using an @CacheSpec annotation, providing the data param and a context object (example, and a cross-test validation listener. The specification constraint runs the test for every configuration, OpenJDK has a custom codegen template which loses all tooling support. From a brief glance through your usages, I believe you could get a much better QoL by using some of the advanced techniques in either framework.
  • Cache your JHipster with Caffeine
    3 projects | | 13 Aug 2021
    Learn more at


Basic Caffeine repo stats
3 days ago

ben-manes/caffeine is an open source project licensed under Apache License 2.0 which is an OSI approved license.

SaaSHub - Software Alternatives and Reviews
SaaSHub helps you find the best software and product alternatives
Find remote jobs at our new job board There are 3 new remote jobs listed recently.
Are you hiring? Post a new remote job listing for free.