MyBatis缓存机制全解析:一级缓存VS二级缓存
mhr18 2025-05-09 20:04 3 浏览 0 评论
MyBatis作为Java生态中最受欢迎的ORM框架之一,其缓存机制是提升数据库访问性能的关键。本文将深入剖析MyBatis的一级缓存和二级缓存,通过代码示例展示它们的实现方式,帮助开发者合理利用缓存优化应用性能。
一、MyBatis缓存机制概述
MyBatis提供了两级缓存设计:
- 一级缓存:SqlSession级别的缓存,默认开启
- 二级缓存:Mapper级别的缓存,需要手动配置
graph TD
A[客户端] --> B[一级缓存]
B --> C[二级缓存]
C --> D[数据库]
二、一级缓存深度解析
1. 一级缓存原理
一级缓存是SqlSession级别的缓存,当同一个SqlSession中执行相同的SQL时,MyBatis会优先从缓存中获取结果,而不是直接查询数据库。
特点:
- 默认开启,无法关闭
- 基于PerpetualCache实现(HashMap存储)
- 作用域为SqlSession
- 执行update/insert/delete或commit/close操作时会清空缓存
2. 一级缓存代码验证
// 测试一级缓存
@Test
public void testFirstLevelCache() {
SqlSession sqlSession = sqlSessionFactory.openSession();
try {
UserMapper mapper = sqlSession.getMapper(UserMapper.class);
// 第一次查询,会访问数据库
User user1 = mapper.selectById(1L);
System.out.println("第一次查询: " + user1);
// 第二次查询相同数据,直接从一级缓存获取
User user2 = mapper.selectById(1L);
System.out.println("第二次查询: " + user2);
// 修改操作会清空一级缓存
user1.setName("新名字");
mapper.update(user1);
// 第三次查询,缓存已清空,会再次访问数据库
User user3 = mapper.selectById(1L);
System.out.println("第三次查询: " + user3);
} finally {
sqlSession.close();
}
}
3. 一级缓存失效场景
- SqlSession不同:每个SqlSession有独立的一级缓存
- SqlSession相同,查询条件不同:缓存的是SQL+参数
- SqlSession相同,两次查询之间执行了增删改操作
- SqlSession相同,手动清空缓存:调用sqlSession.clearCache()
三、二级缓存全面剖析
1. 二级缓存原理
二级缓存是Mapper级别的缓存,多个SqlSession可以共享同一个Mapper的二级缓存。
特点:
- 默认关闭,需要手动开启
- 基于namespace级别(一个Mapper一个缓存)
- 可自定义缓存实现(如Ehcache、Redis等)
- 执行insert/update/delete操作会清空缓存
2. 二级缓存配置与使用
步骤1:全局开启二级缓存
<settings>
<setting name="cacheEnabled" value="true"/>
</settings>
步骤2:在Mapper.xml中配置缓存
<mapper namespace="com.example.mapper.UserMapper">
<cache eviction="FIFO" flushInterval="60000" size="512" readOnly="true"/>
<!-- 其他SQL配置 -->
</mapper>
缓存属性说明:
- eviction:缓存回收策略(LRU/FIFO/SOFT/WEAK)
- flushInterval:刷新间隔(毫秒)
- size:引用数目
- readOnly:是否只读
步骤3:实体类实现Serializable接口
public class User implements Serializable {
// 属性和方法
}
3. 二级缓存代码验证
// 测试二级缓存
@Test
public void testSecondLevelCache() {
SqlSession sqlSession1 = sqlSessionFactory.openSession();
SqlSession sqlSession2 = sqlSessionFactory.openSession();
try {
UserMapper mapper1 = sqlSession1.getMapper(UserMapper.class);
UserMapper mapper2 = sqlSession2.getMapper(UserMapper.class);
// 第一个SqlSession查询,会访问数据库
User user1 = mapper1.selectById(1L);
System.out.println("SqlSession1第一次查询: " + user1);
sqlSession1.close(); // 必须关闭SqlSession才会将缓存写入二级缓存
// 第二个SqlSession查询相同数据,从二级缓存获取
User user2 = mapper2.selectById(1L);
System.out.println("SqlSession2第一次查询: " + user2);
// 执行更新操作会清空二级缓存
user2.setName("修改后的名字");
mapper2.update(user2);
sqlSession2.commit();
SqlSession sqlSession3 = sqlSessionFactory.openSession();
UserMapper mapper3 = sqlSession3.getMapper(UserMapper.class);
// 再次查询,缓存已清空,会访问数据库
User user3 = mapper3.selectById(1L);
System.out.println("SqlSession3第一次查询: " + user3);
sqlSession3.close();
} finally {
sqlSession2.close();
}
}
4. 二级缓存使用注意事项
- 事务性问题:二级缓存可能导致脏读,建议在查询多、修改少的场景使用
- 序列化要求:缓存对象必须实现Serializable接口
- 缓存策略选择:根据业务特点选择合适的回收策略
- 缓存共享问题:集群环境下需要使用集中式缓存(如Redis)
四、一级缓存与二级缓存对比
特性 | 一级缓存 | 二级缓存 |
作用域 | SqlSession级别 | Mapper级别 |
默认状态 | 开启 | 关闭 |
存储结构 | HashMap | 可配置(默认PerpetualCache) |
共享性 | 不能共享 | 可以共享 |
清空时机 | update/commit/close | update/commit |
适用场景 | 单会话重复查询 | 多会话共享数据查询 |
五、缓存最佳实践
- 合理使用缓存:对于频繁查询但很少修改的数据使用二级缓存
- 控制缓存大小:避免缓存占用过多内存
- 考虑数据一致性:对实时性要求高的数据慎用缓存
- 结合第三方缓存:在高并发场景下可集成Redis等分布式缓存
- 监控缓存命中率:定期检查缓存效果,调整策略
六、自定义缓存实现
MyBatis支持集成第三方缓存,例如Ehcache:
<cache type="org.mybatis.caches.ehcache.EhcacheCache"/>
Redis集成示例:
public class RedisCache implements Cache {
private final String id;
private JedisPool jedisPool;
public RedisCache(String id) {
this.id = id;
// 初始化Redis连接池
}
// 实现Cache接口方法
// ...
}
结语
MyBatis的缓存机制是提升应用性能的有效手段,理解并合理使用一级缓存和二级缓存,可以显著减少数据库访问压力。开发者应根据实际业务场景,选择合适的缓存策略,并注意缓存带来的数据一致性问题。
掌握MyBatis缓存原理,让你的应用性能飞起来!
相关推荐
- Redis合集-使用benchmark性能测试
-
采用开源Redis的redis-benchmark工具进行压测,它是Redis官方的性能测试工具,可以有效地测试Redis服务的性能。本次测试使用Redis官方最新的代码进行编译,详情请参见Redis...
- Java简历总被已读不回?面试挂到怀疑人生?这几点你可能真没做好
-
最近看了几十份简历,发现大部分人不是技术差,而是不会“卖自己”——一、简历死穴:你写的不是经验,是岗位说明书!反面教材:ד使用SpringBoot开发项目”ד负责用户模块功能实现”救命写法:...
- redission YYDS(redission官网)
-
每天分享一个架构知识Redission是一个基于Redis的分布式Java锁框架,它提供了各种锁实现,包括可重入锁、公平锁、读写锁等。使用Redission可以方便地实现分布式锁。red...
- 从数据库行锁到分布式事务:电商库存防超卖的九重劫难与破局之道
-
2023年6月18日我们维护的电商平台在零点刚过3秒就遭遇了严重事故。监控大屏显示某爆款手机SKU_IPHONE13_PRO_MAX在库存仅剩500台时,订单系统却产生了1200笔有效订单。事故复盘发...
- SpringBoot系列——实战11:接口幂等性的形而上思...
-
欢迎关注、点赞、收藏。幂等性不仅是一种技术需求,更是数字文明对确定性追求的体现。在充满不确定性的网络世界中,它为我们建立起可依赖的存在秩序,这或许正是技术哲学最深刻的价值所在。幂等性的本质困境在支付系...
- 如何优化系统架构设计缓解流量压力提升并发性能?Java实战分享
-
如何优化系统架构设计缓解流量压力提升并发性能?Java实战分享在高流量场景下。首先,我需要回忆一下常见的优化策略,比如负载均衡、缓存、数据库优化、微服务拆分这些。不过,可能还需要考虑用户的具体情况,比...
- Java面试题: 项目开发中的有哪些成长?该如何回答
-
在Java面试中,当被问到“项目中的成长点”时,面试官不仅想了解你的技术能力,更希望看到你的问题解决能力、学习迭代意识以及对项目的深度思考。以下是回答的策略和示例,帮助你清晰、有说服力地展示成长点:一...
- 互联网大厂后端必看!Spring Boot 如何实现高并发抢券逻辑?
-
你有没有遇到过这样的情况?在电商大促时,系统上线了抢券活动,结果活动刚一开始,服务器就不堪重负,出现超卖、系统崩溃等问题。又或者用户疯狂点击抢券按钮,最后却被告知无券可抢,体验极差。作为互联网大厂的后...
- 每日一题 |10W QPS高并发限流方案设计(含真实代码)
-
面试场景还原面试官:“如果系统要承载10WQPS的高并发流量,你会如何设计限流方案?”你:“(稳住,我要从限流算法到分布式架构全盘分析)…”一、为什么需要限流?核心矛盾:系统资源(CPU/内存/数据...
- Java面试题:服务雪崩如何解决?90%人栽了
-
服务雪崩是指微服务架构中,由于某个服务出现故障,导致故障在服务之间不断传递和扩散,最终造成整个系统崩溃的现象。以下是一些解决服务雪崩问题的常见方法:限流限制请求速率:通过限流算法(如令牌桶算法、漏桶算...
- 面试题官:高并发经验有吗,并发量多少,如何回复?
-
一、有实际高并发经验(建议结构)直接量化"在XX项目中,系统日活用户约XX万,核心接口峰值QPS达到XX,TPS处理能力为XX/秒。通过压力测试验证过XX并发线程下的稳定性。"技术方案...
- 瞬时流量高并发“保命指南”:这样做系统稳如泰山,老板跪求加薪
-
“系统崩了,用户骂了,年终奖飞了!”——这是多少程序员在瞬时大流量下的真实噩梦?双11秒杀、春运抢票、直播带货……每秒百万请求的冲击,你的代码扛得住吗?2025年了,为什么你的系统一遇高并发就“躺平”...
- 其实很多Java工程师不是能力不够,是没找到展示自己的正确姿势。
-
其实很多Java工程师不是能力不够,是没找到展示自己的正确姿势。比如上周有个小伙伴找我,五年经验但简历全是'参与系统设计''优化接口性能'这种空话。我就问他:你做的秒杀...
- PHP技能评测(php等级考试)
-
公司出了一些自我评测的PHP题目,现将题目和答案记录于此,以方便记忆。1.魔术函数有哪些,分别在什么时候调用?__construct(),类的构造函数__destruct(),类的析构函数__cal...
- 你的简历在HR眼里是青铜还是王者?
-
你的简历在HR眼里是青铜还是王者?兄弟,简历投了100份没反应?面试总在第三轮被刷?别急着怀疑人生,你可能只是踩了这些"隐形求职雷"。帮3630+程序员改简历+面试指导和处理空窗期时间...
你 发表评论:
欢迎- 一周热门
- 最近发表
- 标签列表
-
- oracle位图索引 (63)
- oracle批量插入数据 (62)
- oracle事务隔离级别 (53)
- oracle 空为0 (50)
- oracle主从同步 (55)
- oracle 乐观锁 (51)
- redis 命令 (78)
- php redis (88)
- redis 存储 (66)
- redis 锁 (69)
- 启动 redis (66)
- redis 时间 (56)
- redis 删除 (67)
- redis内存 (57)
- redis并发 (52)
- redis 主从 (69)
- redis 订阅 (51)
- redis 登录 (54)
- redis 面试 (58)
- 阿里 redis (59)
- redis 搭建 (53)
- redis的缓存 (55)
- lua redis (58)
- redis 连接池 (61)
- redis 限流 (51)