概述
使用缓存可以使应用更快的获取数据，避免频繁的数据库交互，尤其是在查询越多、缓存命中率越高的情况下，使用缓存的作用就越明显。
MyBatis作为持久化框架，提供了非常强大的查询缓存特性，可以非常方便的配置和定制使用。
一般提到MyBatis的缓存，都是指二级缓存。 一级缓存（也叫本地缓存）默认会启用，并且不能控制，因此很少提到， 这里仅仅是介绍下一级缓存，了解一级缓存可以避免产生一些难以发现的错误。 作为了解即可。
一级缓存
话不多少，直接上代码演示一级缓存如何起作用的
package com.artisan.mybatis.xml.mapper; import org.apache.ibatis.session.SqlSession; import org.junit.Assert; import org.junit.Test; import com.artisan.mybatis.xml.domain.SysUser; /** * * * @ClassName: CacheL1Test * * @Description: 一级缓存设置 * * @author: Mr.Yang * * @date: 2018年5月3日 上午12:06:05 */ public class CacheL1Test extends BaseMapperTest { @Test public void cacheL1Test() { // 获取SqlSession SqlSession sqlSession = getSqlSession(); SysUser sysUser1 = null; try { // 获取UserMapper接口 UserMapper userMapper = sqlSession.getMapper(UserMapper.class); // 调用接口方法,查询sysUser sysUser1 = userMapper.selectSysUserById(1L); // 对当前获取的对象重新赋值 sysUser1.setUserName("New Name"); System.out.println("再次查询id相同的sysUser Begin"); // 再次查询id相同的sysUser，确保和上个查询 方法和参数相同 SysUser sysUser2 = userMapper.selectSysUserById(1L); System.out.println("再次查询id相同的sysUser End"); // 虽然么有更新数据库，但是这个用户名和sysUser1重新赋值的名字相同 Assert.assertEquals("New Name", sysUser2.getUserName()); // 无论如何，sysUser1 和 sysUser2 完全就是同一个实例 Assert.assertEquals(sysUser1, sysUser2); } finally { // 关闭SqlSession sqlSession.clearCache(); } System.out.println("【---------------开启新的SqlSession---------------】"); // 获取一个新的SqlSession sqlSession = getSqlSession(); try { // 获取UserMapper接口 UserMapper userMapper = sqlSession.getMapper(UserMapper.class); // 调用接口方法,查询sysUser SysUser sysUser3 = userMapper.selectSysUserById(1L); // 第二个sqlSession获取的用户仍然是admin Assert.assertNotEquals("New Name", sysUser3.getUserName()); // 这里的sysUser3 和 第一个sqlSession中的sysUser1是两个不同的实例 Assert.assertNotEquals(sysUser1, sysUser3); // 执行删除操作 userMapper.deleteSysUserById(2L); System.out.println("执行删除操作后，再次查询id相同的sysUser Begin"); // 获取 sysUser4 ，确保和上个查询 方法和参数相同 SysUser sysUser4 = userMapper.selectSysUserById(1L); System.out.println("执行删除操作后，再次查询id相同的sysUser End"); // 这里sysUser3和sysUser4是两个不同的实例 Assert.assertNotEquals(sysUser3, sysUser4); } finally { // 关闭SqlSession sqlSession.clearCache(); } } }
结合日志一起分析下
2018-05-03 01:12:18,933 INFO [main] (BaseMapperTest.java:26) - sessionFactory bulit successfully 2018-05-03 01:12:18,937 INFO [main] (BaseMapperTest.java:29) - reader close successfully 2018-05-03 01:12:19,075 DEBUG [main] (BaseJdbcLogger.java:145) - ==> Preparing: select a.id, a.user_name, a.user_password, a.user_email, a.user_info, a.head_img, a.create_time from sys_user a where id = ? 2018-05-03 01:12:19,253 DEBUG [main] (BaseJdbcLogger.java:145) - ==> Parameters: 1(Long) 2018-05-03 01:12:19,316 TRACE [main] (BaseJdbcLogger.java:151) - <== Columns: id, user_name, user_password, user_email, user_info, head_img, create_time 2018-05-03 01:12:19,317 TRACE [main] (BaseJdbcLogger.java:151) - <== Row: 1, admin, 123456, admin@artisan.com, <<BLOB>>, <<BLOB>>, 2018-04-13 21:12:47.0 2018-05-03 01:12:19,325 DEBUG [main] (BaseJdbcLogger.java:145) - <== Total: 1 再次查询id相同的sysUser Begin 再次查询id相同的sysUser End 【---------------开启新的SqlSession---------------】 2018-05-03 01:12:19,343 DEBUG [main] (BaseJdbcLogger.java:145) - ==> Preparing: select a.id, a.user_name, a.user_password, a.user_email, a.user_info, a.head_img, a.create_time from sys_user a where id = ? 2018-05-03 01:12:19,344 DEBUG [main] (BaseJdbcLogger.java:145) - ==> Parameters: 1(Long) 2018-05-03 01:12:19,347 TRACE [main] (BaseJdbcLogger.java:151) - <== Columns: id, user_name, user_password, user_email, user_info, head_img, create_time 2018-05-03 01:12:19,348 TRACE [main] (BaseJdbcLogger.java:151) - <== Row: 1, admin, 123456, admin@artisan.com, <<BLOB>>, <<BLOB>>, 2018-04-13 21:12:47.0 2018-05-03 01:12:19,352 DEBUG [main] (BaseJdbcLogger.java:145) - <== Total: 1 2018-05-03 01:12:19,353 DEBUG [main] (BaseJdbcLogger.java:145) - ==> Preparing: delete from sys_user where id = ? 2018-05-03 01:12:19,354 DEBUG [main] (BaseJdbcLogger.java:145) - ==> Parameters: 2(Long) 2018-05-03 01:12:19,356 DEBUG [main] (BaseJdbcLogger.java:145) - <== Updates: 0 执行删除操作后，再次查询id相同的sysUser Begin 2018-05-03 01:12:19,357 DEBUG [main] (BaseJdbcLogger.java:145) - ==> Preparing: select a.id, a.user_name, a.user_password, a.user_email, a.user_info, a.head_img, a.create_time from sys_user a where id = ? 2018-05-03 01:12:19,362 DEBUG [main] (BaseJdbcLogger.java:145) - ==> Parameters: 1(Long) 2018-05-03 01:12:19,364 TRACE [main] (BaseJdbcLogger.java:151) - <== Columns: id, user_name, user_password, user_email, user_info, head_img, create_time 2018-05-03 01:12:19,365 TRACE [main] (BaseJdbcLogger.java:151) - <== Row: 1, admin, 123456, admin@artisan.com, <<BLOB>>, <<BLOB>>, 2018-04-13 21:12:47.0 2018-05-03 01:12:19,368 DEBUG [main] (BaseJdbcLogger.java:145) - <== Total: 1 执行删除操作后，再次查询id相同的sysUser End
可以看到在第一个sqlSession中，第一次执行selectSysUserById获取SysUser数据的时候，到数据库里执行了SQL获取sysUser1。 第二次获取sysUser2的时候，从日志来看
再次查询id相同的sysUser Begin 再次查询id相同的sysUser End
中间并没有任何到数据库查询用户的操作。
从测试的代码看，获取sysUser1后重新设置了userName，之后没有进行任何更新数据库的操作。 在获取susUser2对象后，发现sysUser2对象的userName的值竟然和sysUse1重新设置后的值一样，再往下继续看，原来sysUser1和sysUse2竟然是同一个对象，之所以是这样就是因为MyBatis的一级缓存。
MyBatis的一级缓存存在于SqlSession的生命周期中，在同一个sqlSession中查询时，MyBatis会把执行的方法和参数通过算法生成缓存的键值，将键值和查询结果一起放入Map对象中。 如果同一个SqlSession中执行的方法和参数完全一致，那么通过算法会生成相同的键值。 当Map缓存对象中已经存在该键值时，则会返回缓存中的对象。
缓存中的对象和我们得到的结果是同一个对象那个，反复使用相同参数执行同一个方法时，总是返回同一个对象。
如果不想让selectSysUserById使用一级缓存，可以做如下调整
<select id="selectSysUserById" flushCache="true" resultMap="userMap"> select a.id, a.user_name, a.user_password, a.user_email, a.user_info, a.head_img, a.create_time from sys_user a where id = #{id} </select>
flushCache="true"后，每次在查询数据前都会清空当前的以及缓存，因此该方法每次都会从数据库中查询，此时sysUser1, sysUser2就是两个不同的实例了。 要避免这样使用，会增加数据库的负担。
在关闭第一个SqlSession后了重新获取了一个SqlSession，因此有重新查询了sysUser3，这时日志中输出了数据库的查询SQL，sysUser3是一个新的实例，和 sysUser1没有任何关系。 因为一级缓存是和SqlSession绑定的，只存在与SqlSession的生命周期中。
接下来执行deleteSysUserById操作，然后使用相同的方法和参数获取了sysUser4。从日志和结果看，sysUser3和sysUser4是完全不同的两个对象。 因为任何的insert update delete 操作都会清空一级缓存，所以查询sysUser4时由于缓存不存在，就会再次之星数据库的查询操作。
关于一级缓存的跟踪情况，通过上面的示例介绍完了，由于一级缓存是在默默的工作，因此要避免在使用过程中由于不了解而发生察觉不到的错误。
