- 简介
以前在使用Hibernate的时候知道其有一级缓存和二级缓存，限制ORM框架的发展都是互相吸收其他框架的优点，在Hibernate中也有一级缓存和二级缓存，用于减轻数据压力，提高数据库性能。
mybaits提供一级缓存和二级缓存结构如下图：
可以看出一级缓存是sqlSession级别的，而二级缓存是Mapper级别的，同一个Mapper中的多个sqlSession可以共享缓存数据。
一级缓存是SqlSession级别的缓存。在操作数据库时需要构造 sqlSession对象，在对象中有一个数据结构（HashMap）用于存储缓存数据。不同的sqlSession之间的缓存数据区域（HashMap）是互相不影响的。 二级缓存是mapper级别的缓存，多个SqlSession去操作同一个Mapper的sql语句，多个SqlSession可以共用二级缓存，二级缓存是跨SqlSession的。
使用缓存时，如果缓存中有数据就不用从数据库中获取，大大提高系统性能。
- 一级缓存
Mybatis一级缓存的作用域是同一个SqlSession，在同一个sqlSession中两次执行相同的sql语句，第一次执行完毕会将数据库中查询的数据写到缓存（内存），第二次会从缓存中获取数据将不再从数据库查询，从而提高查询效率。当一个sqlSession结束后该sqlSession中的一级缓存也就不存在了。Mybatis默认开启一级缓存。
一级缓存的工作原理：
第一次发起查询用户id为1的用户信息，先去找缓存中是否有id为1的用户信息，如果没有，从数据库查询用户信息。得到用户信息，将用户信息存储到一级缓存中。
如果sqlSession去执行commit操作（执行插入、更新、删除），清空SqlSession中的一级缓存，这样做的目的为了让缓存中存储的是最新的信息，避免脏读。
第二次发起查询用户id为1的用户信息，先去找缓存中是否有id为1的用户信息，缓存中有，直接从缓存中获取用户信息。
一级缓存区域是根据SqlSession为单位划分的，每次查询会先从缓存区域找，如果找不到从数据库查询，查询到数据将数据写入缓存。Mybatis内部存储缓存使用一个HashMap，key为hashCode+sqlId+Sql语句。value为从查询出来映射生成的java对象sqlSession执行insert、update、delete等操作commit提交后会清空缓存区域。
还以前面提到的根据id来查询用户信息为例来测试，测试代码如下：
1 public void testCache2() throws Exception {
2 // 获取sqlSession对象
3 SqlSession sqlSession = sqlSessionFactory.openSession();
4 // 创建OrderMapper对象，MyBatis自动生成mapper代理
5 UserMapper userMapper = sqlSession.getMapper(UserMapper.class);
6 // 下边查询使用一个SqlSession
7 // 第一次发起请求，查询id为1的用户
8 User user1 = userMapper.findUserById(10);
9 System.out.println(user1);
10 User user3 = userMapper.findUserById(10);
11 System.out.println(user1 == user3);
12 // 如果sqlSession去执行commit操作（执行插入、更新、删除），清空SqlSession中的一级缓存，这样做的目的为了让缓存中存储的是最新的信息，避免脏读。
13 // 更新user1的信息
14 user1.setUsername("测试用户22");
15 userMapper.updateUser(user1);
16 // 执行commit操作去清空缓存
17 sqlSession.commit();
18 // 第二次发起请求，查询id为1的用户
19 User user2 = userMapper.findUserById(10);
20 System.out.println(user2);
21
22 sqlSession.close();
23 }
运行结果如下：
1 DEBUG [main] - ==> Preparing: select * from user where id = ? 2 DEBUG [main] - ==> Parameters: 10(Integer) 3 DEBUG [main] - <== Total: 1 4 10-张明明3-1-北京市-Thu Jul 10 00:00:00 CST 2014 5 DEBUG [main] - Cache Hit Ratio [com.luchao.mybatis.first.mapper.UserMapper]: 0.0 6 true 7 DEBUG [main] - ==> Preparing: update user set username=?,birthday=?,sex=?,address=? where id=? 8 DEBUG [main] - ==> Parameters: 测试用户22(String), 2014-07-10 00:00:00.0(Timestamp), 1(String), 北京市(String), 10(Integer) 9 DEBUG [main] - <== Updates: 1 10 DEBUG [main] - Committing JDBC Connection [[email protected]] 11 DEBUG [main] - Cache Hit Ratio [com.luchao.mybatis.first.mapper.UserMapper]: 0.0 12 DEBUG [main] - ==> Preparing: select * from user where id = ? 13 DEBUG [main] - ==> Parameters: 10(Integer) 14 DEBUG [main] - <== Total: 1 15 10-测试用户22-1-北京市-Thu Jul 10 00:00:00 CST 2014
可以看出在查询user3的时候是没有查询数据库的，它会直接从缓存中取出数据，并且和第一次放入缓存的数据是同一个数据。
实际运用：
正式开发，是将mybatis和spring进行整合开发，事务控制在service中，一个service方法中包括 很多mapper方法调用。伪代码如下：
1 service{
2 //开始执行时，开启事务，创建SqlSession对象
3 //第一次调用mapper的方法findUserById(1)
4 //第二次调用mapper的方法findUserById(1)，从一级缓存中取数据
5 //方法结束，sqlSession关闭
6 }
如果是执行两次service调用查询相同 的用户信息，不走一级缓存，因为session方法结束，sqlSession就关闭，一级缓存就清空。
- 二级缓存
MyBatis二级缓存是可拔插式的，默认是不开启的，在需要的时候进行配置，这是一种很好的设计理念，Hibernate也是这样。
二级缓存区域是根据mapper的namespace划分的，相同namespace的mapper查询数据放在同一个区域，如果使用mapper代理方法每个mapper的namespace都不同，此时可以理解为二级缓存区域是根据mapper划分。每次查询会先从缓存区域找，如果找不到从数据库查询，查询到数据将数据写入缓存。Mybatis内部存储缓存使用一个HashMap，key为hashCode+sqlId+Sql语句。value为从查询出来映射生成的java对象。sqlSession执行insert、update、delete等操作commit提交后会清空缓存区域。
实现原理：
sqlSession1去查询用户id为1的用户信息，查询到用户信息会将查询数据存储到二级缓存中。如果SqlSession3去执行相同 mapper下sql，执行commit提交，清空该 mapper下的二级缓存区域的数据。sqlSession2去查询用户id为1的用户信息，去缓存中找是否存在数据，如果存在直接从缓存中取出数据。二级缓存与一级缓存区别，二级缓存的范围更大，多个sqlSession可以共享一个UserMapper的二级缓存区域。
UserMapper有一个二级缓存区域（按namespace分） ，其它mapper也有自己的二级缓存区域（按namespace分）。每一个namespace的mapper都有一个二缓存区域，两个mapper的namespace如果相同，这两个mapper执行sql查询到数据将存在相同 的二级缓存区域中。
开启二级缓存的步骤：
1、开启二级缓存
mybaits的二级缓存是mapper范围级别，除了在SqlMapConfig.xml设置二级缓存的总开关，还要在具体的mapper.xml中开启二级缓存。
在核心配置文件SqlMapConfig.xml中加入：
1 <setting name="cacheEnabled" value="true"/>
|
描述 |
允许值 |
默认值 |
|
|
cacheEnabled |
对在此配置文件下的所有cache 进行全局性开/关设置。 |
true false |
true |
在Mapper中开启二级缓存，UserMapper.xml下的sql执行完成会存储到它的缓存区域（HashMap）。
在Mapper.xml中加入：
1 <cache />
就这么简单，不过cache中还可以加入缓存的实现类、大小、刷新频率、是否只读等属性。
2、调用的POJO实现序列化接口即实现Serializable接口，这样是为了将缓存数据取出执行反序列化操作，二级缓存数据存储介质多种多样，不一定在内存中。
3、测试代码：
1 public void testCache1() throws Exception {
2 // 获取sqlSession对象
3 SqlSession sqlSession1 = sqlSessionFactory.openSession();
4 SqlSession sqlSession2 = sqlSessionFactory.openSession();
5 SqlSession sqlSession3 = sqlSessionFactory.openSession();
6 // 创建UserMapper对象，MyBatis自动生成mapper代理
7 UserMapper userMapper1 = sqlSession1.getMapper(UserMapper.class);
8 UserMapper userMapper2 = sqlSession2.getMapper(UserMapper.class);
9 UserMapper userMapper3 = sqlSession3.getMapper(UserMapper.class);
10 // 下边查询使用一个SqlSession
11 // 第一次发起请求，查询id为1的用户
12 User user1 = userMapper1.findUserById(10);
13 System.out.println(user1);
14 // 这里执行关闭操作，将sqlsession中的数据写到二级缓存区域
15 sqlSession1.close();
16 User user2 = userMapper2.findUserById(10);
17 System.out.println(user2);
18 sqlSession2.close();
19 System.out.println(user1==user2);
20 // 使用sqlSession3执行commit()操作
21 User user = userMapper3.findUserById(10);
22 user.setUsername("张明明3");
23 userMapper3.updateUser(user);
24 // 执行提交，清空UserMapper下边的二级缓存
25 sqlSession3.commit();
26 sqlSession3.close();
27 }
测试结果：
1 DEBUG [main] - ==> Preparing: select * from user where id = ? 2 DEBUG [main] - ==> Parameters: 10(Integer) 3 DEBUG [main] - <== Total: 1 4 10-张明明3-1-北京市-Thu Jul 10 00:00:00 CST 2014 5 DEBUG [main] - Resetting autocommit to true on JDBC Connection [[email protected]] 6 DEBUG [main] - Closing JDBC Connection [[email protected]] 7 DEBUG [main] - Returned connection 1892148523 to pool. 8 DEBUG [main] - Cache Hit Ratio [com.luchao.mybatis.first.mapper.UserMapper]: 0.5 9 10-张明明3-1-北京市-Thu Jul 10 00:00:00 CST 2014 10 false 11 DEBUG [main] - Cache Hit Ratio [com.luchao.mybatis.first.mapper.UserMapper]: 0.6666666666666666 12 DEBUG [main] - Opening JDBC Connection 13 DEBUG [main] - Checked out connection 1892148523 from pool. 14 DEBUG [main] - Setting autocommit to false on JDBC Connection [[email protected]] 15 DEBUG [main] - ==> Preparing: update user set username=?,birthday=?,sex=?,address=? where id=? 16 DEBUG [main] - ==> Parameters: 张三(String), 2014-07-10 00:00:00.0(Timestamp), 1(String), 北京市(String), 10(Integer) 17 DEBUG [main] - <== Updates: 1
可以看出第二次查询的user2是在缓存中取出的，没有去查下数据库。另外，在sqlSession在执行close()方法才会将数据写入到缓存中。在结果中我们看到user1==users的结果为false，这个在缓存中取出的的吗，怎么会不一样？这是因为user2是通过反序列化得到的拷贝，所以user1和user2不是同一个对象。可以通过设置缓存的readonly=true来设置缓存为只读，从而得到的将会是同一个对象。
4、userCache配置的
在statement中设置useCache=false可以禁用当前select语句的二级缓存，即每次查询都会发出sql去查询，默认情况是true，即该sql使用二级缓存。
总结：针对每次查询都需要最新的数据sql，要设置成useCache=false，禁用二级缓存。
5、刷新缓存
在mapper的同一个namespace中，如果有其它insert、update、delete操作数据后需要刷新缓存，如果不执行刷新缓存会出现脏读。设置statement配置中的flushCache="true" 属性，默认情况下为true即刷新缓存，如果改成false则不会刷新。使用缓存时如果手动修改数据库表中的查询数据会出现脏读。
总结：一般下执行完commit操作都需要刷新缓存，flushCache=true表示刷新缓存，这样可以避免数据库脏读。
6、MyBatis中cache的参数
flushInterval（刷新间隔）可以被设置为任意的正整数，而且它们代表一个合理的毫秒形式的时间段。默认情况是不设置，也就是没有刷新间隔，缓存仅仅调用语句时刷新。
size（引用数目）可以被设置为任意正整数，要记住你缓存的对象数目和你运行环境的可用内存资源数目。默认值是1024。
readOnly（只读）属性可以被设置为true或false。只读的缓存会给所有调用者返回缓存对象的相同实例。因此这些对象不能被修改。这提供了很重要的性能优势。可读写的缓存会返回缓存对象的拷贝（通过序列化）。这会慢一些，但是安全，因此默认是false。
eviction属性回收策略，可用的收回策略有, 默认的是 LRU:
- LRU – 最近最少使用的:移除最长时间不被使用的对象。
- FIFO – 先进先出:按对象进入缓存的顺序来移除它们。
- SOFT – 软引用:移除基于垃圾回收器状态和软引用规则的对象。
- WEAK – 弱引用:更积极地移除基于垃圾收集器状态和弱引用规则的对象。
- MyBatis整合ehcache
EhCache 是一个纯Java的进程内缓存框架，是一种广泛使用的开源Java分布式缓存，具有快速、精干等特点，是Hibernate中默认的CacheProvider。
分布式缓存：
我们系统为了提高系统并发，性能、一般对系统进行分布式部署（集群部署方式）。
不使用分布缓存，缓存的数据在各各服务单独存储，不方便系统开发。所以要使用分布式缓存对缓存数据进行集中管理。mybatis无法实现分布式缓存，需要和其它分布式缓存框架进行整合。
1、MyBatis整合ehcache的原理
通过实现Cache接口可以实现mybatis缓存数据通过其它缓存数据库整合，mybatis的特长是sql操作，缓存数据的管理不是mybatis的特长，为了提高缓存的性能将mybatis和第三方的缓存数据库整合，比如ehcache、memcache、redis等。
2、引入jar包
3、引入ehcache的配置文件
classpath下添加：ehcache.xml
1 <ehcache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 2 xsi:noNamespaceSchemaLocation="../config/ehcache.xsd"> 3 <diskStore path="D:\ehcache" /> 4 <defaultCache 5 maxElementsInMemory="1000" 6 maxElementsOnDisk="10000000" 7 eternal="false" 8 overflowToDisk="false" 9 timeToIdleSeconds="120" 10 timeToLiveSeconds="120" 11 diskExpiryThreadIntervalSeconds="120" 12 memoryStoreEvictionPolicy="LRU"> 13 </defaultCache> 14 </ehcache>
属性说明：
diskStore：指定数据在磁盘中的存储位置。
defaultCache：当借助CacheManager.add("demoCache")创建Cache时，EhCache便会采用<defalutCache/>指定的的管理策略
以下属性是必须的：
maxElementsInMemory - 在内存中缓存的element的最大数目
maxElementsOnDisk - 在磁盘上缓存的element的最大数目，若是0表示无穷大
eternal - 设定缓存的elements是否永远不过期。如果为true，则缓存的数据始终有效，如果为false那么还要根据timeToIdleSeconds，timeToLiveSeconds判断
overflowToDisk - 设定当内存缓存溢出的时候是否将过期的element缓存到磁盘上
以下属性是可选的：
timeToIdleSeconds - 当缓存在EhCache中的数据前后两次访问的时间超过timeToIdleSeconds的属性取值时，这些数据便会删除，默认值是0,也就是可闲置时间无穷大
timeToLiveSeconds - 缓存element的有效生命期，默认是0.,也就是element存活时间无穷大
diskSpoolBufferSizeMB 这个参数设置DiskStore(磁盘缓存)的缓存区大小.默认是30MB.每个Cache都应该有自己的一个缓冲区.
diskPersistent - 在VM重启的时候是否启用磁盘保存EhCache中的数据，默认是false。
diskExpiryThreadIntervalSeconds - 磁盘缓存的清理线程运行间隔，默认是120秒。每个120s，相应的线程会进行一次EhCache中数据的清理工作
memoryStoreEvictionPolicy - 当内存缓存达到最大，有新的element加入的时候， 移除缓存中element的策略。默认是LRU（最近最少使用），可选的有LFU（最不常使用）和FIFO（先进先出）
4、开启ehcache缓存：
修改mapper.xml文件，在cache中指定EhcacheCache。
1 <cache type="org.mybatis.caches.ehcache.EhcacheCache"/>
根据需求调整缓存参数：
1 <cache type="org.mybatis.caches.ehcache.EhcacheCache" > 2 <property name="timeToIdleSeconds" value="3600"/> 3 <property name="timeToLiveSeconds" value="3600"/> 4 <!-- 同ehcache参数maxElementsInMemory --> 5 <property name="maxEntriesLocalHeap" value="1000"/> 6 <!-- 同ehcache参数maxElementsOnDisk --> 7 <property name="maxEntriesLocalDisk" value="10000000"/> 8 <property name="memoryStoreEvictionPolicy" value="LRU"/> 9 </cache>
应用场景：
对于访问多的查询请求且用户对查询结果实时性要求不高，此时可采用mybatis二级缓存技术降低数据库访问量，提高访问速度，业务场景比如：耗时较高的统计分析sql、电话账单查询sql等。实现方法如下：通过设置刷新间隔时间，由mybatis每隔一段时间自动清空缓存，根据数据变化频率设置缓存刷新间隔flushInterval，比如设置为30分钟、60分钟、24小时等，根据需求而定。
二级缓存的局限性：
因为MyBatis的二级缓存是根据namespace来划分的，如果涉及到多个表的数据的管理，如果其他namespace一个表的数据进行了更新，这也就会出现脏读数据。如果其他表进行了更新把所有涉及这个表的管理的缓存都清空，这也缓存的利用率就比较低。
mybatis二级缓存对细粒度的数据级别的缓存实现不好，比如如下需求：对商品信息进行缓存，由于商品信息查询访问量大，但是要求用户每次都能查询最新的商品信息，此时如果使用mybatis的二级缓存就无法实现当一个商品变化时只刷新该商品的缓存信息而不刷新其它商品的信息，因为mybaits的二级缓存区域以mapper为单位划分，当一个商品信息变化会将所有商品信息的缓存数据全部清空。解决此类问题需要在业务层根据需求对数据有针对性缓存。