sqlsession非线程安全，根本原因在于其内部持有未同步的可变共享状态：数据库连接（connection）、一级缓存（hashmap）、executor及事务状态、参数绑定上下文，多线程共用会导致状态错乱、脏读或异常。

SqlSession 不是线程安全的，根本原因在于它内部维护了多个**可变的、共享状态资源**，且没有做任何线程同步保护。简单说：它不是为并发设计的，就像“一个人的饭碗不能同时被五个人抢着用”。

它内部持有哪些危险的共享状态？

SqlSession 表面是个操作入口，背后实际封装了几个关键组件，每个都自带“易冲突属性”：

• 数据库连接（Connection）：底层直接包装 JDBC 的 Connection 对象，而 JDBC 规范明确要求 Connection 是单线程使用的；多线程共用会导致连接状态错乱（比如事务隔离级别被覆盖、自动提交模式被切换）。
• 一级缓存（Per-session HashMap）：缓存以 HashMap 形式存在 SqlSession 实例中，未加锁；线程 A 写入缓存后，线程 B 可能读到脏数据或触发 ConcurrentModificationException。
• 执行器（Executor）与事务状态：Executor 管理 SQL 执行流程，包含事务开启/提交/回滚标记；若两个线程在同一个 SqlSession 上分别调用 commit() 和 rollback()，结果不可预测——可能 A 刚提交的数据被 B 的 rollback 撤销。
• 参数绑定与结果映射上下文：比如动态 SQL 解析、TypeHandler 处理过程依赖临时变量和线程局部状态，共享实例时容易发生参数混淆（例如线程 A 查询 id=100，线程 B 同时执行 update id=200，但参数被错绑）。

为什么不能靠加锁解决？

有人会想：“那给 SqlSession 方法加 synchronized 不就行了？”不行，原因有二：

Java编程专家

Java 源码分析与编程专家。 TRIGGER when: 分析Java源码、阅读Java代码、Java代码走读、Java项目结构分析、 写Java代码、Java代码生成、Java编程、Java重构、Java性能优化、 Spring Boot开发、Spring框架、MyBatis、Hibernate、JPA、 Maven/Gradle构建、Java单元测试、JUnit、Mockito、 Java设计模式、Java并发编程、JVM调优、Java内存分析、 Java异常排查、Java日志分析、Java接口设计

下载

• SqlSession 生命周期本就该短，加锁会让所有线程排队等待，严重拖慢吞吐，违背高并发场景的设计初衷；
• 锁粒度难控制——它内部多个子组件（Connection、Cache、Transaction）各自有独立状态，单靠对象锁无法保证这些组件间的一致性。

对比 SqlSessionFactory 就清楚了

SqlSessionFactory 是线程安全的，因为它只干一件事：按需生成新的 SqlSession。它的内部配置（Configuration）是只读冻结的，没有运行时可变状态；而 SqlSession 是“干活的人”，每次干活都要带工具（Connection）、记笔记（Cache）、管账本（Transaction），这些都得自己独享。

所以 MyBatis 明确要求：每个线程、每次数据库操作，都应使用独立的 SqlSession 实例，用完即关——这不是限制，而是对数据正确性的基本保障。

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南