1. 引子为什么MyBatis的Mapper接口能直接调用如果你用过MyBatis肯定对下面这种写法不陌生定义一个UserMapper接口里面声明几个方法然后在Service层直接Autowired注入这个接口接着就能调用selectById、insert等方法了。整个过程里你并没有写这个接口的实现类。第一次接触时你可能会觉得有点“魔法”。一个接口没有实现类怎么能被实例化并调用呢这背后就是Java动态代理在“默默干活”。但MyBatis的动态代理和我们平时在Spring AOP里听到的JDK动态代理或CGLib代理目的和实现细节上又有很大不同。它不是为了给方法增强逻辑比如加个日志、事务而是为了将Java方法的调用翻译成一次数据库会话的执行。今天我们就抛开框架的“黑盒”直接钻进MyBatis的源码里看看这个“翻译官”到底是怎么工作的。理解了这个你不仅能更自信地使用MyBatis在遇到一些诡异的问题比如为什么这个方法没生效、参数是怎么绑定的时也能快速定位到根因。2. MyBatis动态代理的核心舞台MapperProxyFactory与MapperProxyMyBatis动态代理的入口非常明确就在org.apache.ibatis.binding.MapperProxyFactory这个类里。它的代码量很少但却是整个机制的“工厂”。2.1MapperProxyFactory代理对象的制造车间我们直接看它的核心方法public class MapperProxyFactoryT { private final ClassT mapperInterface; // ... 其他字段 protected T newInstance(MapperProxyT mapperProxy) { // 使用JDK动态代理创建实例 return (T) Proxy.newProxyInstance(mapperInterface.getClassLoader(), new Class[] { mapperInterface }, mapperProxy); } public T newInstance(SqlSession sqlSession) { // 创建 MapperProxy 这个InvocationHandler final MapperProxyT mapperProxy new MapperProxy(sqlSession, mapperInterface, methodCache); return newInstance(mapperProxy); } }这段代码揭示了几个关键信息工厂与接口绑定每个MapperProxyFactory实例在创建时就和一个具体的Mapper接口比如UserMapper.class绑定了。这个信息存储在mapperInterface字段里。JDK动态代理它明确使用了Proxy.newProxyInstance这是标准的JDK动态代理API。这说明MyBatis的Mapper代理只支持接口不支持类。这也是为什么MyBatis的Mapper必须是接口的原因。真正的核心是MapperProxyProxy.newProxyInstance的第三个参数是一个InvocationHandler的实现。在这里就是MapperProxy。所有对Mapper接口方法的调用最终都会路由到MapperProxy.invoke()方法里。MapperProxy才是那个真正的“翻译官”。所以流程很清晰当你从SqlSession里获取一个Mapper时比如sqlSession.getMapper(UserMapper.class)内部就是找到了或创建了对应的MapperProxyFactory然后调用newInstance方法生成了一个代理对象给你。你拿到的就是这个代理对象。2.2MapperProxy方法调用的总调度中心MapperProxy实现了InvocationHandler接口它的invoke方法是所有魔法发生的地方。我们来看它的简化逻辑public class MapperProxyT implements InvocationHandler, Serializable { Override public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { try { // 1. 如果是Object类自带的方法如toString, hashCode直接调用不走MyBatis逻辑 if (Object.class.equals(method.getDeclaringClass())) { return method.invoke(this, args); } // 2. 接口的默认方法Java 8也特殊处理 else if (method.isDefault()) { return invokeDefaultMethod(proxy, method, args); } } catch (Throwable t) { throw ExceptionUtil.unwrapThrowable(t); } // 3. 最关键的一步这才是我们的Mapper接口里声明的方法 final MapperMethod mapperMethod cachedMapperMethod(method); return mapperMethod.execute(sqlSession, args); } }这个invoke方法做了三件事优先级从高到低处理Object方法如果你调用了代理对象的toString()或equals()它不会去数据库查而是直接调用InvocationHandler也就是MapperProxy本身的对应方法。这很合理。处理默认方法从Java 8开始接口可以有default方法。MyBatis也支持在Mapper接口里写默认方法用于封装一些简单的逻辑。对于这类方法MyBatis会通过一些技巧invokeDefaultMethod去调用接口本身的默认实现而不是将其视为数据库操作。执行数据库方法排除了前两种情况剩下的就是你在Mapper接口里声明的、意图操作数据库的方法了。对于这些方法MapperProxy并没有自己处理而是转交给了另一个重量级角色MapperMethod。这里有个性能优化点cachedMapperMethod(method)。它会缓存MapperMethod实例。因为一个Method对象对应一个接口方法这个方法的执行逻辑对应哪条SQL、参数怎么解析、结果怎么映射在运行期是固定的。缓存起来可以避免重复创建提升性能。踩坑提示这里也隐含了一个潜在问题。MapperMethod的缓存是基于Method对象的。如果你用动态编译、字节码增强等技术在运行时生成了新的Method对象即使签名相同可能会导致缓存失效每次调用都创建新的MapperMethod带来性能损耗。不过这种场景非常罕见。至此MapperProxy完成了它的调度使命将皮球踢给了MapperMethod。真正的“翻译”工作现在才开始。3.MapperMethod将Java方法翻译成数据库命令MapperMethod这个类是理解MyBatis如何“理解”你写的接口方法的关键。它内部有两个非常重要的静态内部类SqlCommand和MethodSignature。3.1SqlCommandSQL命令的元数据SqlCommand负责解析一个方法对应的是什么类型的SQL操作SELECT, INSERT, UPDATE, DELETE等以及这条SQL语句的唯一标识。public static class SqlCommand { private final String name; // SQL语句的全局唯一ID 格式为 “namespace.id” private final SqlCommandType type; // 枚举UNKNOWN, INSERT, UPDATE, DELETE, SELECT, FLUSH }这个name就是你在Mapper XML文件中写的select id”selectById”中的id但前面会加上namespace通常是接口的全限定名。例如com.example.mapper.UserMapper.selectById。MyBatis在启动时会解析所有的XML和注解构建一个全局的Configuration对象里面就存储了所有name到MappedStatementSQL语句的完整描述的映射。SqlCommand在初始化时就是根据传入的Method对象去Configuration里查找对应的MappedStatement从而确定type。3.2MethodSignature方法签名的解析器MethodSignature则负责解析Java方法本身的特征返回值类型、参数列表、是否有Param注解等。这些信息对于后续的参数绑定和结果映射至关重要。public static class MethodSignature { private final boolean returnsMany; // 是否返回集合List, Map等 private final boolean returnsMap; // 是否返回Map private final boolean returnsVoid; // 是否返回void private final boolean returnsCursor; // 是否返回Cursor游标 private final boolean returnsOptional; // 是否返回OptionalJava 8 private final Class? returnType; // 返回类型 private final String mapKey; // 如果返回Map哪个参数作为key通过MapKey注解指定 private final Integer resultHandlerIndex; // 参数中ResultHandler的位置 private final Integer rowBoundsIndex; // 参数中RowBounds的位置用于内存分页已不推荐 private final ParamNameResolver paramNameResolver; // 参数名解析器 }其中最值得关注的是ParamNameResolver。它解决了Java编译后参数名丢失的问题默认编译为arg0, arg1。它的工作逻辑是如果方法参数用了Param(“id”)注解那就用注解指定的名字。如果没注解且编译时加了-parameters参数保留参数名就用真实的参数名。如果以上都不满足则使用param1,param2...作为参数名。这个解析出来的参数名映射关系在后面绑定SQL参数时会用到。3.3execute方法执行路由MapperMethod的核心是它的execute方法。它根据SqlCommand解析出的SQL类型SqlCommandType以及MethodSignature解析出的返回类型来决定最终调用SqlSession的哪个方法。public Object execute(SqlSession sqlSession, Object[] args) { Object result; switch (command.getType()) { case INSERT: { // 转换参数通常只有一个参数是待插入的对象 Object param method.convertArgsToSqlCommandParam(args); // 调用sqlSession.insert返回值是受影响的行数 result rowCountResult(sqlSession.insert(command.getName(), param)); break; } case UPDATE: { Object param method.convertArgsToSqlCommandParam(args); result rowCountResult(sqlSession.update(command.getName(), param)); break; } case DELETE: { Object param method.convertArgsToSqlCommandParam(args); result rowCountResult(sqlSession.delete(command.getName(), param)); break; } case SELECT: // 查询逻辑最复杂根据返回值类型细分 if (method.returnsVoid() method.hasResultHandler()) { // 使用ResultHandler处理结果无返回值 executeWithResultHandler(sqlSession, args); result null; } else if (method.returnsMany()) { // 返回集合如ListUser result executeForMany(sqlSession, args); } else if (method.returnsMap()) { // 返回Map result executeForMap(sqlSession, args); } else if (method.returnsCursor()) { // 返回Cursor游标 result executeForCursor(sqlSession, args); } else { // 返回单个对象 Object param method.convertArgsToSqlCommandParam(args); result sqlSession.selectOne(command.getName(), param); // 注意如果查询返回多条这里会抛出TooManyResultsException } break; case FLUSH: result sqlSession.flushStatements(); break; default: throw new BindingException(Unknown execution method for: command.getName()); } return result; }这个方法就像一个大型路由器它的逻辑非常直白增删改统一调用sqlSession的insert/update/delete核心是convertArgsToSqlCommandParam方法将方法参数数组转换为SQL可用的参数对象通常是一个Map或原始对象然后处理返回值将int行数转换为方法声明的返回值类型比如boolean。查询根据方法返回值类型分派到不同的执行路径。这是最容易出错的地方。selectOne期望返回单个对象。如果数据库返回0条则返回null如果返回多条则抛出TooManyResultsException。这是新手常踩的坑比如根据非唯一字段查询却用了selectOne。executeForMany用于返回集合内部调用sqlSession.selectList。executeForMap用于返回Map内部调用sqlSession.selectMap。带有ResultHandler的参数这是一种流式处理结果的方式适用于数据量极大、不想一次性加载到内存的场景。核心经验MapperMethod.execute方法清晰地展示了MyBatis如何将Java方法映射到SQL执行。当你遇到“方法调用结果不符合预期”时首先应该检查这里你的方法返回值类型是否匹配SQL实际执行的结果类型比如一个返回ListUser的方法其对应的SQL必须能返回多条记录如果SQL只返回一条MyBatis也会把它包装进List里包含一个元素这通常是符合预期的。但反过来一个返回User的方法如果SQL返回多条就会立刻报错。4. 参数绑定与SQL执行ParamNameResolver与SqlSession的协作前面提到MethodSignature里有个ParamNameResolver它在convertArgsToSqlCommandParam方法中扮演关键角色。我们看看这个方法做了什么public Object convertArgsToSqlCommandParam(Object[] args) { return paramNameResolver.getNamedParams(args); }ParamNameResolver.getNamedParams方法会将传入的参数数组转换成一个MapString, Object。这个Map的key就是解析出来的参数名Param值或param1等value就是对应的参数值。为什么是Map因为MyBatis的SQL解析器DynamicContext在替换#{}或${}占位符时默认就是从传入的Map或JavaBean对象中根据key即参数名或者property属性名来获取值的。例如你的接口方法是User selectById(Param(“userId”) Integer id, Param(“userStatus”) String status);经过ParamNameResolver处理后传给SqlSession的参数就是一个Map{“userId”: 123, “userStatus”: “ACTIVE”}。对应的XML SQL就可以写select id”selectById” resultType”User” SELECT * FROM user WHERE id #{userId} AND status #{userStatus} /select至此MapperMethod完成了从Java方法到SqlSession方法调用的翻译。它告诉SqlSession“请执行名字叫com.example.mapper.UserMapper.selectById的SQL这是给你的参数Map”。接下来的故事就交给了SqlSession默认实现是DefaultSqlSession和它的四大执行器Executor。它们负责根据SQL ID从Configuration里拿到完整的MappedStatement创建StatementHandler设置参数执行JDBC操作并通过ResultSetHandler将结果集映射成Java对象。这一部分属于MyBatis执行流程的更深层但动态代理的使命在将调用权交给SqlSession的那一刻就已经圆满完成了。5. 从动态代理看MyBatis的设计哲学与实战避坑理解了动态代理的原理我们就能从更高维度审视MyBatis并规避一些常见问题。5.1 设计哲学接口即契约配置即实现MyBatis通过动态代理完美实现了“接口与实现分离”。Mapper接口定义了做什么方法签名而XML或注解定义了怎么做SQL语句。这种设计让数据库操作代码变得非常清晰接口可以被JUnit轻易Mock也方便与Spring等框架集成。动态代理是连接这两者的“胶水”。5.2 常见问题与排查思路BindingException: Invalid bound statement (not found)根因这是最经典的错误。意味着MapperProxy在创建MapperMethod时其内部的SqlCommand无法根据接口方法名如selectById和接口全限定名在全局配置Configuration中找到对应的MappedStatement即SQL声明。排查步骤检查XML中的namespace必须和Mapper接口的全限定名完全一致一个字母都不能差。检查SQL语句的id必须和接口方法名完全一致。检查XML文件是否被扫描到检查MyBatis配置的mapperLocationsSpring Boot中是mybatis.mapper-locations是否包含了你的XML文件路径。检查是否有多处定义冲突同一个方法是否同时在XML和注解Select中定义了这可能导致冲突。方法调用返回null但数据库明明有数据根因大概率是MapperMethod.execute方法中调用了sqlSession.selectOne但你的SQL实际返回了0条记录可能是参数传错或者查询条件不匹配。selectOne对0条记录的处理就是返回null。排查打开MyBatis的SQL日志配置log4j.logger.org.apache.ibatisDEBUG或使用mybatis.log.free等插件查看实际执行的SQL和参数。确认你的方法返回值类型。如果是返回单个对象确保你的查询条件能唯一确定一条记录。抛TooManyResultsException异常根因和上一条相反。方法声明返回单个对象如User但SQL查询返回了多条记录。MapperMethod在selectOne分支中检测到多条结果就会抛出此异常。解决修改SQL确保查询条件具有唯一性例如加上LIMIT 1但需注意业务逻辑是否正确。或者修改接口方法让其返回集合类型如ListUser。Param注解失效参数绑定错误根因ParamNameResolver解析参数名失败最终使用了param1, param2作为key但你的SQL中用的是自定义名称。注意在Spring Boot项目中如果编译时未加-parameters参数且未使用Param注解MyBatis确实只能使用arg0, arg1或param1, param2。强烈建议为多参数方法显式加上Param注解这是最可靠的方式。5.3 性能与扩展点缓存MapperMethod对象是被缓存的避免了每次调用都重新解析方法签名和SQL命令。这是一个有效的性能优化。插件InterceptorMyBatis的插件机制可以拦截Executor、StatementHandler、ParameterHandler、ResultSetHandler四大组件的执行。但请注意插件拦截不到MapperProxy和MapperMethod这一层。因为插件是在SqlSession执行过程中生效的。如果你想在方法调用层面做切面比如记录所有Mapper方法的执行时间需要在Spring的AOP层面实现或者使用MyBatis-Plus提供的SqlParser等工具。与Spring的集成Spring整合MyBatis时MapperScannerConfigurer或MapperScan注解负责扫描接口并为每个接口注册一个MapperFactoryBean。这个FactoryBean的getObject()方法返回的正是通过MapperProxyFactory创建的代理对象。所以你在Spring中Autowired的Mapper已经是代理对象了。6. 总结与个人体会走读一遍源码MyBatis动态代理的脉络就非常清晰了MapperProxyFactory制造代理 -MapperProxy拦截调用并分派 -MapperMethod翻译方法并执行路由 -SqlSession最终执行。它就像一个精密的流水线每个环节职责单一共同将一句简单的Java方法调用转化为一次完整的数据库交互。我个人在长期使用和排查问题的过程中最大的体会是理解MapperMethod.execute方法里的那个switch-case分支是解决大部分“结果不符合预期”问题的钥匙。它明确地告诉你MyBatis是如何根据你的方法定义来决定调用方式的。很多看似诡异的问题归根结底是“声明”与“实际”不匹配。另外不要畏惧阅读源码。MyBatis的源码质量很高结构清晰命名规范。从动态代理这个切入点进去顺着调用链往下走你不仅能更扎实地掌握这个框架还能学到不少优秀的设计思想。下次当你的同事为某个MyBatis问题抓耳挠腮时你可以淡定地说“走我们一起看看MapperProxy是怎么工作的。”
1. 引子为什么MyBatis的Mapper接口能直接调用如果你用过MyBatis肯定对下面这种写法不陌生定义一个UserMapper接口里面声明几个方法然后在Service层直接Autowired注入这个接口接着就能调用selectById、insert等方法了。整个过程里你并没有写这个接口的实现类。第一次接触时你可能会觉得有点“魔法”。一个接口没有实现类怎么能被实例化并调用呢这背后就是Java动态代理在“默默干活”。但MyBatis的动态代理和我们平时在Spring AOP里听到的JDK动态代理或CGLib代理目的和实现细节上又有很大不同。它不是为了给方法增强逻辑比如加个日志、事务而是为了将Java方法的调用翻译成一次数据库会话的执行。今天我们就抛开框架的“黑盒”直接钻进MyBatis的源码里看看这个“翻译官”到底是怎么工作的。理解了这个你不仅能更自信地使用MyBatis在遇到一些诡异的问题比如为什么这个方法没生效、参数是怎么绑定的时也能快速定位到根因。2. MyBatis动态代理的核心舞台MapperProxyFactory与MapperProxyMyBatis动态代理的入口非常明确就在org.apache.ibatis.binding.MapperProxyFactory这个类里。它的代码量很少但却是整个机制的“工厂”。2.1MapperProxyFactory代理对象的制造车间我们直接看它的核心方法public class MapperProxyFactoryT { private final ClassT mapperInterface; // ... 其他字段 protected T newInstance(MapperProxyT mapperProxy) { // 使用JDK动态代理创建实例 return (T) Proxy.newProxyInstance(mapperInterface.getClassLoader(), new Class[] { mapperInterface }, mapperProxy); } public T newInstance(SqlSession sqlSession) { // 创建 MapperProxy 这个InvocationHandler final MapperProxyT mapperProxy new MapperProxy(sqlSession, mapperInterface, methodCache); return newInstance(mapperProxy); } }这段代码揭示了几个关键信息工厂与接口绑定每个MapperProxyFactory实例在创建时就和一个具体的Mapper接口比如UserMapper.class绑定了。这个信息存储在mapperInterface字段里。JDK动态代理它明确使用了Proxy.newProxyInstance这是标准的JDK动态代理API。这说明MyBatis的Mapper代理只支持接口不支持类。这也是为什么MyBatis的Mapper必须是接口的原因。真正的核心是MapperProxyProxy.newProxyInstance的第三个参数是一个InvocationHandler的实现。在这里就是MapperProxy。所有对Mapper接口方法的调用最终都会路由到MapperProxy.invoke()方法里。MapperProxy才是那个真正的“翻译官”。所以流程很清晰当你从SqlSession里获取一个Mapper时比如sqlSession.getMapper(UserMapper.class)内部就是找到了或创建了对应的MapperProxyFactory然后调用newInstance方法生成了一个代理对象给你。你拿到的就是这个代理对象。2.2MapperProxy方法调用的总调度中心MapperProxy实现了InvocationHandler接口它的invoke方法是所有魔法发生的地方。我们来看它的简化逻辑public class MapperProxyT implements InvocationHandler, Serializable { Override public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { try { // 1. 如果是Object类自带的方法如toString, hashCode直接调用不走MyBatis逻辑 if (Object.class.equals(method.getDeclaringClass())) { return method.invoke(this, args); } // 2. 接口的默认方法Java 8也特殊处理 else if (method.isDefault()) { return invokeDefaultMethod(proxy, method, args); } } catch (Throwable t) { throw ExceptionUtil.unwrapThrowable(t); } // 3. 最关键的一步这才是我们的Mapper接口里声明的方法 final MapperMethod mapperMethod cachedMapperMethod(method); return mapperMethod.execute(sqlSession, args); } }这个invoke方法做了三件事优先级从高到低处理Object方法如果你调用了代理对象的toString()或equals()它不会去数据库查而是直接调用InvocationHandler也就是MapperProxy本身的对应方法。这很合理。处理默认方法从Java 8开始接口可以有default方法。MyBatis也支持在Mapper接口里写默认方法用于封装一些简单的逻辑。对于这类方法MyBatis会通过一些技巧invokeDefaultMethod去调用接口本身的默认实现而不是将其视为数据库操作。执行数据库方法排除了前两种情况剩下的就是你在Mapper接口里声明的、意图操作数据库的方法了。对于这些方法MapperProxy并没有自己处理而是转交给了另一个重量级角色MapperMethod。这里有个性能优化点cachedMapperMethod(method)。它会缓存MapperMethod实例。因为一个Method对象对应一个接口方法这个方法的执行逻辑对应哪条SQL、参数怎么解析、结果怎么映射在运行期是固定的。缓存起来可以避免重复创建提升性能。踩坑提示这里也隐含了一个潜在问题。MapperMethod的缓存是基于Method对象的。如果你用动态编译、字节码增强等技术在运行时生成了新的Method对象即使签名相同可能会导致缓存失效每次调用都创建新的MapperMethod带来性能损耗。不过这种场景非常罕见。至此MapperProxy完成了它的调度使命将皮球踢给了MapperMethod。真正的“翻译”工作现在才开始。3.MapperMethod将Java方法翻译成数据库命令MapperMethod这个类是理解MyBatis如何“理解”你写的接口方法的关键。它内部有两个非常重要的静态内部类SqlCommand和MethodSignature。3.1SqlCommandSQL命令的元数据SqlCommand负责解析一个方法对应的是什么类型的SQL操作SELECT, INSERT, UPDATE, DELETE等以及这条SQL语句的唯一标识。public static class SqlCommand { private final String name; // SQL语句的全局唯一ID 格式为 “namespace.id” private final SqlCommandType type; // 枚举UNKNOWN, INSERT, UPDATE, DELETE, SELECT, FLUSH }这个name就是你在Mapper XML文件中写的select id”selectById”中的id但前面会加上namespace通常是接口的全限定名。例如com.example.mapper.UserMapper.selectById。MyBatis在启动时会解析所有的XML和注解构建一个全局的Configuration对象里面就存储了所有name到MappedStatementSQL语句的完整描述的映射。SqlCommand在初始化时就是根据传入的Method对象去Configuration里查找对应的MappedStatement从而确定type。3.2MethodSignature方法签名的解析器MethodSignature则负责解析Java方法本身的特征返回值类型、参数列表、是否有Param注解等。这些信息对于后续的参数绑定和结果映射至关重要。public static class MethodSignature { private final boolean returnsMany; // 是否返回集合List, Map等 private final boolean returnsMap; // 是否返回Map private final boolean returnsVoid; // 是否返回void private final boolean returnsCursor; // 是否返回Cursor游标 private final boolean returnsOptional; // 是否返回OptionalJava 8 private final Class? returnType; // 返回类型 private final String mapKey; // 如果返回Map哪个参数作为key通过MapKey注解指定 private final Integer resultHandlerIndex; // 参数中ResultHandler的位置 private final Integer rowBoundsIndex; // 参数中RowBounds的位置用于内存分页已不推荐 private final ParamNameResolver paramNameResolver; // 参数名解析器 }其中最值得关注的是ParamNameResolver。它解决了Java编译后参数名丢失的问题默认编译为arg0, arg1。它的工作逻辑是如果方法参数用了Param(“id”)注解那就用注解指定的名字。如果没注解且编译时加了-parameters参数保留参数名就用真实的参数名。如果以上都不满足则使用param1,param2...作为参数名。这个解析出来的参数名映射关系在后面绑定SQL参数时会用到。3.3execute方法执行路由MapperMethod的核心是它的execute方法。它根据SqlCommand解析出的SQL类型SqlCommandType以及MethodSignature解析出的返回类型来决定最终调用SqlSession的哪个方法。public Object execute(SqlSession sqlSession, Object[] args) { Object result; switch (command.getType()) { case INSERT: { // 转换参数通常只有一个参数是待插入的对象 Object param method.convertArgsToSqlCommandParam(args); // 调用sqlSession.insert返回值是受影响的行数 result rowCountResult(sqlSession.insert(command.getName(), param)); break; } case UPDATE: { Object param method.convertArgsToSqlCommandParam(args); result rowCountResult(sqlSession.update(command.getName(), param)); break; } case DELETE: { Object param method.convertArgsToSqlCommandParam(args); result rowCountResult(sqlSession.delete(command.getName(), param)); break; } case SELECT: // 查询逻辑最复杂根据返回值类型细分 if (method.returnsVoid() method.hasResultHandler()) { // 使用ResultHandler处理结果无返回值 executeWithResultHandler(sqlSession, args); result null; } else if (method.returnsMany()) { // 返回集合如ListUser result executeForMany(sqlSession, args); } else if (method.returnsMap()) { // 返回Map result executeForMap(sqlSession, args); } else if (method.returnsCursor()) { // 返回Cursor游标 result executeForCursor(sqlSession, args); } else { // 返回单个对象 Object param method.convertArgsToSqlCommandParam(args); result sqlSession.selectOne(command.getName(), param); // 注意如果查询返回多条这里会抛出TooManyResultsException } break; case FLUSH: result sqlSession.flushStatements(); break; default: throw new BindingException(Unknown execution method for: command.getName()); } return result; }这个方法就像一个大型路由器它的逻辑非常直白增删改统一调用sqlSession的insert/update/delete核心是convertArgsToSqlCommandParam方法将方法参数数组转换为SQL可用的参数对象通常是一个Map或原始对象然后处理返回值将int行数转换为方法声明的返回值类型比如boolean。查询根据方法返回值类型分派到不同的执行路径。这是最容易出错的地方。selectOne期望返回单个对象。如果数据库返回0条则返回null如果返回多条则抛出TooManyResultsException。这是新手常踩的坑比如根据非唯一字段查询却用了selectOne。executeForMany用于返回集合内部调用sqlSession.selectList。executeForMap用于返回Map内部调用sqlSession.selectMap。带有ResultHandler的参数这是一种流式处理结果的方式适用于数据量极大、不想一次性加载到内存的场景。核心经验MapperMethod.execute方法清晰地展示了MyBatis如何将Java方法映射到SQL执行。当你遇到“方法调用结果不符合预期”时首先应该检查这里你的方法返回值类型是否匹配SQL实际执行的结果类型比如一个返回ListUser的方法其对应的SQL必须能返回多条记录如果SQL只返回一条MyBatis也会把它包装进List里包含一个元素这通常是符合预期的。但反过来一个返回User的方法如果SQL返回多条就会立刻报错。4. 参数绑定与SQL执行ParamNameResolver与SqlSession的协作前面提到MethodSignature里有个ParamNameResolver它在convertArgsToSqlCommandParam方法中扮演关键角色。我们看看这个方法做了什么public Object convertArgsToSqlCommandParam(Object[] args) { return paramNameResolver.getNamedParams(args); }ParamNameResolver.getNamedParams方法会将传入的参数数组转换成一个MapString, Object。这个Map的key就是解析出来的参数名Param值或param1等value就是对应的参数值。为什么是Map因为MyBatis的SQL解析器DynamicContext在替换#{}或${}占位符时默认就是从传入的Map或JavaBean对象中根据key即参数名或者property属性名来获取值的。例如你的接口方法是User selectById(Param(“userId”) Integer id, Param(“userStatus”) String status);经过ParamNameResolver处理后传给SqlSession的参数就是一个Map{“userId”: 123, “userStatus”: “ACTIVE”}。对应的XML SQL就可以写select id”selectById” resultType”User” SELECT * FROM user WHERE id #{userId} AND status #{userStatus} /select至此MapperMethod完成了从Java方法到SqlSession方法调用的翻译。它告诉SqlSession“请执行名字叫com.example.mapper.UserMapper.selectById的SQL这是给你的参数Map”。接下来的故事就交给了SqlSession默认实现是DefaultSqlSession和它的四大执行器Executor。它们负责根据SQL ID从Configuration里拿到完整的MappedStatement创建StatementHandler设置参数执行JDBC操作并通过ResultSetHandler将结果集映射成Java对象。这一部分属于MyBatis执行流程的更深层但动态代理的使命在将调用权交给SqlSession的那一刻就已经圆满完成了。5. 从动态代理看MyBatis的设计哲学与实战避坑理解了动态代理的原理我们就能从更高维度审视MyBatis并规避一些常见问题。5.1 设计哲学接口即契约配置即实现MyBatis通过动态代理完美实现了“接口与实现分离”。Mapper接口定义了做什么方法签名而XML或注解定义了怎么做SQL语句。这种设计让数据库操作代码变得非常清晰接口可以被JUnit轻易Mock也方便与Spring等框架集成。动态代理是连接这两者的“胶水”。5.2 常见问题与排查思路BindingException: Invalid bound statement (not found)根因这是最经典的错误。意味着MapperProxy在创建MapperMethod时其内部的SqlCommand无法根据接口方法名如selectById和接口全限定名在全局配置Configuration中找到对应的MappedStatement即SQL声明。排查步骤检查XML中的namespace必须和Mapper接口的全限定名完全一致一个字母都不能差。检查SQL语句的id必须和接口方法名完全一致。检查XML文件是否被扫描到检查MyBatis配置的mapperLocationsSpring Boot中是mybatis.mapper-locations是否包含了你的XML文件路径。检查是否有多处定义冲突同一个方法是否同时在XML和注解Select中定义了这可能导致冲突。方法调用返回null但数据库明明有数据根因大概率是MapperMethod.execute方法中调用了sqlSession.selectOne但你的SQL实际返回了0条记录可能是参数传错或者查询条件不匹配。selectOne对0条记录的处理就是返回null。排查打开MyBatis的SQL日志配置log4j.logger.org.apache.ibatisDEBUG或使用mybatis.log.free等插件查看实际执行的SQL和参数。确认你的方法返回值类型。如果是返回单个对象确保你的查询条件能唯一确定一条记录。抛TooManyResultsException异常根因和上一条相反。方法声明返回单个对象如User但SQL查询返回了多条记录。MapperMethod在selectOne分支中检测到多条结果就会抛出此异常。解决修改SQL确保查询条件具有唯一性例如加上LIMIT 1但需注意业务逻辑是否正确。或者修改接口方法让其返回集合类型如ListUser。Param注解失效参数绑定错误根因ParamNameResolver解析参数名失败最终使用了param1, param2作为key但你的SQL中用的是自定义名称。注意在Spring Boot项目中如果编译时未加-parameters参数且未使用Param注解MyBatis确实只能使用arg0, arg1或param1, param2。强烈建议为多参数方法显式加上Param注解这是最可靠的方式。5.3 性能与扩展点缓存MapperMethod对象是被缓存的避免了每次调用都重新解析方法签名和SQL命令。这是一个有效的性能优化。插件InterceptorMyBatis的插件机制可以拦截Executor、StatementHandler、ParameterHandler、ResultSetHandler四大组件的执行。但请注意插件拦截不到MapperProxy和MapperMethod这一层。因为插件是在SqlSession执行过程中生效的。如果你想在方法调用层面做切面比如记录所有Mapper方法的执行时间需要在Spring的AOP层面实现或者使用MyBatis-Plus提供的SqlParser等工具。与Spring的集成Spring整合MyBatis时MapperScannerConfigurer或MapperScan注解负责扫描接口并为每个接口注册一个MapperFactoryBean。这个FactoryBean的getObject()方法返回的正是通过MapperProxyFactory创建的代理对象。所以你在Spring中Autowired的Mapper已经是代理对象了。6. 总结与个人体会走读一遍源码MyBatis动态代理的脉络就非常清晰了MapperProxyFactory制造代理 -MapperProxy拦截调用并分派 -MapperMethod翻译方法并执行路由 -SqlSession最终执行。它就像一个精密的流水线每个环节职责单一共同将一句简单的Java方法调用转化为一次完整的数据库交互。我个人在长期使用和排查问题的过程中最大的体会是理解MapperMethod.execute方法里的那个switch-case分支是解决大部分“结果不符合预期”问题的钥匙。它明确地告诉你MyBatis是如何根据你的方法定义来决定调用方式的。很多看似诡异的问题归根结底是“声明”与“实际”不匹配。另外不要畏惧阅读源码。MyBatis的源码质量很高结构清晰命名规范。从动态代理这个切入点进去顺着调用链往下走你不仅能更扎实地掌握这个框架还能学到不少优秀的设计思想。下次当你的同事为某个MyBatis问题抓耳挠腮时你可以淡定地说“走我们一起看看MapperProxy是怎么工作的。”
