MyBatis一级缓存踩坑实录，90%开发者忽略的线程安全问题

第一章：MyBatis一级缓存踩坑实录，90%开发者忽略的线程安全问题

在高并发场景下，MyBatis的一级缓存（SqlSession级别缓存）可能引发严重的数据一致性问题。由于一级缓存默认开启且作用域为 SqlSession，当多个线程共享同一个 SqlSession 实例时，彼此会读取到对方未提交的缓存数据，从而导致脏读。

问题复现场景

假设在一个 Web 应用中，开发者错误地将 SqlSession 设置为类成员变量，供多个请求线程共用：

public class UserService {
    private SqlSession sqlSession = MyBatisUtil.getSqlSessionFactory().openSession();

    public User getUserById(int id) {
        return sqlSession.selectOne("selectUser", id);
    }
}

上述代码中，sqlSession 被多个线程共享。每个线程调用 getUserById 时，可能读取到其他线程之前查询并缓存的结果，尤其在事务未提交时，极易返回中间状态数据。

缓存机制与线程安全分析

MyBatis 一级缓存的生命周期与 SqlSession 绑定，其底层由 PerpetualCache 实现，本质是一个简单的 HashMap，并未做任何同步处理。

• 缓存键：MappedStatement ID + 查询参数 + 环境等
• 缓存值：查询结果对象
• 线程安全：无同步控制，不支持并发访问

以下表格展示了不同并发场景下的行为差异：

场景	是否共享 SqlSession	是否线程安全	风险等级
单线程操作	是	是	低
多线程共享 SqlSession	是	否	高
每个线程独立 SqlSession	否	是	低

正确使用建议

• 确保每个线程拥有独立的 SqlSession 实例
• 在请求结束时及时关闭 SqlSession，避免缓存累积
• 避免将 SqlSession 作为成员变量或静态变量使用

通过合理管理 SqlSession 生命周期，可彻底规避一级缓存带来的线程安全问题。

第二章：深入理解MyBatis缓存架构设计

2.1 一级缓存与二级缓存的核心区别

一级缓存通常指线程或会话级别的本地缓存，而二级缓存是跨会话共享的全局缓存机制。两者在作用范围、生命周期和数据一致性方面存在本质差异。

作用域与生命周期

一级缓存生命周期与数据库会话绑定，例如 MyBatis 的 SqlSession 级缓存，在会话关闭后自动失效；二级缓存则跨越多个会话，需显式配置如 Redis 或 Ehcache 实现持久化存储。

数据同步机制

二级缓存面临多节点数据一致性挑战。常见策略包括设置合理的过期时间（TTL）和使用发布-订阅模式同步更新事件。

特性	一级缓存	二级缓存
作用范围	单个会话内	应用级共享
并发安全	天然隔离	需加锁或版本控制

// 开启 MyBatis 二级缓存
@Mapper
public interface UserMapper {
    @Select("SELECT * FROM user WHERE id = #{id}")
    @Options(useCache = true, flushCache = false)
    User findById(Long id);
}

上述注解启用查询缓存，useCache=true 表示结果可缓存，flushCache=false 避免执行更新时清空缓存，适用于读多写少场景。

2.2 SqlSession级别的缓存实现原理

SqlSession级别的缓存，又称一级缓存，是MyBatis默认开启的本地缓存机制。该缓存基于同一个SqlSession实例，在执行查询时将SQL语句的哈希值与结果对象映射存储在内存中。

缓存的生命周期

一级缓存的生命周期与SqlSession一致，从创建到关闭期间有效。当SqlSession调用commit()、close()或执行update()操作时，缓存会被清空。

缓存键的构建

MyBatis通过以下元素构建缓存键：

• 映射语句的ID
• 查询参数值
• 分页信息（offset和limit）
• SQL语句文本

CacheKey cacheKey = sqlSession.createCacheKey(mappedStatement, parameter, rowBounds, boundSql);
Object cachedResult = localCache.getObject(cacheKey);
if (cachedResult == null) {
    cachedResult = executeQueryFromDatabase(mappedStatement, parameter, rowBounds, resultHandler, cacheKey, boundSql);
    localCache.putObject(cacheKey, cachedResult);
}

上述代码展示了缓存查询的核心流程：首先生成唯一缓存键，尝试从localCache（本质为PerpetualCache实例）中获取结果，未命中则查询数据库并写入缓存。

2.3 缓存生命周期与执行流程剖析

缓存的生命周期涵盖创建、命中、失效与淘汰四个核心阶段。当请求访问数据时，系统首先检查缓存中是否存在对应条目。

缓存执行流程

典型的缓存读取流程如下：

1. 接收客户端请求
2. 查询缓存是否存在有效数据
3. 若命中则返回结果
4. 未命中则回源数据库并写入缓存

代码示例：缓存读取逻辑

func GetUserData(id string) (*User, error) {
    data, found := cache.Get("user:" + id)
    if found {
        return data.(*User), nil // 命中缓存
    }
    user := fetchFromDB(id)     // 回源数据库
    cache.Set("user:"+id, user, 5*time.Minute)
    return user, nil
}

上述代码展示了缓存读取的基本模式：先尝试从缓存获取数据，未命中时从数据库加载，并设置TTL（生存时间）后写入缓存。

缓存状态转换表

状态	触发条件	后续动作
未初始化	首次请求	加载数据并创建缓存
已命中	Key存在且未过期	直接返回值
已失效	TTL到期	标记删除，等待淘汰

2.4 基于PerpetualCache的缓存存储机制实践

核心实现原理

PerpetualCache 是 MyBatis 提供的默认缓存实现，基于简单的 HashMap 存储结构，用于在 SqlSession 生命周期内保存查询结果。其线程不安全的设计适用于单会话场景。

public class PerpetualCache implements Cache {
    private final String id;
    private final Map<Object, Object> cache = new HashMap<>();

    public PerpetualCache(String id) {
        this.id = id;
    }

    @Override
    public void putObject(Object key, Object value) {
        cache.put(key, value); // 直接存入HashMap
    }

    @Override
    public Object getObject(Object key) {
        return cache.get(key); // 直接获取
    }
}

上述代码展示了 PerpetualCache 的基本结构：使用 HashMap 存储键值对，无自动过期机制，适合短期缓存。

适用场景与限制

• 适用于 SqlSession 级别的本地缓存
• 不支持跨会话数据共享
• 无容量控制和淘汰策略，需配合其他装饰器使用

2.5 源码视角解读缓存的put与get操作

在主流缓存实现中，`put` 与 `get` 是核心操作。以 Guava Cache 为例，其内部通过 `ConcurrentHashMap` 实现线程安全的数据存取。

put 操作流程

cache.put(key, value);

该操作将键值对插入缓存，若已存在相同 key，则覆盖旧值。底层调用 `ConcurrentHashMap#put`，并触发可能的过期策略检测。

get 操作机制

cache.getIfPresent(key);

直接从哈希表中查询对应值，无则返回 `null`。此方法不触发加载逻辑，适用于已预加载场景。

• put 操作会触发权重计算与容量回收
• get 操作可能引发最近最少使用（LRU）排序更新

第三章：一级缓存中的线程安全陷阱

3.1 多线程环境下共享SqlSession的风险演示

在MyBatis中，`SqlSession` 负责执行SQL操作并管理事务。然而，它并非线程安全对象，若在多线程环境中共享同一个实例，将引发数据错乱或异常。

风险代码示例

SqlSession sqlSession = sqlSessionFactory.openSession();
Runnable task = () -> {
    try {
        User user = sqlSession.selectOne("selectUser", 1);
        System.out.println(user.getName());
    } catch (Exception e) {
        e.printStackTrace();
    }
};
new Thread(task).start();
new Thread(task).start(); // 并发访问同一SqlSession

上述代码中，两个线程共用一个 `SqlSession`，可能导致内部状态冲突，如缓存混乱、游标错位甚至抛出 `ConcurrentModificationException`。

典型问题表现

• 查询结果错乱，返回不属于当前请求的数据
• 事务边界失控，提交或回滚影响其他线程操作
• 底层JDBC资源竞争，引发连接关闭异常

正确做法是确保每个线程独享独立的 `SqlSession` 实例，并在操作完成后及时关闭。

3.2 并发访问导致的数据不一致问题分析

在多线程或分布式系统中，多个进程同时读写共享数据时，可能因缺乏同步机制而导致数据状态异常。典型场景包括库存超卖、账户余额错误等。

竞态条件的产生

当两个线程同时读取同一变量，修改后写回，后写入的结果会覆盖前者，造成更新丢失。例如：

var balance int = 100
// 线程1和线程2同时执行
func deposit(amount int) {
    temp := balance      // 同时读取 balance = 100
    temp += amount       // 都计算为 150
    balance = temp       // 先后者生效，最终 balance = 150 而非预期 200
}

上述代码未使用互斥锁，导致两次存款仅一次生效。

常见解决方案对比

方案	优点	缺点
互斥锁（Mutex）	实现简单，控制粒度细	可能引发死锁
原子操作	无锁，性能高	仅适用于简单类型
事务机制	保证ACID特性	开销较大

3.3 ThreadLocal模式在缓存隔离中的应用实践

在高并发场景下，多线程共享数据易引发脏读与覆盖问题。ThreadLocal 提供了线程私有变量机制，可实现缓存的隔离存储，避免竞争。

核心实现原理

每个线程持有独立的变量副本，通过 ThreadLocal<T> 实例的 get() 与 set(T) 方法操作本地存储。

public class UserContext {
    private static final ThreadLocal<String> userIdHolder = new ThreadLocal<>();

    public static void setCurrentUser(String userId) {
        userIdHolder.set(userId);
    }

    public static String getCurrentUser() {
        return userIdHolder.get();
    }

    public static void clear() {
        userIdHolder.remove();
    }
}

上述代码中，userIdHolder 为静态常量，但每个线程调用 set 和 get 时访问的是自身绑定的数据副本，实现了请求级上下文隔离。

典型应用场景

• Web 请求链路中的用户身份传递
• 事务上下文或数据库会话隔离
• 日志追踪ID（如TraceID）的跨方法传播

务必在请求结束时调用 remove() 防止内存泄漏，尤其在使用线程池时。

第四章：规避缓存风险的最佳实践方案

4.1 正确管理SqlSession的作用域与生命周期

理解SqlSession的核心角色

SqlSession 是 MyBatis 框架中执行数据库操作的核心接口，封装了 SQL 执行、事务管理和映射器调用。其生命周期若管理不当，易引发资源泄漏或线程安全问题。

典型使用场景与代码示例

try (SqlSession session = sqlSessionFactory.openSession()) {
    UserMapper mapper = session.getMapper(UserMapper.class);
    User user = mapper.selectById(1L);
    // 自动提交事务
    session.commit();
} // try-with-resources 确保 session 关闭

该代码利用 try-with-resources 语法确保 SqlSession 在作用域结束时自动关闭，避免资源泄露。SqlSessionFactory 应为单例，而 SqlSession 必须为每次请求创建独立实例。

生命周期管理准则

• SqlSession 不应被多个线程共享，不具备线程安全性
• 应在方法或请求级别创建并及时关闭
• 与 Spring 集成时，推荐由框架管理其生命周期

4.2 高并发场景下的缓存使用规范

在高并发系统中，缓存是提升性能的核心手段，但不规范的使用可能导致数据不一致、缓存击穿或雪崩等问题。合理设计缓存策略至关重要。

缓存穿透防护

为防止恶意查询不存在的数据导致数据库压力过大，推荐使用布隆过滤器预先判断键是否存在。

// 使用布隆过滤器拦截无效请求
if !bloomFilter.Contains(key) {
    return ErrKeyNotFound
}
data, err := cache.Get(key)

该机制可显著降低对后端存储的无效访问，适用于用户画像、商品详情等高频读取场景。

缓存更新策略

采用“先更新数据库，再删除缓存”的双写一致性方案，避免脏读。

• 写操作时清除缓存，确保下次读取触发最新数据加载
• 配合延迟双删，应对主从复制延迟问题

4.3 利用Mapper接口隔离保障线程安全

在多线程环境下，Mapper接口的合理设计能有效避免共享状态带来的并发问题。通过将数据操作封装在独立的接口中，每个线程调用的实例相互隔离，从而杜绝了竞态条件。

接口职责单一化

遵循单一职责原则，Mapper仅负责数据映射逻辑，不持有可变状态。例如：

public interface UserMapper {
    User toUser(UserEntity entity);
    UserEntity toEntity(User user);
}

上述代码中，方法均为无状态转换，不依赖成员变量，天然支持线程安全。

无状态设计优势

• 避免使用静态字段或实例变量存储临时数据
• 所有方法输入完全依赖参数，输出仅由输入决定
• 便于在Spring等容器中以原型或请求作用域部署

结合依赖注入机制，每次请求获取的Mapper实例可独立存在，进一步强化隔离性。

4.4 缓存刷新策略与手动清空时机控制

在高并发系统中，缓存的时效性直接影响数据一致性。合理的刷新策略能有效降低数据库压力，同时保障用户体验。

常见缓存刷新机制

• 定时刷新：周期性更新缓存，适用于数据变化规律的场景；
• 写时失效：数据更新时清除旧缓存，下次读取触发加载；
• 事件驱动刷新：通过消息队列通知缓存服务更新。

手动清空的最佳实践

// 手动清空指定前缀的缓存
func ClearCacheByPrefix(prefix string) error {
    keys, err := redisClient.Keys(prefix + "*").Result()
    if err != nil {
        return err
    }
    if len(keys) > 0 {
        return redisClient.Del(keys...).Err()
    }
    return nil
}

该函数通过 Redis 的 Keys 命令匹配前缀，批量删除相关键。适用于配置变更、运营活动上线等需立即生效的场景。注意避免在高峰时段执行全量清空，防止缓存雪崩。

控制清空时机的决策表

场景	是否立即清空	说明
用户资料更新	是	强一致性要求高
商品价格调整	否（延迟1分钟）	防刷接口，避免频繁触发

第五章：总结与展望

技术演进的持续驱动

现代软件架构正加速向云原生与边缘计算融合。以 Kubernetes 为核心的调度平台已成标配，但服务网格在跨集群通信中仍面临延迟挑战。某金融企业在混合云部署中采用 Istio + eBPF 技术栈，通过自定义流量镜像策略实现灰度发布链路追踪。

• 使用 eBPF 程序拦截 Envoy 的 TCP 流量并注入上下文标签
• 基于 OpenTelemetry 收集细粒度调用指标
• 通过 Prometheus 联邦机制聚合多集群监控数据

代码即基础设施的深化实践

// 自动化生成 Terraform 模块的核心逻辑
func GenerateModule(serviceName string, replicas int) string {
    return fmt.Sprintf(`
resource "aws_ecs_service" "%s" {
  name            = "%s"
  desired_count   = %d
  launch_type     = "FARGATE"
  network_configuration {
    subnets         = ["subnet-123", "subnet-456"]
    assign_public_ip = true
  }
}`, serviceName, serviceName, replicas)
}

该模式已在 CI/CD 流程中集成，每次提交 GitTag 后触发自动化资源编排，部署效率提升 60%。

未来架构的关键方向

技术领域	当前瓶颈	潜在解决方案
AI 推理服务化	GPU 资源碎片化	基于 Kueue 的批处理队列调度
边缘节点安全	零信任策略落地难	硬件级 TPM 与 SPIRE 集成

图示：下一代可观测性管道

Metrics → Logs → Traces → Profiling → Expvars

统一通过 OTLP 协议上报至中央数据湖