MyBatis缓存机制深度解析与实践指南

1. 缓存基础概念与MyBatis缓存体系

1.1 缓存本质与价值

缓存本质上是用空间换时间的典型实践。作为存储在内存中的临时数据集合，其核心价值在于解决计算机系统中不同层级组件间的速度差异问题。在数据库访问场景中，磁盘I/O操作通常需要4-10ms，而内存访问仅需100ns左右，两者存在5个数量级的性能差距。

现代服务器内存配置普遍达到64GB-1TB规模，但相比动辄数十TB的数据库仍显有限。因此缓存策略需要遵循二八定律：将20%的热点数据存入缓存，就能解决80%的访问需求。这种选择性缓存机制在MyBatis中体现为细粒度的缓存控制策略。

1.2 MyBatis缓存体系结构

MyBatis采用二级缓存架构设计：

• 一级缓存（Local Cache）：SqlSession级别的缓存，默认开启
• 二级缓存（Global Cache）：Mapper级别的缓存，需显式配置

这种分层设计既保证了会话内的数据一致性，又提供了跨会话的数据共享能力。从实现上看，一级缓存直接使用HashMap存储，而二级缓存可通过多种缓存实现（如Ehcache、Redis）扩展。

2. 一级缓存深度解析

2.1 工作机制详解

一级缓存的生命周期与SqlSession严格绑定。当执行查询时，MyBatis会构建CacheKey作为唯一标识，其生成规则包括：

1. Mapper方法ID（namespace + method）
2. 分页参数（offset/limit）
3. SQL语句本身
4. 参数值列表
5. 环境ID（environment）

这些要素通过哈希算法生成唯一键，确保相同查询条件能命中缓存。以下代码展示了CacheKey的生成过程：

java复制public class CacheKey implements Cloneable, Serializable {
    private static final int DEFAULT_MULTIPLIER = 37;
    private int hashcode;
    private int count;
    private List<Object> updateList;
    
    public void update(Object object) {
        int baseHashCode = object == null ? 1 : object.hashCode();
        count++;
        baseHashCode *= count;
        hashcode = multiplier * hashcode + baseHashCode;
        updateList.add(object);
    }
}

2.2 缓存失效场景

一级缓存的自动失效机制包括：

1. DML操作触发：执行INSERT/UPDATE/DELETE时，会清空当前SqlSession的所有缓存
2. 手动清除：调用clearCache()方法强制刷新
3. 事务提交：非自动提交模式下，commit操作会触发缓存刷新
4. 配置变更：执行flushCache="true"的查询语句

重要提示：一级缓存默认采用SESSION作用域（同一个SqlSession），若配置为STATEMENT级别则每次查询后都会清空缓存

2.3 实践验证案例

通过以下测试代码可验证缓存行为：

java复制try (SqlSession session = sqlSessionFactory.openSession()) {
    UserMapper mapper = session.getMapper(UserMapper.class);
    
    // 第一次查询（缓存未命中）
    User user1 = mapper.findById(1L); 
    // 第二次查询（缓存命中）
    User user2 = mapper.findById(1L);
    assert user1 == user2;  // 对象地址相同
    
    // 执行更新操作
    user1.setName("newName");
    mapper.update(user1);
    
    // 第三次查询（缓存失效）
    User user3 = mapper.findById(1L);
    assert user1 != user3;  // 新对象实例
}

日志输出验证：

code复制DEBUG [main] - ==>  Preparing: SELECT * FROM users WHERE id=? 
DEBUG [main] - ==> Parameters: 1(Long)
DEBUG [main] - <==      Total: 1
DEBUG [main] - ==>  Preparing: UPDATE users SET name=? WHERE id=? 
DEBUG [main] - ==> Parameters: newName(String), 1(Long)
DEBUG [main] - ==>  Preparing: SELECT * FROM users WHERE id=? 
DEBUG [main] - ==> Parameters: 1(Long)

3. 二级缓存全面剖析

3.1 配置与启用

二级缓存需要显式开启，支持两种配置方式：

方式一：单个Mapper启用

xml复制<mapper namespace="com.example.UserMapper">
    <cache 
        eviction="LRU"
        flushInterval="60000"
        size="1024"
        readOnly="true"/>
</mapper>

方式二：全局配置启用

xml复制<settings>
    <setting name="cacheEnabled" value="true"/>
</settings>

缓存参数说明：

• eviction：淘汰策略（LRU/FIFO/SOFT/WEAK）
• flushInterval：刷新间隔（毫秒）
• size：缓存对象数量
• readOnly：是否只读（性能优化关键）

3.2 工作流程解析

二级缓存的工作流程包含关键阶段：

1. 缓存加载：SqlSession关闭时，一级缓存内容转入二级缓存
2. 缓存查询：新会话优先查询二级缓存
3. 缓存更新：DML操作触发全局缓存失效

mermaid复制graph TD
    A[新查询请求] --> B{二级缓存命中?}
    B -->|是| C[返回缓存结果]
    B -->|否| D[查询数据库]
    D --> E[存入一级缓存]
    E --> F[SqlSession关闭]
    F --> G[转存二级缓存]

3.3 跨会话测试案例

验证二级缓存的跨会话特性：

java复制// 会话1
try (SqlSession session1 = sqlSessionFactory.openSession()) {
    User user1 = session1.getMapper(UserMapper.class).findById(1L);
}

// 会话2
try (SqlSession session2 = sqlSessionFactory.openSession()) {
    // 命中二级缓存
    User user2 = session2.getMapper(UserMapper.class).findById(1L); 
    assert user1 != user2;  // 不同对象实例（readOnly=false时）
}

4. 生产级缓存实践指南

4.1 缓存策略选型

4.2 性能优化技巧

1. 批量操作处理：大批量DML操作前手动清空缓存

   java复制sqlSession.clearCache();
   userMapper.batchInsert(users);
   

2. 缓存粒度控制：对字段级变化使用<cache-ref>共享缓存

   xml复制<cache-ref namespace="com.example.BaseMapper"/>
   

3. 监控缓存命中率：通过日志分析缓存效果

   properties复制logging.level.org.mybatis.cache=DEBUG
   

4.3 典型问题解决方案

问题1：脏读现象

• 现象：事务A未提交时，事务B从缓存读取到中间状态数据
• 解决方案：
  • 设置readOnly="true"
  • 使用TransactionalCache装饰器

问题2：缓存穿透

• 现象：恶意查询不存在的数据，绕过缓存直达数据库
• 解决方案：

  xml复制<cache blocking="true"/>
  

问题3：缓存雪崩

• 现象：大量缓存同时失效导致数据库压力骤增
• 解决方案：

  xml复制<cache flushInterval="随机时间"/>
  

5. 高级特性与源码解析

5.1 缓存装饰器模式

MyBatis通过装饰器模式增强缓存功能：

code复制BaseCache
  ↑
 SynchronizedCache（线程安全）
  ↑
 LoggingCache（命中率统计）
  ↑
 SerializedCache（序列化支持）
  ↑
 LruCache（淘汰策略）

5.2 自定义缓存实现

实现自定义缓存需要：

1. 实现Cache接口
2. 注册到MyBatis配置

java复制public class RedisCache implements Cache {
    private final ReadWriteLock lock = new ReentrantReadWriteLock();
    private String id;
    private JedisPool jedisPool;

    public RedisCache(String id) {
        this.id = id;
        this.jedisPool = new JedisPool("127.0.0.1", 6379);
    }
    
    // 实现各缓存方法...
}

配置使用：

xml复制<cache type="com.example.RedisCache"/>

5.3 缓存同步机制

跨节点缓存同步可通过消息队列实现：

1. 订阅数据库binlog
2. 发布缓存失效事件
3. 各节点消费事件更新本地缓存

这种方案在微服务架构中能保证最终一致性，延迟通常在毫秒级别。

6. 性能对比测试数据

通过JMeter压测对比不同场景性能（单位：TPS）：

测试结论：

1. 缓存对读操作提升显著（20倍+）
2. 二级缓存效果优于一级缓存
3. 写操作场景需权衡缓存开销

7. 最佳实践总结

经过多年项目实践，我总结出MyBatis缓存使用的黄金法则：

1. 谨慎评估必要性：不是所有查询都需要缓存，评估数据变化频率和实时性要求
2. 合理设置超时：结合业务特点设置flushInterval，通常5-30分钟为宜
3. 严格监控指标：关注缓存命中率（建议>85%）、内存占用等关键指标
4. 分布式环境方案：推荐使用Redis等集中式缓存，避免本地缓存一致性问题
5. 定期清理策略：配置合理的eviction策略，防止内存泄漏

一个典型的优化配置示例：

xml复制<cache
  eviction="LRU"
  flushInterval="1800000"
  size="2048"
  readOnly="false"
  blocking="true"/>

最后特别提醒：缓存虽好，但滥用会导致数据不一致、内存溢出等问题。建议新系统初期保持缓存关闭，待性能瓶颈明确后再针对性启用。