一级缓存和二级缓存
本文参考了下文:
https://www.cnblogs.com/happyflyingpig/p/7739749.html \
一级缓存 Mybatis 对缓存提供了支持,在没有配置的情况下,Mybatis默认只开启一级缓存,一级缓存其实就是依托于SqlSession,即使用同一个SqlSession操作下,如果Sql语句和参数都没有变化,SqlSession第一次会发送SQL,再缓存没有失效的情况下,后面的查询,就会直接去二级缓存中查找,不再像数据库发送SQL查询。
图片来源于上述链接博文:
为什么要使用一级缓存,不用多说也知道个大概。但是还有几个问题我们要注意一下。
1、一级缓存的生命周期有多长?
a、MyBatis在开启一个数据库会话时,会创建一个新的SqlSession对象,SqlSession对象中会有一个新的Executor对象。Executor对象中持有一个新的PerpetualCache对象;当会话结束时,SqlSession对象及其内部的Executor对象还有PerpetualCache对象也一并释放掉。
b、如果SqlSession调用了close()方法,会释放掉一级缓存PerpetualCache对象,一级缓存将不可用。
c、如果SqlSession调用了clearCache(),会清空PerpetualCache对象中的数据,但是该对象仍可使用。
d、SqlSession中执行了任何一个update操作(update()、delete()、insert()) ,都会清空PerpetualCache对象的数据,但是该对象可以继续使用
2、怎么判断某两次查询是完全相同的查询?
mybatis认为,对于两次查询,如果以下条件都完全一样,那么就认为它们是完全相同的两次查询。
2.1 传入的statementId
2.2 查询时要求的结果集中的结果范围
2.3 这次查询所产生的最终要传递给JDBC java.sql.Preparedstatement的Sql语句字符串(boundSql.getSql() )
2.4 传递给java.sql.Statement要设置的参数值
一级缓存验证 我们依托于前面的示例,
Role:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 @NoArgsConstructor @AllArgsConstructor @Getter @Setter @ToString public class Role { private Integer id; private String roleName; private String description; private Integer status; private Date createTime; private String createUser; private Date modifyTime; private String modifyUser; }
RoleMapper:
1 2 3 public interface RoleMapper { Role findById (Integer id) ; }
下面是测试一级缓存的方法:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 public class AppTest { SqlSession sqlSession = null ; @Before public void init () { String resource = "mybatis.configuration.xml" ; InputStream inputStream = AppTest.class .getClassLoader ().getResourceAsStream (resource ) ; sqlSession = new SqlSessionFactoryBuilder().build(inputStream).openSession(true ); } @Test public void testFindRoleById () { RoleMapper mapper = sqlSession.getMapper(RoleMapper.class ) ; Role role1 = mapper.findById(1 ); Role role2 = mapper.findById(1 ); System.out.println(role1); System.out.println(role2); sqlSession.close(); } }
测试结果:
二级缓存 Mybatis的二级缓存是SqlSessionFactory层面的,一级缓存是SqlSession层面的。
默认情况下,只启用了本地的会话缓存,也就是一级缓存,基于SqlSession的 ,但是如果需要开启二级缓存的话,只需要在Mapper.xml文件中添加一行:
基本上就是这样。这个简单语句的效果如下:
映射语句文件中的所有 select 语句的结果将会被缓存。
映射语句文件中的所有 insert、update 和 delete 语句会刷新缓存。
缓存会使用最近最少使用算法(LRU, Least Recently Used)算法来清除不需要的缓存。
缓存不会定时进行刷新(也就是说,没有刷新间隔)。
缓存会保存列表或对象(无论查询方法返回哪种)的 1024 个引用。
缓存会被视为读/写缓存,这意味着获取到的对象并不是共享的,可以安全地被调用者修改,而不干扰其他调用者或线程所做的潜在修改。
二级缓存验证 RoleMapper.xml:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 <?xml version="1.0" encoding="UTF-8" ?> <!DOCTYPE mapper PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN" "http://mybatis.org/dtd/mybatis-3-mapper.dtd" > <mapper namespace ="com.ooyhao.mybatis4.mapper.RoleMapper" > <cache /> <resultMap id ="base_map_4" type ="role" > <id column ="id" jdbcType ="INTEGER" property ="id" /> <result column ="role_name" jdbcType ="VARCHAR" property ="roleName" /> <result column ="description" jdbcType ="VARCHAR" property ="description" /> <result column ="status" jdbcType ="INTEGER" property ="status" /> <result column ="create_time" jdbcType ="TIMESTAMP" property ="createTime" /> <result column ="create_user" jdbcType ="VARCHAR" property ="createUser" /> <result column ="modify_time" jdbcType ="TIMESTAMP" property ="modifyTime" /> <result column ="modify_user" jdbcType ="VARCHAR" property ="modifyUser" /> </resultMap > <select id ="findById" resultMap ="base_map_4" > select * from tb_role where id = #{id} </select > </mapper >
如xml文件所述,我们仅在RoleMapper文件下添加<cache/>
用于开启当前namespace 的缓存。
单元测试方法:
(需要注意,我们需要将自动提交关闭,即openSession()的参数设置为false,或不填,否则无法进行缓存)
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 @Test public void testFindRoleByIdWithCache () { String resource = "mybatis.configuration.xml" ; InputStream stream = AppTest.class .getClassLoader ().getResourceAsStream (resource ) ; SqlSessionFactoryBuilder builder = new SqlSessionFactoryBuilder(); SqlSessionFactory build = builder.build(stream); SqlSession sqlSession1 = build.openSession(); RoleMapper mapper = sqlSession1.getMapper(RoleMapper.class ) ; Role role1 = mapper.findById(1 ); System.out.println(role1); RoleMapper mapper1 = sqlSession1.getMapper(RoleMapper.class ) ; Role role = mapper1.findById(1 ); System.out.println(role); sqlSession1.commit(); SqlSession sqlSession2 = build.openSession(); RoleMapper roleMapper = sqlSession2.getMapper(RoleMapper.class ) ; Role role2 = roleMapper.findById(1 ); System.out.println(role2); sqlSession2.commit(); }
此时测试结果为:(报未序列化异常)
所以,我们需要为Role对象加上Serializable接口 。
如果我们标注为缓存是只读的话,那么不序列化也不会保错:
1 <cache readOnly ="true" />
测试结果:
这是启用二级缓存之后的执行结果,可以发现查询了3次,但是实际仅仅只发送了一次SQL,我们可以看第二次的Cache Hit Ratio
是0.3333,即三分之一,我们总共查询了三次,在二级缓存中的命中的次数是一次,所以是0.333.
我们像下面这样,增加一次查询:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 public class AppTest { @Test public void testFindRoleByIdWithCache () { String resource = "mybatis.configuration.xml" ; InputStream stream = AppTest.class .getClassLoader ().getResourceAsStream (resource ) ; SqlSessionFactoryBuilder builder = new SqlSessionFactoryBuilder(); SqlSessionFactory build = builder.build(stream); SqlSession sqlSession1 = build.openSession(); RoleMapper mapper = sqlSession1.getMapper(RoleMapper.class ) ; Role role1 = mapper.findById(1 ); System.out.println(role1); RoleMapper mapper1 = sqlSession1.getMapper(RoleMapper.class ) ; Role role = mapper1.findById(1 ); System.out.println(role); sqlSession1.commit(); SqlSession sqlSession2 = build.openSession(); RoleMapper roleMapper = sqlSession2.getMapper(RoleMapper.class ) ; Role role2 = roleMapper.findById(1 ); System.out.println(role2); sqlSession2.commit(); SqlSession sqlSession3 = build.openSession(); RoleMapper roleMapper3 = sqlSession3.getMapper(RoleMapper.class ) ; Role role3 = roleMapper3.findById(1 ); System.out.println(role3); sqlSession3.commit(); } }
执行结果如下:
二级缓存详述 我们知道了如何操作二级缓存,下面我们对二级缓存进行更加详细的了解。
这个简单语句的效果如下:
映射语句文件中的所有 select 语句的结果将会被缓存。
映射语句文件中的所有 insert、update 和 delete 语句会刷新缓存。
缓存会使用最近最少使用算法(LRU, Least Recently Used)算法来清除不需要的缓存。
缓存不会定时进行刷新(也就是说,没有刷新间隔)。
缓存会保存列表或对象(无论查询方法返回哪种)的 1024 个引用。
缓存会被视为读/写缓存,这意味着获取到的对象并不是共享的,可以安全地被调用者修改,而不干扰其他调用者或线程所做的潜在修改。
这些属性可以通过 cache 元素的属性来修改。比如:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 <cache eviction ="FIFO" flushInterval ="60000" readOnly ="true" size ="512" /> <resultMap id ="base_map_4" type ="role" > <id column ="id" jdbcType ="INTEGER" property ="id" /> <result column ="role_name" jdbcType ="VARCHAR" property ="roleName" /> <result column ="description" jdbcType ="VARCHAR" property ="description" /> <result column ="status" jdbcType ="INTEGER" property ="status" /> <result column ="create_time" jdbcType ="TIMESTAMP" property ="createTime" /> <result column ="create_user" jdbcType ="VARCHAR" property ="createUser" /> <result column ="modify_time" jdbcType ="TIMESTAMP" property ="modifyTime" /> <result column ="modify_user" jdbcType ="VARCHAR" property ="modifyUser" /> </resultMap > <select id ="findById" resultMap ="base_map_4" useCache ="true" > select * from tb_role where id = #{id} </select >
这个更高级的配置创建了一个FIFO(first in first out) 缓存,每隔60秒刷新,最多可以存储结果对象或列表的512个引用,而且返回的对象被认为是只读的,因此对他们进行修改可能会在不同线程中的调用者产生冲突。
可用的清楚策略有:
LRU -最近最少使用:移除最长时间不被使用的对象。(默认)
FIFO -先进先出:按对象进入缓存的顺序来移除它们。
SOFT - 软引用:基于垃圾回收器状态和软引用规则移除对象。
WEAK - 弱引用:更积极地基于垃圾收集器状态和弱引用规则移除对象。
flushInterval(刷新间隔)属性可以被设置为任意的正整数,设置的值应该是一个以毫秒 为单位的合理时间量。 默认情况是不设置,也就是没有刷新间隔,缓存仅仅会在调用语句时刷新。
size(引用数目)属性可以被设置为任意正整数,要注意欲缓存对象的大小和运行环境中可用的内存资源。默认值是 1024。
readOnly(只读)属性可以被设置为 true 或 false。只读的缓存会给所有调用者返回缓存对象的相同实例。 因此这些对象不能被修改。这就提供了可观的性能提升。而可读写的缓存会(通过序列化)返回缓存对象的拷贝。 速度上会慢一些,但是更安全,因此默认值是 false。
提示 : 二级缓存是事务性的 。这意味着,当 SqlSession 完成并提交时,或是完成并回滚,但没有执行 flushCache=true 的 insert/delete/update 语句时,缓存会获得更新。
总结:
至此,我们学习了Mybatis的基础知识了,当然,如果我们需要深入理解Mybatis,我们还有很多要学习,所以,学习Mybatis,我们才刚刚开始。后面,我们学习一下如何和Spring整合操作。
源码地址:
https://gitee.com/ooyhao/JavaRepo_Public/tree/master/Mybatis