Java高级面试专题-spring-mybatis面试的各种坑

为什么 Spring 整合后 MyBatis 的一级缓存就废了

很多开发者背面试题时，张口就来 MyBatis 有两级缓存，一级缓存默认开启，二级缓存需要配置。但在 Spring 环境下，这套说辞往往会在追问中瞬间露馅。面试官真正想考察的，不是你能不能背出概念，而是你有没有真正搭建过环境，验证过整合后的缓存状态。这门课直指的痛点正是这个：脱离纯理论，从实际框架运行机制出发，拆解 MyBatis 缓存在 Spring 整合场景下发生的机制变异。如果你对底层源码缺乏探究，或者一直搞不懂为什么本地测试没走缓存，这门课能帮你把缺失的这块拼图补上。

必须先搞透的缓存失效与避坑逻辑

这门课的基础门槛并不高，但要求你有过实际排查经验。建议具备基本的 MyBatis 和 Spring 使用能力，能独立写完增删改查。学习时不要跳过开头的构建环境环节，直接看结论。很多人之所以记不住失效原因，就是因为没有跟着手敲一遍测试用例。重点要先看一级缓存失效原因这块，理解 Spring 框架对 SqlSession 的生命周期管理机制，弄清每次调用如何导致缓存无法复用。接着带着疑问去学二级缓存存在的问题，不要只记它会导致脏读，要弄明白在多表联查和分布式场景下，二级缓存为什么不仅解决不了性能瓶颈，反而会引发更严重的数据一致性问题。课程里给出的避免方案，必须结合你自己的业务场景去推导，看看是否真的适用，而不是死记硬背。

学完能独立排查什么问题以及资料怎么练

看完这些内容，你应该能独立回答几个硬核问题：Spring 整合 MyBatis 后，一级缓存到底还存不存在？为什么在同一个事务里有时候缓存生效，有时候又失效？二级缓存的致命缺陷是什么，实际项目中到底该不该开？资料包里的代码目录不是用来收藏的，必须全部拉取到本地跑通。练习方法是：先在纯 MyBatis 环境下复现一级缓存命中，再引入 Spring 依赖，对比控制台日志，观察 SqlSession 的创建次数。针对二级缓存，自己构造一个跨表更新的测试用例，亲手触发一次脏读，然后再用课程里提到的方案去修复它。只有把坑踩在本地，面试时遇到这些连环追问，你才能从底层机制聊到业务取舍，而不是干巴巴地背八股文。