主要区别是因为咖啡因使用环形缓冲液来记录

剩余的成本是由于设计不匹配。MapMaker的原始作者热衷于将软引用作为缓存问题的解决方案，将其推迟到GC。不幸的是，虽然这在微基准测试中看起来很快，但由于导致停止世界GC抖动，它在实践中的性能很糟糕。基于大小的解决方案必须适应这项工作，这并不理想。咖啡因针对基于大小的优化，还获得了改进的哈希表，而Guava处理引用缓存更优雅。

Caffeine不会为维护或过期创建自己的线程。它确实将成本推迟到公共池，这略微提高了面向用户的延迟，但没有提高吞吐量。未来的版本可能会利用CompletableFuture. delayedExecator来安排下一个过期事件，而无需直接创建线程（适用于具有依赖于提示删除通知的业务逻辑的用户）。

并发LinkedHashMap和MapMaker是同时编写的，CLHM的性能与咖啡因相似。我相信这种差异是由于设计者喜欢和优化的场景，这影响了其他功能的实现方式。有低垂的果实可以让Guava拥有类似的性能配置文件，但没有内部冠军来推动这一点（咖啡因作为受欢迎的替代方案更是如此）。