咖啡因与番石榴缓存

Question

根据这些微型基准，事实证明，在读取和写入操作中，咖啡因的速度都比Guava缓存快。

咖啡因实施的秘密是什么？它与Guava缓存有何不同？

我是否可以在咖啡因定时过期的情况下使用预定的执行程序在后台执行适当的维护操作？

Answer 1

主要区别在于，咖啡因使用环形缓冲区来记录和重播事件，而番石榴则使用ConcurrentLinkedQueue。目的总是要迁移番石榴，并且开始更简单是有道理的，但是不幸的是，从来没有兴趣接受这些更改。环形缓冲区方法避免了分配，是有界的（有损），并且操作起来更便宜。

剩余成本是由于设计不匹配造成的。的原始作者MapMaker热衷于将软引用作为将缓存问题提交给GC的解决方案。不幸的是，尽管在微基准测试中看似很快，但由于引起了世界各地的GC颠簸，它在实践中的性能令人震惊。基于大小的解决方案必须适应这项工作，这并不理想。咖啡因针对基于大小的文件进行了优化，并且还获得了改进的哈希表，而番石榴则更优雅地处理了引用缓存。

咖啡因不会创建自己的线程来进行维护或到期。确实将成本降低了commonPool，这会稍微提高面向用户的延迟，但不会提高吞吐量。将来的版本可能会利用它CompletableFuture.delayedExecutor来调度下一个到期事件，而无需直接创建线程（对于具有业务逻辑的用户，取决于提示删除通知）。

ConcurrentLinkedHashMap并且MapMaker是同时编写的，CLHM与咖啡因的性能相似。我相信差异是由于设计人员偏爱和优化了哪些方案而影响了其他功能的实现方式。垂死挣扎的水果可以使番石榴具有类似的性能，但没有一个内部冠军可以推动这一发展（以咖啡因为首选替代品更是如此）。