「lru缓存java」java缓存技术 redis

博主：adminadmin 2023-03-21 06:41:10 579

今天给各位分享lru缓存java的知识，其中也会对java缓存技术 redis进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

Redis的缓存淘汰策略LRU与LFU

Redis缓存淘汰策略与Redis键的过期删除策略并不完全相同，前者是在Redis内存使用超过一定值的时候（一般这个值可以配置）使用的淘汰策略；而后者是通过定期删除+惰性删除两者结合的方式淘汰内存过期键的。

这里参照官方文档的解释重新叙述一遍过期删除策略：当某个key被设置了过期时间之后，客户端每次对该key的访问（读写）都会事先检测该key是否过期，如果过期就直接删除；但有一些键只访问一次，因此需要主动删除，默认情况下redis每秒检测10次，检测的对象是所有设置了过期时间的键集合，每次从这个集合中随机检测20个键查看他们是否过期，如果过期就直接删除，如果删除后还有超过25%的集合中的键已经过期，那么继续检测过期集合中的20个随机键进行删除。这样可以保证过期键最大只占所有设置了过期时间键的25%。

在Java中LRU的实现方式是使用HashMap结合双向链表，HashMap的值是双向链表的节点，双向链表的节点也保存一份key value。

LFU是在Redis4.0后出现的，LRU的最近最少使用实际上并不精确，考虑下面的情况，如果在|处删除，那么A距离的时间最久，但实际上A的使用频率要比B频繁，所以合理的淘汰策略应该是淘汰B。LFU就是为应对这种情况而生的。

Spring本地缓存的使用方法

我们现在在用的Spring Cache，可以直接看Spring Boot提供的缓存枚举类，有如下这些：

EhCache：一个纯Java的进程内缓存框架，所以也是基于本地缓存的。(注意EhCache2.x和EhCache3.x相互不兼容)。

Redis：分布式缓存，只有Client-Server(C\S)模式，Java一般使用Jedis/Luttuce来操纵。

Hazelcast：基于内存的数据网格。虽然它基于内存，但是分布式应用程序可以使用Hazelcast进行分布式缓存、同步、集群、处理、发布/订阅消息等。

Guava：它是Google Guava工具包中的一个非常方便易用的本地化缓存实现，基于LRU（最近最少使用）算法实现，支持多种缓存过期策略。在Spring5.X以后的版本已经将他标记为过期了。

Caffeine：是使用Java8对Guava缓存的重写版本，在Spring5中将取代了Guava，支持多种缓存过期策略。

SIMPLE：使用ConcurrentMapCacheManager，因为不支持缓存过期时间，所以做本地缓存基本不考虑该方式。

关于分布式缓存，我们需要后面会专门讨论Redis的用法，这里只看本地缓存。性能从高到低，依次是Caffeine，Guava，ConcurrentMapCacheManager，其中Caffeine在读写上都快了Guava近一倍。

这里我们只讨论在Spring Boot里面怎么整合使用Caffeine和EhCache。

主要有以下几个步骤：

1)加依赖包：

2)配置缓存：

这里有两种方法，通过文件配置或者在配置类里面配置，先看一下文件配置，我们可以写一个properties文件，内容像这样：

然后还要在主类中加上@EnableCaching注解：

另外一种更灵活的方法是在配置类中配置：

应用类：

测试类：

导入依赖包，分为2.x版本和3.x版本。

其中2.x版本做如下导入：

3.x版本做如下导入：

导包完成后，我们使用JCacheManagerFactoryBean + ehcache.xml的方式配置：

参考资料：

LRU缓存机制的实现

leetcode 146.

LRU(Least Recently Used)是一种缓存替换策略。现实生活中，缓存的大小总是有限的，为了合理地利用缓存，在缓存满了以后需要利用合适的替换策略把某些内容从缓存中移出，以腾出空间给新的元素。LRU就是其中一种常见的策略，它把缓存中最不常访问到的数据移出。

为了实现LRU，可以利用哈希表+双向链表。哈希表以键值对的形式保存元素，并以O(1)的时间复杂度取出元素；双向链表用于记录每个元素的使用情况。具体如下：

参考：

[1]

Java有哪些值得推荐的，好用优秀的第三方库

1. log4j

理由：向system.out.println()说永别，刚开始学java的时候总是喜欢依靠system.out.println()的输出来查看异常和调试。后来工作后就果断log4j了，这样项目开发和发布的时候，可以根据自己的需求开关日志级别，把日志打印到远程服务等多种功能。现在这个基本成为标配了。

2.guava

google出品的第三方工具库。当java.util 提供的数据结构不能满足的时候从这里你可以快速找到大量已经写好的数据结构了，这使得你不用花费心思在一些常用的数据结构上了。比如LRU缓存之类的。只是好几个版本的跨度比较大，兼容也不怎么好。

java为什么使用缓存实现抢答

您是否在询问为什么使用缓存，缓存是用来存储数据的。

FIFO先入先出，很好理解，就和队列一样，先进队列的先出队列，LRU 最近最少使用，意思就是最近读取的数据放在最前面，最早读取的数据放在最后面，如果这个时候有新的数据进来，那么最后面存储的数据淘汰，LFU最不常使用，意思就是对存储的数据都会有一个计数引用，然后队列按数据引用次数排序，引用数多的排在最前面，引用数少的排在后面。如果这个时候有新的数据进来，把最后面的数据删除，把新进数据排在最后面，且引用次数为1。

java web开发缓存方案，ehcache和redis哪个更好

Ehcache

在java项目广泛的使用。它是一个开源的、设计于提高在数据从RDBMS中取出来的高花费、高延迟采取的一种缓存方案。正因为Ehcache具有健壮性（基于java开发）、被认证（具有apache 2.0 license）、充满特色（稍后会详细介绍），所以被用于大型复杂分布式web application的各个节点中。

1. 够快

Ehcache的发行有一段时长了，经过几年的努力和不计其数的性能测试，Ehcache终被设计于large, high concurrency systems.

2. 够简单

开发者提供的接口非常简单明了，从Ehcache的搭建到运用运行仅仅需要的是你宝贵的几分钟。其实很多开发者都不知道自己用在用Ehcache，Ehcache被广泛的运用于其他的开源项目

比如：hibernate

3.够袖珍

关于这点的特性，官方给了一个很可爱的名字small foot print ，一般Ehcache的发布版本不会到2M，V 2.2.3 才 668KB。

4. 够轻量

核心程序仅仅依赖slf4j这一个包，没有之一！

5.好扩展

Ehcache提供了对大数据的内存和硬盘的存储，最近版本允许多实例、保存对象高灵活性、提供LRU、LFU、FIFO淘汰算法，基础属性支持热配置、支持的插件多

6.监听器

缓存管理器监听器 （CacheManagerListener）和 缓存监听器（CacheEvenListener）,做一些统计或数据一致性广播挺好用的

如何使用？

够简单就是Ehcache的一大特色，自然用起来just so easy!

redis

redis是在memcache之后编写的，大家经常把这两者做比较，如果说它是个key-value store 的话但是它具有丰富的数据类型，我想暂时把它叫做缓存数据流中心，就像现在物流中心那样，order、package、store、classification、distribute、end。现在还很流行的LAMP PHP架构 不知道和 redis+mysql 或者 redis + mongodb的性能比较（听群里的人说mongodb分片不稳定）。

先说说reidis的特性

1. 支持持久化

redis的本地持久化支持两种方式：RDB和AOF。RDB 在redis.conf配置文件里配置持久化触发器，AOF指的是redis没增加一条记录都会保存到持久化文件中（保存的是这条记录的生成命令），如果不是用redis做DB用的话还会不要开AOF ，数据太庞大了，重启恢复的时候是一个巨大的工程！

2.丰富的数据类型

redis 支持 String 、Lists、sets、sorted sets、hashes 多种数据类型,新浪微博会使用redis做nosql主要也是它具有这些类型，时间排序、职能排序、我的微博、发给我的这些功能List 和 sorted set 的强大操作功能息息相关

3.高性能

这点跟memcache很想象，内存操作的级别是毫秒级的比硬盘操作秒级操作自然高效不少，较少了磁头寻道、数据读取、页面交换这些高开销的操作！这也是NOSQL冒出来的原因吧，应该是高性能

是基于RDBMS的衍生产品，虽然RDBMS也具有缓存结构，但是始终在app层面不是我们想要的那么操控的。

4.replication

redis提供主从复制方案，跟mysql一样增量复制而且复制的实现都很相似，这个复制跟AOF有点类似复制的是新增记录命令，主库新增记录将新增脚本发送给从库，从库根据脚本生成记录，这个过程非常快，就看网络了，一般主从都是在同一个局域网，所以可以说redis的主从近似及时同步，同事它还支持一主多从，动态添加从库，从库数量没有限制。 主从库搭建，我觉得还是采用网状模式，如果使用链式（master-slave-slave-slave-slave·····）如果第一个slave出现宕机重启，首先从master 接收 数据恢复脚本，这个是阻塞的，如果主库数据几TB的情况恢复过程得花上一段时间，在这个过程中其他的slave就无法和主库同步了。

5.更新快

这点好像从我接触到redis到目前为止 已经发了大版本就4个，小版本没算过。redis作者是个非常积极的人，无论是邮件提问还是论坛发帖，他都能及时耐心的为你解答，维护度很高。有人维护的话，让我们用的也省心和放心。目前作者对redis 的主导开发方向是redis的集群方向。

所以如果希望简单就用ehcache，如果开发任务比较复杂，希望得到比较多的支持什么的就redis

lru缓存java的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于java缓存技术 redis、lru缓存java的信息别忘了在本站进行查找喔。

标签：