Jvm内部缓存选型？

使用ConcurrentHashMap作为缓存，没有淘汰功能或者手动淘汰。但是寻找效率较高，而且线程安全

可以明显看出这个存在的问题，线程不安全，需要额外加锁，功能结构单一，没有过期时间容易存在内存泄露

Guava

因为LinkedHashMap存在的问题，所以大神们在此基础上造出了Guava

既然HashMap线程不安全，那么就使用CurrentHashMap(类似不完全是)，为了实现过期那么就给数据加上时间戳标志，为了实现写后过期，读后过期，这两种配置，就使用了多条队列分别代表读和写

EHCHCHED

1. Ehcache支持持久化到本地磁盘，Guava不可以;
2. Ehcache有现成的集群解决方案，Guava没有。不过个人感觉比较鸡肋，对JVM级别的缓存来讲太重了
3. Ehcache jar包庞大，Guava Cache只是Guava jar包中的工具之一，而且后者远远小于Ehcache;
4. 两种缓存当缓存过期或者没有命中的时候都可以通过load接口重载数据，调用方式略有不同。两者的主要区别是Ehcache的缓存load的时候，允许用户返回null，而Guava Cache则不允许返回为null，因为Guava Cache是根据value的值是否为null来判断是否需要load，所以不允许返回为null，但是使用的时候可以使用空对象替换。不允许返回null是一个很好的考虑;
5. Ehcache有内存占用大小统计，Guava Cache没有，需要自己开发;
6. Ehcache在put缓存的时候，对K、V都做了包装，对GC有一定影响。

Caffeine

Caffeine是Spring 5默认支持的Cache，可见Spring对它的看重，那么Spring为什么喜新厌旧的抛弃Guava而追求Caffeine呢?

缓存的淘汰策略是为了预测哪些数据在短期内最可能被再次用到，从而提升缓存的命中率。LRU由于实现简单、高效的运行时表现以及在常规的使用场景下有不错的命中率，或许是目前最佳的实现途径。但 LRU 通过历史数据来预测未来是局限的，它会认为最后到来的数据是最可能被再次访问的，从而给与它最高的优先级。这样就意味着淘汰真正热点数据，为了解决这个问题业界运用一些数据结构上的改进巧妙的解决这个问题。

下面的内容是转载的一篇译文，如果需要查看译文原文，请点击这里,英语好的同学也可以直接查看英文原作。

缓存是提升性能的通用方法，现在大多数的缓存实现都使用了经典的技术。这篇文章中，我们会发掘Caffeine中的现代的实现方法。Caffeine是一个开源的Java缓存库，它能提供高命中率和出色的并发能力。期望读者们能被这些想法激发，进而将它们应用到任何你喜欢的编程语言中。

（编辑：孝感站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!