spring缓存集成
1. spring为什么要使用三级缓存解决循环依赖
首先清楚spring中bean 的加载过程：
1 解析需要spring管理的类为beanDefinition
2 通过反射实例化对象
3 反射设置属性
4初始化，调用initMethod等。（postConstruct也是在这执行）
循环依赖的问题： a依赖b，b依赖a。
在a实例化之后会先将a放入到缓存中，然后给a设置属性，去缓存中查到b。此时找不到就开始b的创建。b实例化之后，放入到缓存中，需要给a设置属性，此时去缓存中查到a设置成功。然后初始化。成功后将b放入一级缓存。这个时候a在给自己属性b设置值的时候就找到了b，然后设置b。完成属性设置，再初始化，初始化后a放入一级缓存。
解决代理对象（如aop）循环依赖的问题。
例： a依赖b,b依赖a，同时a,b都被aop增强。
首先明确aop的实现是通过 postBeanProcess后置处理器，在初始化之后做代理操作的。
为什么使用三级缓存原因：
1 只使用二级缓存，且二级缓存缓存的是一个不完整的bean
如果只使用二级缓存，且二级缓存缓存的是一个不完整的bean，这个时候a在设置属性的过程中去获取b（这个时候a还没有被aop的后置处理器增强），创建b的过程中，b依赖a，b去缓存中拿a拿到的是没有经过代理的a。就有问题。
2 使用二级缓存，且二级缓存是一个工厂方法的缓存
如果二级缓存是一个工厂的缓存，在从缓存中获取的时候获取到经过aop增强的对象。可以看到从工厂缓存中获取的逻辑。
protected ObjectgetEarlyBeanReference(String beanName, RootBeanDefinition mbd, Object bean) {
Object exposedObject = bean;
if (!mbd.isSynthetic() && ()) {
for (BeanPostProcessor bp : getBeanPostProcessors()) {
if (bpinstanceof ) {
ibp = () bp;
exposedObject = ibp.getEarlyBeanReference(exposedObject, beanName);
}
}
}
return exposedObject;
}
a依赖b，b依赖a，c。c又依赖a。a,b，c均aop增强。
加载开始： a实例化，放入工厂缓存，设置b，b实例化，设置属性，拿到a,此时从工厂缓存中拿到代理后的a。由于a没加载完毕，不会放入一级缓存。这个时候b开始设置c,c实例化，设置属性a,又去工厂缓存中拿对象a。这个时候拿到的a和b从工厂缓存不是一个对象。出现问题。
3 使用二级缓存，二级缓存缓存的是增强后的bean。这个与spring加载流程不符合。spring加载流程是：实例化，设置属性，初始化，增强。在有循环引用的时候，之前的bean并不会增强后放入到二级缓存。
综上1，2，3 可知二级缓存解决不了有aop的循环依赖。spring采用了三级缓存。
一级缓存 singletonObjects 缓存加载完成的bean。
二级缓存 earlySingletonObjects 缓存从三级缓存中获取到的bean，此时里面的bean没有加载完毕。
三级缓存 singletonFactories 。缓存一个objectFactory工厂。
场景：a依赖b，b依赖a和c，c依赖a。并且a，b，c都aop增强。
加载过程：
a实例化，放入三级工厂缓存，设置属性b，b实例化放入三级缓存。b设置属性a，从三级工厂缓存中获取代理后的对象a，同时，代理后的a放入二级缓存，然后设置属性c，c实例化放入三级缓存，设置属性a,此时从二级缓存中获取到的代理后的a跟b中的a是一个对象，属性a设置成功。c初始化，然后执行后置处理器。进行aop的增强。增强后将代理的c放入到一级缓存，同时删除三级缓存中的c。c加载完成，b得到c，b设置c成功。b初始化，然后执行后置处理器，进行aop增强，将增强后的代理对象b放入到一级缓存。删除三级缓存中的b。此时 a拿到b，设置属性b成功，开始初始化，初始化后执行后置处理器。在aop的后置处理器中有一个以beanName为key，经过aop增强的代理对象为value的map earlyProxyReferences。
这个时候 后置处理器处理对象a的时候，
public (@Nullable Object bean, String beanName) {
if (bean !=null) {
Object cacheKey = getCacheKey(bean.getClass(), beanName);
if (this.earlyProxyReferences.remove(cacheKey) != bean) {
return wrapIfNecessary(bean, beanName, cacheKey);
}
}
return bean;
}
也就是 发现这个beanName已经被代理后就不在代理。这个时候执行后置处理器后，a还是未经代理的对象a。此时a再通过getSingleton 重新从缓存中获取一下a。
Object earlySingletonReference = getSingleton(beanName, false);
false 表示不从三级缓存中取，只从一级，二级缓存中获取。
这个时候能拿到二级缓存中的a。二级缓存中的a也是经过代理后的a。
然后将代理后的a放入到一级缓存中。a加载完毕。
放入一级缓存的过程 ：
addSingleton(beanName, singletonObject);
从三级工厂缓存中获取对象：
protected ObjectgetEarlyBeanReference(String beanName, RootBeanDefinition mbd, Object bean) {
Object exposedObject = bean;
if (!mbd.isSynthetic() && ()) {
for (BeanPostProcessor bp : getBeanPostProcessors()) {
if (bpinstanceof ) {
ibp = () bp;
exposedObject = ibp.getEarlyBeanReference(exposedObject, beanName);
}
}
}
return exposedObject;
}
其中 AbstractAutoProxyCreator实现该接口。
public ObjectgetEarlyBeanReference(Object bean, String beanName) {
Object cacheKey = getCacheKey(bean.getClass(), beanName);
this.earlyProxyReferences.put(cacheKey, bean);
return wrapIfNecessary(bean, beanName, cacheKey);
}
wrapIfNecessary（）就是真正执行代理的。
bean初始化之后执行的后置处理器：
其中AbstractAutoProxyCreator 实现了该接口。
2. spring一级缓存和二级缓存的区别是什么
一级缓存：x0dx0a就是Session级别的缓存。一个Session做了一个查询操作，它会把这个操作的结果放在一级缓存中。x0dx0a如果短时间内这个session（一定要同一个session）又做了同一个操作，那么hibernate直接从一级缓存中拿，而不会再去连数据库，取数据。x0dx0a它是内置的事务范围的缓存，不能被卸载。x0dx0a二级缓存：x0dx0a就是SessionFactory级别的缓存。顾名思义，就是查询的时候会把查询结果缓存到二级缓存中。x0dx0a如果同一个sessionFactory创建的某个session执行了相同的操作，hibernate就会从二级缓存中拿结果，而不会再去连接数据库。x0dx0a这是可选的插件式的缓存，在默认情况下，SessionFactory不会启用这个插件。x0dx0a可以在每个类或每个集合的粒度上配置。缓存适配器用于把具体的缓存实现软件与Hibernate集成。x0dx0a严格意义上说，SessionFactory缓存分为两类：内置缓存和外置缓存。我们通常意义上说的二级缓存是指外置缓存。x0dx0a内置缓存与session级别缓存实现方式相似。前者是SessionFactory对象的一些集合属性包含的数据，后者是指Session的一些集合属性包含的数据x0dx0aSessionFactory的内置缓存中存放了映射元数据和预定义sql语句。x0dx0a映射元数据是映射文件中数据的拷贝；x0dx0a而预定义SQL语句是在Hibernate初始化阶段根据映射元数据推导出来。x0dx0aSessionFactory的内置缓存是只读的，应用程序不能修改缓存中的映射元数据和预定义SQL语句，因此SessionFactory不需要进行内置缓存与映射文件的同步。x0dx0aHibernate的这两级缓存都位于持久化层，存放的都是数据库数据的拷贝。x0dx0a缓存的两个特性：x0dx0a缓存的范围x0dx0a缓存的并发访问策略x0dx0a1、缓存的范围x0dx0a决定了缓存的生命周期以及可以被谁访问。缓存的范围分为三类。x0dx0a事务范围x0dx0a进程范围x0dx0a集群范围x0dx0a注：x0dx0a对大多数应用来说，应该慎重地考虑是否需要使用集群范围的缓存，因为访问的速度不一定会比直接访问数据库数据的速度快多少。x0dx0a事务范围的缓存是持久化层的第一级缓存，通常它是必需的；进程范围或集群范围的缓存是持久化层的第二级缓存，通常是可选的。x0dx0a2、缓存的并发访问策略x0dx0a当多个并发的事务同时访问持久化层的缓存的相同数据时，会引起并发问题，必须采用必要的事务隔离措施。x0dx0a在进程范围或集群范围的缓存，即第二级缓存，会出现并发问题。x0dx0a因此可以设定以下四种类型的并发访问策略，每一种策略对应一种事务隔离级别。x0dx0a事务型并发访问策略是事务隔离级别最高，只读型的隔离级别最低。事务隔离级别越高，并发性能就越低。x0dx0aA 事务型：仅仅在受管理环境中适用。它提供了Repeatable Read事务隔离级别。x0dx0a对于经常被读但很少修改的数据，可以采用这种隔离类型，因为它可以防止脏读和不可重复读这类的并发问题。x0dx0aB 读写型：提供了Read Committed事务隔离级别。仅仅在非集群的环境中适用。x0dx0a对于经常被读但很少修改的数据，可以采用这种隔离类型，因为它可以防止脏读这类的并发问题。x0dx0aC 非严格读写型：不保证缓存与数据库中数据的一致性。x0dx0a如果存在两个事务同时访问缓存中相同数据的可能，必须为该数据配置一个很短的数据过期时间，从而尽量避免脏读。x0dx0a对于极少被修改，并且允许偶尔脏读的数据，可以采用这种并发访问策略。x0dx0aD 只读型：对于从来不会修改的数据，如参考数据，可以使用这种并发访问策略。x0dx0a什么样的数据适合存放到第二级缓存中？x0dx0a1、很少被修改的数据x0dx0a2、不是很重要的数据，允许出现偶尔并发的数据x0dx0a3、不会被并发访问的数据x0dx0a4、参考数据x0dx0a不适合存放到第二级缓存的数据？x0dx0a1、经常被修改的数据x0dx0a2、财务数据，绝对不允许出现并发x0dx0a3、与其他应用共享的数据。x0dx0aHibernate的二级缓存策略的一般过程如下：x0dx0a1) 条件查询的时候，总是发出一条select * from table_name where ?. （选择所有字段）这样的SQL语句查询数据库，一次获得所有的数据对象。x0dx0a2) 把获得的所有数据对象根据ID放入到第二级缓存中。x0dx0a3) 当Hibernate根据ID访问数据对象的时候，首先从Session一级缓存中查；查不到，如果配置了二级缓存，那么从二级缓存中查；查不到，再查询数据库，把结果按照ID放入到缓存。x0dx0a4) 删除、更新、增加数据的时候，同时更新缓存。x0dx0a注：x0dx0aHibernate的二级缓存策略，是针对于ID查询的缓存策略，对于条件查询则毫无作用。为此，Hibernate提供了针对条件查询的Query缓存。x0dx0aQuery缓存策略的过程如下：x0dx0a1) Hibernate首先根据这些信息组成一个Query Key，Query Key包括条件查询的请求一般信息：SQL, SQL需要的参数，记录范围（起始位置rowStart，最大记录个数maxRows)，等。x0dx0a2) Hibernate根据这个Query Key到Query缓存中查找对应的结果列表。如果存在，那么返回这个结果列表；如果不存在，查询数据库，获取结果列表，把整个结果列表根据Query Key放入到Query缓存中。x0dx0a3) Query Key中的SQL涉及到一些表名，如果这些表的任何数据发生修改、删除、增加等操作，这些相关的Query Key都要从缓存中清空。
3. SpringBoot进阶之整合Shiro实现缓存和会话管理
大家好，一直以来我都本着用最通俗的话理解核心的知识点, 我认为所有的难点都离不开 “基础知识” 的铺垫。目前正在出一个 SpringBoot 长期系列教程，从入门到进阶, 篇幅会较多~
“大佬可以绕过 ~”
如果你是一路看过来的，很高兴你能够耐心看完。之前带大家学了 Springboot 基础部分，对基本的使用有了初步的认识, 接下来的几期内容将会带大家进阶使用，会先讲解基础 中间件 的使用和一些场景的应用，或许这些技术你听说过，没看过也没关系，我会带大家一步一步的入门，耐心看完你一定会有 收获 ~
上期带大家学习了 Shiro 中如何进行权限认证，本期将带大家学习 Shiro 中如何进行 缓存和会话管理 ，最后我们将做一个在线用户管理以及强制下线用户的功能，同样的，我们集成到 Springboot 中。
首先我们要明白使用缓存的原因，为啥要用它 还记得之前带大家实现的 用户认证 和 权限认证 吗，那里我使用了 MockUser ，真实场景中是要去数据查询的，这样一来就会产生耗时，请求多的时候数据库肯定忙不过来了，所以我们需要使用缓存来提高程序响应速度
缓存使用 Redis ,下面就带大家整一下:
修改 ShiroConfig ,添加方法
这样就可以了，大家可以把测试获取用户的地方改成数据库获取，看下 控制台 sql日志会明显减少，因为有一部分是从缓存拿的
这部分功能还是比较好玩的，学完可以自由发挥做一个房间功能,可以加入可以踢人,下面我们就开整
修改 ShiroConfig ,添加方法，因为我们使用的是 Redis 缓存
实现 SessionListener
最后同样的，想要开启需要我们注入到 Manager 中:
我们先定义一个类，用来记录在线用户:
那么怎么获取呢？我们定义一个方法,大家实践中可以抽到 Service 层,这里方便演示，我直接写到控制器里
如果你看谁不爽，可以直接让他下线，hhh~
是不是很简单,这里就不演示了，大家自行试试
本期内容就到这里结束了，总结一下，本节主要讲了 Shiro 如何进行缓存以及如何进行用户会话管理，大家可以举一反三，做一些小功能尝试尝试
下期给大家讲讲 Shiro 中如何整合 JWT ，这个大家应该不陌生，如果不知道啥是 JWT 也没关系，我会带大家一步一步入门，下期也是 Shiro 系列的终极篇，内容可能有点多，耐心看完哦。欢迎加群一起学习交流 ~
4. SpringBoot进阶之缓存中间件Redis
大家好，一直以来我都本着 用最通俗的话理解核心的知识点， 我认为所有的难点都离不开 “基础知识” 的铺垫
“大佬可以绕过 ~”
本节给大家讲讲 “java的SpringBoot框架” , 之前我们学习的都是java的基础知识和底层提供的一些能力，我们日常工作都是在写接口。在我们在产品开发中，一般我们都会选择比较稳定的框架来帮我们加速开发，不会自己去造轮子，而在java众多框架中，spring框架表现的非常好，大部分公司都会首选它作为开发框架，而至今，大部分企业都是以 springboot 来构建项目了,一个稳健的系统需要引入稳定的技术~
如果你是一路看过来的，很高兴你能够耐心看完。前几期都是带大家学习了 SpringBoot 的基础使用以及集成 mybatis 开发，这也是我们写业务的基础，如果你还不熟悉这些，请先看完它们。接下来的几期内容将会带大家进阶使用，会先讲解基础 中间件 的使用和一些场景的应用，或许这些技术你听说过，没看过也没关系，我会带大家一步一步的入门，耐心看完你一定会有 收获 ,本期将会给大家讲解最热门的缓存中间件技术 Redis ,同样的，我们集成到 Springboot 中。最近github可能会被墙，所以我把源码放到了国内gitee上,本节我们依然使用上期的代码
Redis 是由意大利人Salvatore Sanfilippo（网名：antirez）开发的一款内存高速缓存数据库。全称叫 Remote Dictionary Server（远程数据服务） 是由 C语言 编写的，Redis是一个 key-value 存储系统，它支持丰富的数据类型，如： string、list、set、zset(sorted set)、hash 。
它本质上是一种键值对数据库，我们之前学习的 mysql 它是持久层的关系型数据库,而 redis 它的存储主要存在 内存 中。我们都知道在 内存 中的数据读取是非常快的，就好比你把一个变量存到磁盘读取和直接放到代码中运行，肯定是在代码中拿到的速度快，因为运行时期，都是直接存到内存的。
给大家总结一下：
有了基本的概念之后，我们下面进行环境搭建,在学习阶段，安装 redis 很简单,生产环境一般我们也会选择云产品，一切为了服务保障,虽说它只是做缓存用，但也是系统的一把 保护伞
如果你是 mac 用户，你可以运行如下命令:
安装完成后会提示你运行命令，运行即可。
win 用户也很简单，直接下载 redis 软件，双击运行即可，运行之后它会有一个小方块的图案，和 locahost:6379 的log,说明运行成功了。初始阶段没有配置的 redis 默认 host 就是本地, port 就是 6379 , 而且是 没有密码 就可以访问的。
推荐一个客户端软件 Redis Desktop Manager ，它是 redis 的客户端界面软件,方便面我们学习的时候 清理缓存 使用,生产慎连。
我们不给大家讲它的基本命令使用，它也有语法，可以通过类似命令执行,如果想学习的小伙伴，可以自行搜索。本期重点内容是在 sprinboot 中的使用,我们平时开发不可能是去命令行里敲的，都是代码里执行，而目前市面上有很多封装好的库，我们可以直接调用它的方法，很方便的就可以操作它了，不用记一些繁琐的命令,下面我们就实际操作一下:
修改 pom.xml
修改 application.yml :
redis 默认是有 16 个库,不是 15 个啊，从 0 开始算的,我们随便连一个
通过代码很好理解, 首先需要引入 StringRedisTemplate ,然后需要设置一个 key ,那么思考一下，这个 key 允许重复吗
我们进客户端看一下，发现 key 还是只有一个,但是值变成了新的值了，所以可以得知 key 是唯一的，我们重新设置的时候相当于刷新了它。
在 redis 中删除缓存有两种方式，一种是自我消亡，也就是 过期 销毁,还有有一种是 主动 销毁，我们先看一下，过期时间如何设置
我们设置了 10s 后过期,过完10s后发现，这个```key data``消失了。我们在看看如何主动删除
我们可以利用 Redis 做一个计数器，实现自增功能,你可以用它做网站访问统计
通常做法，我们会把它封装一下，后续使用直接引入封装好的即可，把它直接交给 Springboot容器 管理
其实这个类，你还可以继续进一步封装，比如约束 key 的规范，约束过期时间，约束数据类型等等，这一切也都是为了规范和后期维护，防止滥用缓存
缓存的主要场景是用于解决热点数据问题，因为这些数据是访问频率比较高的，当大量的请求进来, mysql 可能压力很大，这样一来，数据查询效率就很慢，用户肯不高兴等了，这样用户体验很不好。所以我们一般做法，都是把这些热点数据放到缓存里，因为缓存读取速度很快。当有新数据的时候，我们再及时更新它，一般流程是先查询缓存，查到了直接返回缓存数据，查不到再走数据库，然后再刷回缓存。
但是并发足够大的时候，还是会暴露出很多问题，比如面试常问的一些高频问题 缓存雪崩、缓存穿透、缓存雪崩 ,这些问题后边会给大家专门讲，和如何去防范。所以总的来说，引入任何一门技术并不是万事大吉，还需我们不断的在实践中积累经验
本期到这里就结束了，总结一下，我们了解了什么是 redis ，以及在 springboot 中如何去使用它们，很简单，没什么复杂的东西。但这里想多说一点的是，缓存的设计却是很复杂的，因为工具是死的，人是活的，我们如何正确设计，需要我们在项目中不断的积累。
我们之前教大家查询列表数据，都是所有数据返回，还没有教大家如何去做分页，下期将带大家学习一下 mybatis 分页插件的使用 ，下期不见不散, 关注我，不迷路~
5. spring自带缓存机制怎么弄
此缓存方法既适用于层，也适用于service层。
spring配置文件配置：<!--缓存配置-->
<!--启用缓存注解功能-->
<cache:annotation-drivencache-manager="cacheManager"/>
<!--spring自己的基于java.util.concurrent.ConcurrentHashMap实现的缓存管理器（该功能是从Spring3.1开始提供）-->
<beanid="cacheManager"class="org.springframework.cache.support.SimpleCacheManager">
<propertyname="caches">
<set>
<!--此处类concurrentMapCacheFactoryBean的作用是
-->
<beanname="myCache"class="org.springframework.cache.concurrent.ConcurrentMapCacheFactoryBean"/>
</set>
</property>
</bean>service层示例如下：@Transactional(readOnly=true)
@Cacheable(value="myCache")
publicJsonObjectgetWFK(JsonObjectparams){
OneObob=newOneOb();
try{
List<Map<String,Object>>map=LawAssistantMapper.getWFK();
ob.setOb(map);
}catch(Exceptione){
e.printStackTrace();
ob.setCode(500);
ob.setMsg("服务器错误！！！");
returnnewJsonObject(Json.encode(ob));
}
ob.setCode(200);
ob.setMsg("ok");
logger.debug(Json.encode(ob));
returnnewJsonObject(Json.encode(ob));
}
由于使用的是spring自带的缓存类，所以，仅仅需要两步：1.在spring配置文件中声明，2.在service层，方法代码前增加注解，即可。
缺点：
spring自带的缓存功能，实质上是通过java类来保存缓存的数据，这样会占用一定的内存消耗，并发率越高，对内存的压力越大。
码民直接使用的缓存类：org.springframework.cache.support.SimpleCacheManager，org.springframework.cache.concurrent.ConcurrentMapCacheFactoryBean
6. hibernate二级缓存 和 spring整合的缓存(就是用哪个Cacheable注解的)有什么区别么
二级缓存配置（spring+hibernate）
说明：本人不建议使用查询缓存，因为查询缓存要求完全相同的查询sql语句才会起作用，所说的查询缓存是针对第二次查询时 sql语句与第一次sql语句完全相同 那么就可以从缓存中取数据而不去数据库中取数据了，在不启用查询缓存的情况下 每次的查询数据也会缓存到二级缓存的 只不过每次查询都会去查询数据库（不包括根据ID查询），启用查询缓存很麻烦 需要每次查询时 调用Query.setCacheable(true)方法才可以，如：List<OrgiData> orgiDatas = (List<OrgiData>) s.createQuery("from OrgiData").setCacheable(true).list();
因此建议将查询缓存设置为如下：
hibernate.cache.use_query_cache=false
还有就是最重要的一点：对于经常修改或重要的数据不宜进行缓存，因为多并发时会造成数据不同步的情况。
首先增加ehcache-1.4.1.jar和backport-util-concurrent-3.1.jar或oscache-2.1.jar
一、spring配置
<bean id="sessionFactory"
class="org.springframework.orm.hibernate3.LocalSessionFactoryBean">
<property name="dataSource" ref="dataSource" />
<property name="mappingResources">
<list>
<value>com/handpay/core/merchant/bean/MerchGroupBuy.hbm.xml
</value>
</list>
</property>
<property name="hibernateProperties">
<value>
hibernate.dialect=org.hibernate.dialect.SQLServerDialect
hibernate.show_sql=true
hibernate.format_sql=true
hibernate.hbm2ddl.auto=update
hibernate.cache.use_second_level_cache=true
hibernate.cache.use_query_cache=false
hibernate.cache.provider_class=org.hibernate.cache.EhCacheProvider </value>
</property>
</bean>
<!---红色字体是二级缓存相关的设置->
二、hbm.xml文件示例
<?xml version="1.0"?>
<!DOCTYPE hibernate-mapping PUBLIC
"-//Hibernate/Hibernate Mapping DTD 3.0//EN"
"http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">
<hibernate-mapping package="com.handpay.core.merchant.bean">
<class name="MerchGroupBuy" table="merch_group_buy">
<cache usage="read-write" region="com.handpay.core.merchant.bean.MerchGroupBuy"/>
<id name="id">
<generator class="native" />
</id>
<property name="code" />
<property name="createTime"/>
<property name="minNum"/>
<property name="status">
</property>
<property name="title"/>
<property name="typeCode"/>
<property name="updateTime"/>
</class>
</hibernate-mapping>
三、注解示例
@Entity
@Cache(usage = CacheConcurrencyStrategy.READ_ONLY)
@Table(name = "alcor_t_countries", catalog = "alcorweb")
public class AlcorTCountries implements java.io.Serializable{。。。。}
四、配置文件参数详解
ehcache.xml是ehcache的配置文件，并且存放在应用的classpath中。下面是对该XML文件中的一些元素及其属性的相关说明：
<diskStore>元素：指定一个文件目录，当EHCache把数据写到硬盘上时，将把数据写到这个文件目录下。 下面的参数这样解释：
user.home – 用户主目录
user.dir – 用户当前工作目录
java.io.tmpdir – 默认临时文件路径
<defaultCache>元素：设定缓存的默认数据过期策略。
<cache>元素：设定具体的命名缓存的数据过期策略。
<cache>元素的属性
name：缓存名称。通常为缓存对象的类名（非严格标准）。
maxElementsInMemory：设置基于内存的缓存可存放对象的最大数目。
maxElementsOnDisk：设置基于硬盘的缓存可存放对象的最大数目。
eternal：如果为true，表示对象永远不会过期，此时会忽略timeToIdleSeconds和timeToLiveSeconds属性，默认为false;
timeToIdleSeconds： 设定允许对象处于空闲状态的最长时间，以秒为单位。当对象自从最近一次被访问后，如果处于空闲状态的时间超过了timeToIdleSeconds属性值，这个对象就会过期。当对象过期，EHCache将把它从缓存中清空。只有当eternal属性为false，该属性才有效。如果该属性值为0，则表示对象可以无限期地处于空闲状态。
timeToLiveSeconds：设定对象允许存在于缓存中的最长时间，以秒为单位。当对象自从被存放到缓存中后，如果处于缓存中的时间超过了 timeToLiveSeconds属性值，这个对象就会过期。当对象过期，EHCache将把它从缓存中清除。只有当eternal属性为false，该属性才有效。如果该属性值为0，则表示对象可以无限期地存在于缓存中。timeToLiveSeconds必须大于timeToIdleSeconds属性，才有意义。
overflowToDisk：如果为true,表示当基于内存的缓存中的对象数目达到了maxElementsInMemory界限后，会把益出的对象写到基于硬盘的缓存中。注意：如果缓存的对象要写入到硬盘中的话，则该对象必须实现了Serializable接口才行。
memoryStoreEvictionPolicy：缓存对象清除策略。有三种：
1 FIFO ，first in first out ，这个是大家最熟的，先进先出，不多讲了
2 LFU ， Less Frequently Used ，就是上面例子中使用的策略，直白一点就是讲一直以来最少被使用的。如上面所讲，缓存的元素有一个hit 属性，hit 值最小的将会被清出缓存。
2 LRU ，Least Recently Used ，最近最少使用的，缓存的元素有一个时间戳，当缓存容量满了，而又需要腾出地方来缓存新的元素的时候，那么现有缓存元素中时间戳离当前时间最远的元素将被清出缓存。
五 、查看 二级缓存数据
1、使用sessionFactory直接获取
Map cacheEntries = sessionFactory().getStatistics()
.getSecondLevelCacheStatistics("cacheRegionName")
.getEntries();
其中 cacheRegionName 既是 ehcache.xml配置中的<cache 标签的name属性值
2、让log4j打印缓存信息（生成环境下请注释掉，以免影响性能）
log4j.logger.org.hibernate.cache=debug
7. spring mvc 怎么设计缓存
用于提供如浏览器缓存控制、是否必须有session开启、支持的请求方法类型（GET、POST等）等，该类主要有如下属性：
Set<String> supportedMethods：设置支持的请求方法类型，默认支持“GET”、“POST”、“HEAD”，如果我们想支持“PUT”，则可以加入该集合“PUT”。
boolean requireSession = false：是否当前请求必须有session，如果此属性为true，但当前请求没有打开session将抛出HttpSessionRequiredException异常；
boolean useExpiresHeader = true：是否使用HTTP1.0协议过期响应头：如果true则会在响应头添加：“Expires：”；需要配合cacheSeconds使用；
boolean useCacheControlHeader = true：是否使用HTTP1.1协议的缓存控制响应头，如果true则会在响应头添加；需要配合cacheSeconds使用；
boolean useCacheControlNoStore = true：是否使用HTTP 1.1协议的缓存控制响应头，如果true则会在响应头添加；需要配合cacheSeconds使用；
private int cacheSeconds = -1：缓存过期时间，正数表示需要缓存，负数表示不做任何事情（也就是说保留上次的缓存设置），
1、cacheSeconds =0时，则将设置如下响应头数据：
Pragma：no-cache // HTTP 1.0的不缓存响应头
Expires：1L // useExpiresHeader=true时，HTTP 1.0
Cache-Control ：no-cache // useCacheControlHeader=true时，HTTP 1.1
Cache-Control ：no-store // useCacheControlNoStore=true时，该设置是防止Firefox缓存
2、cacheSeconds>0时，则将设置如下响应头数据：
Expires：System.currentTimeMillis() + cacheSeconds * 1000L // useExpiresHeader=true时，HTTP 1.0
Cache-Control ：max-age=cacheSeconds // useCacheControlHeader=true时，HTTP 1.1
3、cacheSeconds<0时，则什么都不设置，即保留上次的缓存设置。
此处简单说一下以上响应头的作用，缓存控制已超出本书内容：
HTTP1.0缓存控制响应头
Pragma：no-cache：表示防止客户端缓存，需要强制从服务器获取最新的数据；
Expires：HTTP1.0响应头，本地副本缓存过期时间，如果客户端发现缓存文件没有过期则不发送请求，HTTP的日期时间必须是格林威治时间（GMT），如“Expires:Wed, 14 Mar 2012 09:38:32 GMT”；
HTTP1.1缓存控制响应头
Cache-Control ：no-cache 强制客户端每次请求获取服务器的最新版本，不经过本地缓存的副本验证；
Cache-Control ：no-store 强制客户端不保存请求的副本，该设置是防止Firefox缓存
Cache-Control：max-age=[秒] 客户端副本缓存的最长时间，类似于HTTP1.0的Expires，只是此处是基于请求的相对时间间隔来计算，而非绝对时间。
还有相关缓存控制机制如Last-Modified（最后修改时间验证，客户端的上一次请求时间 在 服务器的最后修改时间 之后，说明服务器数据没有发生变化 返回304状态码）、ETag（没有变化时不重新下载数据，返回304）。
该抽象类默认被AbstractController和WebContentInterceptor继承。
8. Spring本地缓存的使用方法
我们现在在用的Spring Cache，可以直接看Spring Boot提供的缓存枚举类，有如下这些：
EhCache：一个纯Java的进程内缓存框架，所以也是基于本地缓存的。(注意EhCache2.x和EhCache3.x相互不兼容)。
Redis：分布式缓存，只有Client-Server(CS)模式，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的方式配置：
参考资料：
https://blog.csdn.net/f641385712/article/details/94982916
http://www.360doc.com/content/17/1017/20/16915_695800687.shtml
9. SpringBoot整合SpringSeesion实现Redis缓存
使用Spring Boot开发项目时我们经常需要存储Session，因为Session中会存一些用户信息或者登录信息。传统的web服务是将session存储在内存中的，一旦服务挂了，session也就消失了，这时候我们就需要将session存储起来，而Redis就是用来缓存seesion的一种非关系型数据库，我们可以通过配置或者注解的方式将Spring Boot和Redis整合。而在分布式系统中又会涉及到session共享的问题，多个服务同时部署时session需要共享，Spring Session可以帮助我们实现这一功能。将Spring Session集成到Spring Boot框架中并使用Redis进行缓存是目前非常流行的解决方案，接下来就跟着我一起学习吧。
工具/材料
IntelliJ IDEA
首先我们创建一个Spring Boot 2.x的项目，在application.properties配置文件中添加Redis的配置，Spring和Redis的整合可以参考我其他的文章，此处不再详解。我们设置服务端口server.port为8080端口用于启动第一个服务。
接下来我们需要在pom文件中添加spring-boot-starter-data-redis和spring-session-data-redis这两个依赖，spring-boot-starter-data-redis用于整合Spring Boot和Redis，spring-session-data-redis集成了spring-session和spring-data-redis，提供了session与redis的整合方案。
接下来我们创建一个配置类RedisSessionConfig，这个类使用@Configuration注解表明这是一个配置类。在这个类上我们同时添加注解@EnableRedisHttpSession，表示开启Redis的Session管理。如果需要设置失效时间可以使用@EnableRedisHttpSession(maxInactiveIntervalInSeconds = 3600)表示一小时后失效。若同时需要设置Redis的命名空间则使用@EnableRedisHttpSession(maxInactiveIntervalInSeconds=3600, redisNamespace="{spring.session.redis.namespace}") ，其中{spring.session.redis.namespace}表示从配置文件中读取这个命名空间。
配置完成后我们写一个测试类SessionController，在这个类中我们写两个方法，一个方法用于往session中存数据，一个用于从session中取数据，代码如下图所示，我们存取请求的url。启动类非常简单，一般都是通用的，我们创建一个名为SpringbootApplication的启动类，使用main方法启动。
接下来我们使用Postman分别请求上面两个接口，先请求存数据接口，再请求取数据接口，结果如下图所示，我们可以看到数据已从redis中取出。另外需要注意sessionId的值，这是session共享的关键。
为了验证两个服务是否共享了session，我们修改项目的配置文件，将服务端口server.port改为8090，然后再启动服务。此时我们不必在请求存数据的接口，只需要修改请求端口号再一次请求取数据的接口即可。由下图可以看到两次请求的sessionId值相同，实现了session的共享。
以上我们完成了SpringBoot整合SpringSeesion实现Redis缓存的功能，在此我们还要推荐一个Redis的可视化工具RedisDesktopManager，我们可以配置Redis数据库的连接，然后便可以非常直观地查看到存储到Redis中的session了，如下图所示，session的命名空间是share，正是从配置文件中读取到的。
特别提示
如果Redis服务器是很多项目共用的，非常建议配置命名空间，否则同时打开多个项目的浏览器页面可能会导致session错乱的现象。