1. MyBatis框架概述与面试考察点
作为Java生态中最受欢迎的ORM框架之一，MyBatis在技术面试中的出现频率常年居高不下。面试官偏爱考察MyBatis工作原理的原因主要有三点：首先它能有效检验候选人对Java数据库访问层的理解深度；其次通过框架设计可以评估抽象思维能力；最后实际使用中的坑点能反映工程经验。我在技术面试中常发现，能清晰描述MyBatis运行机制的候选人，往往在SQL优化和复杂业务建模方面也有独到见解。
MyBatis的核心定位是解决JDBC的原始性问题。与传统JDBC相比，它通过XML/注解配置将SQL与代码解耦，用动态SQL生成替代字符串拼接，以结果集自动映射消除手动处理ResultSet的繁琐。这种半自动化的设计哲学，既保留了SQL的灵活性，又提供了对象化的便捷接口。
2. 核心架构与运行时序解析
2.1 组件协作模型
MyBatis的架构设计遵循典型的分层模式，各组件通过明确的职责划分实现松耦合：
- 接口层：暴露SqlSession等API给业务代码调用
- 核心处理层：包含配置解析、SQL解析、执行器路由等核心功能
- 基础支撑层：提供事务管理、连接池、缓存等基础设施
在运行时，这些组件通过精心设计的交互流程协同工作。以查询为例，当调用session.selectOne()时，请求会依次经过：
- 执行器(Executor)决定是否走缓存
- 语句处理器(StatementHandler)构建PreparedStatement
- 参数处理器(ParameterHandler)设置预编译参数
- 结果处理器(ResultHandler)转换ResultSet
2.2 关键源码路径
跟踪DefaultSqlSession的selectList方法，可以看到完整的执行链条：
- 通过MappedStatement定位要执行的SQL
- 执行器根据配置决定创建简单/可重用/批处理Statement
- 参数处理器将JavaBean属性映射到SQL参数占位符
- 结果处理器通过TypeHandler完成JDBC类型到Java类型的转换
这个过程中最精妙的是TypeHandler体系的设计，它通过泛型+策略模式实现了类型转换的扩展性。比如处理LocalDateTime时，会自动选用Jsr310TypeHandler的子类完成与Timestamp的互转。
3. 核心流程深度剖析
3.1 配置加载阶段
配置文件解析是MyBatis初始化的关键环节。XMLConfigBuilder会按固定顺序处理：
- 解析properties外部变量
- 加载typeAliases类型别名
- 注册plugins拦截器链
- 构建environments数据源环境
- 扫描mappers映射文件
特别需要注意的是mapper文件的加载策略。当使用包扫描方式时，MyBatis会通过VFS(虚拟文件系统)抽象来兼容不同部署环境，这在Tomcat与独立应用中的表现可能不同。
3.2 SQL执行阶段
动态SQL生成是MyBatis的招牌特性。观察SqlSourceBuilder的解析过程：
java复制public SqlSource parse(String originalSql, Class<?> parameterType) {
ParameterMappingTokenHandler handler = new ParameterMappingTokenHandler();
GenericTokenParser parser = new GenericTokenParser("#{", "}", handler);
String sql = parser.parse(originalSql);
return new StaticSqlSource(sql, handler.getParameterMappings());
}
这段代码揭示了#{}占位符的处理逻辑：先提取参数表达式，再生成PreparedStatement适用的参数映射。与之对比，${}的处理则直接进行字符串替换，这也是SQL注入风险的根源。
4. 高级特性实现原理
4.1 插件拦截机制
MyBatis通过动态代理实现插件拦截，其设计类似Spring AOP：
- 拦截目标：Executor/StatementHandler/ParameterHandler/ResultSetHandler
- 代理链生成：InterceptorChain.pluginAll()方法嵌套包装原始对象
- 执行时序：通过@Intercepts注解定义拦截点
实际开发中，利用插件可以实现分库分表、慢SQL监控等功能。但需要注意过度拦截会影响性能，我在某项目中曾因添加过多监控插件导致吞吐量下降30%。
4.2 缓存体系设计
一级缓存(SqlSession级别)默认开启，其实现简单但易踩坑：
- 更新操作会清空整个缓存
- 分布式环境可能产生脏读
- 大结果集可能引发内存问题
二级缓存(Mapper级别)需要显式配置，其实现依赖TransactionalCacheManager。常见问题包括：
- 事务提交后才更新缓存
- 对象需要实现Serializable
- 缓存策略与业务场景不匹配
5. 生产环境中的典型问题
5.1 参数映射异常
当遇到"Could not set parameter"错误时，通常需要检查：
- 属性名是否与#{}占位符一致
- 复杂对象是否缺少@Param注解
- TypeHandler是否注册正确
我曾遇到一个隐蔽案例：Lombok生成的getter方法不符合JavaBean规范，导致布尔类型字段映射失败。最终通过自定义TypeHandler解决。
5.2 动态SQL陷阱
在使用
- 判断null需用_parameter
- 字符串比较要加toString()
- 集合判断用@Param("list")而非parameterType
一个性能优化技巧：对于固定条件分支，使用
6. 面试应答策略与扩展思考
回答"MyBatis工作原理"时，建议采用分层表述法：
- 宏观流程：配置加载→SQL解析→执行映射
- 关键组件：SqlSessionFactoryBuilder→Configuration→Executor
- 扩展点：插件、TypeHandler、ObjectFactory
进阶问题通常围绕：
- 与Hibernate的设计哲学差异
- 如何实现多数据源动态切换
- 大批量插入的性能优化方案
在某个电商项目中，我们通过改写BatchExecutor实现了百万级数据的高效导入，关键点在于调整rewriteBatchedStatements参数和合理设置batchSize。