咖啡因与番石榴缓存 [英] Caffeine versus Guava cache
问题描述
实现咖啡因的秘密是什么？
我是正确的，如果超时，Caffeine使用预定的执行程序在后台执行适当的维护操作？我是正确的吗？
主要区别在于，咖啡因使用环形缓冲区来记录&重播事件，而Guava使用 ConcurrentLinkedQueue 。目的总是要迁移番石榴，并且开始更简单是有意义的，但是不幸的是，从来没有兴趣接受这些更改。环形缓冲区方法避免了分配，有界（有损）并且操作起来更便宜。 MapMaker 的原始作者热衷于将软引用作为解决问题的解决方案，方法是将其推迟到GC。不幸的是，尽管在微基准测试中看似很快，但由于引起了世界各地的GC颠簸，它在实践中的性能令人震惊。基于大小的解决方案必须适应这项工作，这并不理想。 Caffeine针对基于大小的内容进行优化，并且还获得了改进的哈希表，而Guava则更优雅地处理了引用缓存。
Caffeine不会创建自己的线程来进行维护或到期。它确实将成本推迟到 commonPool ，这会稍微提高面向用户的延迟，但不会提高吞吐量。将来的版本可能会利用 CompletableFuture.delayedExecutor 安排下一个到期事件，而无需直接创建线程（对于具有业务逻辑的用户，这取决于迅速删除通知）。
ConcurrentLinkedHashMap 和 MapMaker 是同时编写的，并且CLHM的性能相似咖啡因。我相信差异是由于设计人员偏爱和优化了哪些方案而影响了其他功能的实现方式。垂死挣扎的水果可以使番石榴具有类似的性能表现，但没有一个内部冠军能做到这一点（以咖啡因为首选替代品更是如此）。
According to these micro benchmarks it turns out that Caffeine is a way faster than Guava cache in both read and write operations.
What is the secret of Caffeine implementation? How it differs from the Guava Cache?
Am I right that in case of timed expiration Caffeine use a scheduled executor to perform appropriate maintenance operations in background?
The main difference is because Caffeine uses ring buffers to record & replay events, whereas Guava uses ConcurrentLinkedQueue. The intent was always to migrate Guava over and it made sense to start simpler, but unfortunately there was never interest in accepting those changes. The ring buffer approach avoids allocation, is bounded (lossy), and cheaper to operate against.
The remaining costs are due to a design mismatch. The original author of MapMaker was enthusiastic about soft references as the solution to caching problems by deferring it to the GC. Unfortunately while that can seem fast in microbenchmarks, it has horrible performance in practice due to causing stop-the-world GC thrashing. The size-based solution had to be adapted into this work and that is not ideal. Caffeine optimizes for size-based and also gains an improved hash table, whereas Guava handles reference caching more elegantly.
Caffeine doesn't create its own threads for maintenance or expiration. It does defer the cost to the commonPool, which slightly improves user-facing latencies but not throughput. A future version might leverage CompletableFuture.delayedExecutor to schedule the next expiration event without directly creating threads (for users who have business logic depending on prompt removal notifications).
ConcurrentLinkedHashMap and MapMaker were written at the same time and CLHM has similar performance to Caffeine. I believe the difference is due to what scenarios the designers favored and optimized for, which impacted how other features would be implemented. There is low hanging fruit to allow Guava to have similar performance profile, but there isn't an internal champion to drive that (and even less so with Caffeine as a favored alternative).
这篇关于咖啡因与番石榴缓存的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
