MyBatis 的 SqlSession 非线程安全，必须避免多线程共享；应为每个线程独享实例并及时释放，Spring 中推荐使用线程安全的 SqlSessionTemplate，纯 MyBatis 场景可用 ThreadLocal 封装，严禁静态变量或成员变量持有 SqlSession。
MyBatis 的 SqlSession 本身不是线程安全的，多线程共享同一个实例会导致事务混乱、一级缓存错乱、连接冲突甚至 NullPointerException。真正可行的做法不是“加固”它，而是**避免共享**——让每个线程拥有自己专属的 SqlSession 实例，并在其作用域结束时及时释放。
核心原则：每个线程独享一个 SqlSession
SqlSession 内部持有 Connection 和一级缓存（HashMap），二者均无同步控制。一旦被多个线程并发调用，会出现：
- 线程 A 执行 update 后未 commit，线程 B 通过同一 SqlSession 查询，读到脏数据；
- 两个线程调用 commit() 或 rollback()，相互覆盖事务状态；
- Mapper 方法参数绑定过程发生竞态，导致执行 SQL 与预期不符。
所以，“保证安全”的本质是隔离，不是加锁。
推荐方案：用 Spring 的 SqlSessionTemplate
在 Spring 环境中，这是最简洁、最可靠的解法。SqlSessionTemplate 是线程安全的代理类，底层自动结合 ThreadLocal + 事务管理器完成会话隔离：
- 每次调用 mapper 方法时，它动态获取当前线程绑定的 SqlSession（由 Spring 事务上下文管理）；
- 事务开始时创建或复用 SqlSession，事务提交/回滚后自动清理一级缓存、归还连接、解除 ThreadLocal 绑定；
- 开发者完全不用手动 open/close，也无需担心静态变量或单例误用。
只需确保 Mapper 接口由 Spring 托管（如通过 @MapperScan 或 XML 配置），所有注入的 mapper 实际调用的都是 SqlSessionTemplate 封装后的逻辑。
手动管理场景：用 ThreadLocal 封装工具类
若项目未使用 Spring（如纯 MyBatis + 多线程任务），可自行封装线程级 SqlSession 工具类：
- 声明 static ThreadLocal
，每个线程首次调用 getSqlSession() 时创建新会话； - 务必在业务逻辑结束后显式调用 close()（建议 try-finally 或 try-with-resources）；
- 禁止将 SqlSession 存入静态字段、实例变量、HttpSession 或任何跨请求/跨线程的容器中。
示例关键逻辑：
SqlSession sqlSession = threadLocal.get();if (sqlSession == null) {
sqlSession = sqlSessionFactory.openSession();
threadLocal.set(sqlSession);
}
try {
// 执行查询或更新
} finally {
sqlSession.close();
threadLocal.remove(); // 防止内存泄漏
}
必须避开的坑
以下做法看似省事，实则埋雷：
- 静态 SqlSession 字段：多个线程共用一个实例，必然出错；
- 将 SqlSession 放入 Controller 或 Service 成员变量：Spring 默认单例，等同于全局共享；
- 在 Servlet 的 HttpSession 中保存 SqlSession：HTTP 会话可能跨线程复用，且生命周期远长于数据库操作；
- 认为 “SqlSession.openSession(true)”（自动提交）就能解决线程问题：自动提交只影响事务行为，不解决缓存和连接竞争。
不复杂但容易忽略
