MyBatis 二级缓存脏读真实原因

很多同学熟悉 MyBatis 一级缓存、二级缓存基础用法但多表联查、跨Mapper更新场景下的缓存脏读漏洞90%的人都会踩坑。本文结合完整实战案例用大白话拆解脏读如何产生、一级缓存二级缓存双重隐患、Namespace隔离缺陷最后给出官方解决方案与企业级最佳实践可直接面试背诵、项目避坑。一、业务场景前置说明1. 业务数据表设计本次案例涉及两张关联表模拟日常一对多/关联业务场景表名业务作用初始测试数据dept部门基础信息表部门名ali、地址hzdeptNum部门人数统计表部门名ali、员工人数10502. Mapper 与 Namespace 隔离规则MyBatis 二级缓存核心特性以 Mapper 命名空间 Namespace 为单位独立隔离不同 Mapper 缓存相互独立、互不干扰。- DeptDao.xml负责多表关联查询同时查询部门信息部门人数- DeptNumDao.xml负责单表更新仅修改部门人数字段核心关键联查SQL 在 DeptDao 命名空间更新SQL 在 DeptNumDao 命名空间两个Mapper 属于不同Namespace。关联查询 SQLDeptDaoselect d.deptno,d.dname,d.loc,dn.numfrom dept d, deptNum dnwhere dn.name d.dname and d.dname #{name}人数更新 SQLDeptNumDaoupdate deptNum set num #{num} where name #{dname}二、官方必考MyBatis 完整缓存查询顺序标准答案这是 MyBatis 官方规定的固定查询优先级死记硬背1.先查询二级缓存跨SqlSession、Mapper全局缓存2. 二级缓存未命中 →再查询一级缓存当前SqlSession本地缓存3. 一级缓存也未命中 →最终查询数据库关键规则一级缓存的数据必须执行 commit / close / flush 操作才会同步到二级缓存中不执行这三个操作二级缓存永远是空的三、完整业务执行流程步骤1第一次查询数据仅存入一级缓存// 开启第一个SqlSessionSqlSession sqlSession factory.openSession();DeptDao deptDao sqlSession.getMapper(DeptDao.class);// 关联查询部门人数数据DeptVo deptVo deptDao.selectByDeptVo(ali);System.out.println(deptVo deptVo);执行流程1. 首次查询二级缓存为空→ 未命中2. 查询一级缓存→ 为空 → 未命中3. 访问数据库查询结果ali部门人数 10504. 数据仅存入当前SqlSession一级缓存5.致命重点该SqlSession 全程没有关闭、没有commit提交、没有flush刷新→一级缓存数据永远无法同步到二级缓存✅ 一级缓存存有旧数据❌ 二级缓存完全为空步骤2跨Mapper更新数据库数据// 开启全新第二个SqlSessionSqlSession sqlSession2 factory.openSession();DeptNumDao deptDao2 sqlSession2.getMapper(DeptNumDao.class);// 修改ali部门人数为 1000deptDao2.updateDeptVoNum(new DeptVo(ali,1000));// 提交事务数据库数据已真实修改sqlSession2.commit();// 关闭当前会话sqlSession2.close();执行流程1. 执行更新语句数据库deptNum人数永久修改为 10002. 更新操作归属DeptNumDao命名空间3. MyBatis 只会清空当前Namespace二级缓存4. 完全不会清理DeptDao的缓存数据。步骤3二次查询产生脏读// 复用【第一个未关闭的SqlSession】再次查询deptVo deptDao.selectByDeptVo(ali);System.out.println(deptVo deptVo);现象数据库人数已经是 1000但代码查询结果依旧是1050。明明数据已经更新却查不到最新结果这就是典型的缓存脏读。四、深度剖析脏读产生两大核心原因原因1二级缓存为空 命中一级缓存最直接、最核心原因结合官方缓存查询顺序完整闭环解释1. 二次查询先走二级缓存→ 因为没commit/close二级缓存一直是空的→ 未命中2. 按照顺序继续走一级缓存→ 缓存里有旧数据1050→命中3. 直接返回一级缓存的旧数据不会查询数据库4. 日志中Cache Hit Ratio: 0.0证明二级缓存命中率0本身就无数据简单总结没提交、没关闭 → 数据进不了二级缓存 → 二级缓存空 → 查询走一级缓存 → 脏数据诞生原因2二级缓存 Namespace 隔离缺陷就算手动关闭第一个SqlSession把一级缓存刷入二级缓存脏读依旧存在1. 联查结果缓存存放在DeptDao二级缓存2. 更新操作只清空DeptNumDao二级缓存3. 跨Namespace 的更新无法触发其他Mapper缓存清空4. 多表联查场景下不同表操作分散在不同Mapper缓存完全无法联动。致命问题多表关联业务一旦增删改和查询不在同一个 NamespaceMyBatis原生二级缓存必然脏读。五、官方解决方案cache-ref 共享缓存1. 标签作用MyBatis 提供cache-ref标签用于多个Mapper共享同一个二级缓存。打破 Namespace 独立隔离限制让多个命名空间共用一块缓存区域。2. 使用方式在需要联动的 Mapper 中引入对方的缓存命名空间!-- 在 DeptDao.xml 中配置 --cache-ref namespacecom.mybatis.dao.DeptNumDao/含义DeptDao 放弃独立二级缓存直接共用 DeptNumDao 的缓存。3、解决原理1. 当DeptNumDao执行更新操作时会清空公共缓存2. 关联查询的 DeptDao 共用此缓存缓存同步失效3. 下次查询缓存不存在自动访问数据库读取最新数据4. 彻底解决跨 Mapper 更新导致的缓存不同步问题。六、方案优缺点 企业级选型1. cache-ref 方案优缺点✅ 优点- MyBatis 原生自带无需引入第三方组件- 配置简单少量代码即可解决跨命名空间脏读❌ 缺点- 只适用于简单关联业务- 项目模块复杂、多表错综复杂时缓存耦合严重难以维护- 依旧无法解决分布式环境下多服务缓存同步问题。2. 企业级主流最佳实践绝大多数互联网/企业项目直接禁用 MyBatis自带二级缓存1. 原生二级缓存基于本地内存分布式部署下多服务缓存不互通2. Namespace 隔离机制导致联查场景大量脏读3. 事务、缓存刷新机制复杂线上问题难排查统一替换方案使用 Redis / Redisson 实现分布式业务缓存- 手动控制缓存存入、过期、主动删除- 跨服务、跨模块数据统一缓存管理- 灵活性更高、数据一致性更强、线上问题更好排查。七、核心总结面试满分版1.MyBatis 缓存查询顺序官方标准答案二级缓存 → 一级缓存 → 数据库2.缓存同步规则一级缓存数据只有执行commit / close / flush才会写入二级缓存3.本次脏读根源SqlSession 未提交/关闭 → 数据只在一级缓存 → 二级缓存为空 → 查询命中一级缓存旧数据4.二级缓存缺陷基于Namespace隔离跨Mapper更新无法联动清空缓存5.临时解决方案使用cache-ref共享缓存打破命名空间隔离6.生产环境规范禁用 MyBatis 原生二级缓存统一使用 Redis 分布式缓存。