记一次 Mybatis 一级缓存清理无效引发的源码走读

今天对象在学习 Mybatis 时发现 org.apache.ibatis.session.SqlSession 对象的 clearCache() 方法并不能清理一级缓存, 同一 session 下相同查询条件返回的结果仍是旧值。测试代码以下

上网搜索

网上搜索找到了相同问题, 并无人解答。例如：https://www.iqismart.com/topi...

查看官方文档

http://www.mybatis.org/mybati...

SqlSession 实例有一个本地缓存在执行 update,commit,rollback 和 close 时被清理。要明确地关闭它(获取打算作更多的工做) ,你能够调用 clearCache()。

看起来, 没什么问题, 方法也没有被标记成废弃.

打印详细日志

先把日志配上, 看看有没有打印什么有用的信息, 添加 slf4j、logback 依赖,添加 logback.xml , 日志级别设置为 DEBUG 运行后未看到跟清理缓存有关的信息, 调整日志级别为 TRACE 后依旧没有.

<configuration>
    <contextName>mybatis</contextName>
    <appender name="stdout" class="ch.qos.logback.core.ConsoleAppender">
        <encoder>
            <pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger %msg%n</pattern>
        </encoder>
    </appender>
    <appender name="file" class="ch.qos.logback.core.FileAppender">
        <file>mybatis.log</file>
        <encoder>UTF-8</encoder>
        <encoder>
            <pattern>%d{YYYY-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern>
        </encoder>
    </appender>
    <root level="TRACE">
        <appender-ref ref="stdout"/>
        <appender-ref ref="file"/>
    </root>
</configuration>

看 clearCache() 源码

上面方法都没有收获, 只能看源码了.第一步, 先看一下 clearCache() 作了什么, 下面会大规模贴图

注意 PerpetualCache 类的 cache 变量

org.apache.ibatis.cache.impl.PerpetualCache#cache 就是一个 HashMap

到此, clearCache() 已经完结, 最终就是调用一个 HashMap 的 clear() 方法

看 selectOne() 源码

这一步没有什么好看的, 就是封一层 selectList

第一个方法会间接调用第二个, 只是少了一个分页相关的 RowBounds
把传入的 statement 值变成 MappedStatement, 因为不是咱们查看源码的重点, 能够直接跳过.

不过能够学习到 Mybatis 实际上是把咱们写的 xml 文件抽象成 MappedStatement , 在执行 sql 时须要先使用 statement (也就是咱们 xml 中 select 标签中的 id) 去配置中 get 出整个 MappedStatement, MappedStatement 包含了 resultMaps 之类的, 一下子 sql 返回时映射结果集极可能要用到.

这一步把 MappedStatement 变成 BoundSql, BoundSql 应该就是每条 SQL 的抽象.

还会根据 MappedStatement (xml 文件)、parameter (sql 参数)、rowBounds (分页信息)、BoundSql (SQL) 生成一个 CacheKey (缓存 key) .

已经跟咱们想要了解的东西沾点边了.

这一步是取 MappedStatement 对象的 Cache , 暂时不知道是什么缓存(多是二级缓存), 能够知道的是和刚才看 clearCache() 清理的不是同一个东西. 调试发现返回值是 null, 不关心继续往下看

这里到了 BaseExecutor 类, 152 行会根据 CacheKey 从 localCache 获取结果.
并且和 clearCache() 方法清理的是同一个缓存对象.
基本能够肯定 Mybatis 就是在这里从一级缓存获取结果后返回, 须要重点关注.

阶段性成果

反复运行发现以下规律：

• 若是第二次查询前不加 sqlSession.clearCache(); 能够从 localCache get 出结果
• 若是第二次查询前加 sqlSession.clearCache(); localCache get 结果为空

由此能够得出结论:

sqlSession.clearCache() 方法是有效的, 清理一级缓存后第二次查询结果依然和第一次相同, 和 Mybatis 一级缓存并没有关系.

既然如此, 要想知道结果, 只能继续往下跟踪, 看一级缓存为空后, Mybatis 是怎么处理的.

能够看出, 为空后调用了 queryFromDatabase 方法,从方法名能够理解, 会去数据库查询

第 322 行先往一级缓存设置一个占位符, 并没有实际含义
第 324 行执行查询动做, 须要重点关注
第 326 行根据缓存 key 清理一级缓存
第 328 行从新设置一级缓存
第 330 行看到一个面熟的东西, 在 clearCache() 时会同时清理 localCache 和 localOutputParameterCache, 若是执行的是存储过程, 会把参数缓存起来

继续跟踪 doQuery 方法

先是获取 MappedStatement 的配置, 建立一个 StatementHandler, 加工成 JDBC 标准的 Statement , 这中间隐藏了无数细节, 仍是那句话, 不是咱们关心的重点, 继续跟踪 Query 方法

通过 RoutingStatementHandler 路由分发, 到达 SimpleStatementHandler

方法体只有三行
第一行拿出具体 SQL
第二行调用 statement.execute() 方法, 这里已经到了 JDBC 驱动层, mysql 驱动包会帮咱们封装请求包发送给 mysql 服务器并把响应结果映射到 jdbc 规范的对象中
第三行处理返回结果集

其实执行完 execute 方法, 就能够从 PreparedStatement 对象 get 出想要的结果集, 但贸然 get 会影响 Mybatis 处理, 仍是继续跟踪 handleResultSets 方法吧

方法一开始声明了一个 multipleResults , 这个就是最终的结果集.
接着分别处理 ResultMap 和 ResultSet, 把 mysql 返回的结果按照 xml 中的规则映射成指定对象
因为 xml 中的 select 并无定义 resultSets , 只关注上半部分便可, 断点设在 198 行

能够看出 mysql 服务器返回的确实是旧值,

阶段性成果

至此能够肯定一级缓存清理无效的问题和应用没有关系.

还能是什么问题呢, 难道是事务的隔离级别致使的, 应用只是简单的查询, 连事务管理器都没有配置, 要有问题也只能怀疑 mysql 服务器.

查询数据库的默认隔离级别

mysql> SELECT @@global.tx_isolation;
+-----------------------+
| @@global.tx_isolation |
+-----------------------+
| REPEATABLE-READ       |
+-----------------------+
1 row in set, 1 warning (0.00 sec)

mysql> SELECT @@session.tx_isolation;
+------------------------+
| @@session.tx_isolation |
+------------------------+
| REPEATABLE-READ        |
+------------------------+
1 row in set, 1 warning (0.00 sec)

mysql> SELECT @@tx_isolation;
+-----------------+
| @@tx_isolation  |
+-----------------+
| REPEATABLE-READ |
+-----------------+
1 row in set, 1 warning (0.00 sec)

居然是"可重复读", 好了, 缘由找到, 此贴终结.

解决

解决办法就是把事务的默认隔离级别设置成 "读已提交".

mysql> SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;
Query OK, 0 rows affected (0.00 sec)

mysql> SET GLOBAL TRANSACTION ISOLATION LEVEL READ COMMITTED;
Query OK, 0 rows affected (0.00 sec)