1.为什么 MyBatis 码分源码中，没有我那种 if···else
2.mybatis插件机制源码解析
3.Mybatis拼接sql出错及源码解析
4.MyBatis 码分源码解析：映射文件的加载与解析（上）
5.从源码角度分析 Mybatis 工作原理
6.Mybatis源码剖析（懒加载原理）

为什么 MyBatis 源码中，没有我那种 if···else

       在 MyBatis 码分源码中，设计模式的码分巧妙使用是整个框架的精华，共有约种模式，码分包括创建型、码分aps游戏交易源码结构型和行为型模式。码分

       创建型模式包括工厂模式、码分单例模式和建造者模式。码分工厂模式用于创建 SqlSessionFactory，码分单例模式确保 Configuration 的码分唯一实例，建造者模式将 XML 文件解析到对象中。码分

       结构型模式有适配器模式、码分代理模式、码分组合模式和装饰器模式。码分适配器模式使接口不兼容的对象可以协作，代理模式提供 DAO 接口的实现，组合模式用于 SQL 标签组合，装饰器模式允许在不修改结构的情况下增加行为。

       行为型模式包括模板模式、策略模式和迭代器模式。模板模式定义算法框架，策略模式允许算法的替换，迭代器模式遍历集合元素。

       总结，MyBatis 源码运用设计模式解决复杂问题，合理切割子问题，学习这些方案技术能提高对设计和实现的理解，扩展编码思维，积累经验，成为优秀工程师和架构师。仿 下载 源码

mybatis插件机制源码解析

       引言

       本篇源码解析基于MyBatis3.5.8版本。

       首先需要说明的是，本篇文章不是mybatis插件开发的教程，而是从源码层面分析mybatis是如何支持用户自定义插件开发的。

       mybatis的插件机制，让其扩展能力大大增加。比如我们项目中经常用到的PageHelper，这就是一款基于mybatis插件能力开发的产品，它的功能是让基于mybatis的数据库分页查询更容易使用。

       当然基于插件我们还可以开发其它功能，比如在执行sql前打印日志、做权限控制等。

正文

       mybatis插件也叫mybatis拦截器，它支持从方法级别对mybatis进行拦截。整体架构图如下：

       解释下几个相关概念：

       Interceptor拦截器接口，用户自定义的拦截器就是实现该接口。

       InterceptorChain拦截器链，其内部维护一个interceptorslist,表示拦截器链中所有的拦截器，并提供增加或获取拦截器链的方法。比如有个核心的方法是pluginAll。该方法用来生成代理对象。

       Invocation拦截器执行时的上下文环境，其实就是目标方法的调用信息，包含目标对象、调用的方法信息、参数信息。核心方法是proceed。该方法的主要目的就是进行处理链的传播，执行完拦截器的方法后，最终需要调用目标方法的wpe原版源码invoke方法。

       mybatis支持在哪些地方进行拦截呢？你只需要在代码里搜索interceptorChain.pluginAll的使用位置就可以获取答案，一共有四处：

parameterHandler=(ParameterHandler)interceptorChain.pluginAll(parameterHandler);resultSetHandler=(ResultSetHandler)interceptorChain.pluginAll(resultSetHandler);statementHandler=(StatementHandler)interceptorChain.pluginAll(statementHandler);executor=(Executor)interceptorChain.pluginAll(executor);

       这四处实现的原理都是一样的，我们只需要选择一个进行分析就可以了。

       我们先来看下自定义的插件是如何加载进来的，比如我们使用PageHelper插件，通常会在mybatis-config.xml中加入如下的配置：

<plugins><plugininterceptor="com.github.pagehelper.PageInterceptor"><!--configparamsasthefollowing--><propertyname="param1"value="value1"/></plugin></plugins>

       mybatis在创建SqlSessionFactory的时候会加载配置文件，

publicConfigurationparse(){ if(parsed){ thrownewBuilderException("EachXMLConfigBuildercanonlybeusedonce.");}parsed=true;parseConfiguration(parser.evalNode("/configuration"));returnconfiguration;}

       parseConfiguration方法会加载包括plugins在内的很多配置，

privatevoidparseConfiguration(XNoderoot){ try{ ...pluginElement(root.evalNode("plugins"));...}catch(Exceptione){ thrownewBuilderException("ErrorparsingSQLMapperConfiguration.Cause:"+e,e);}}privatevoidpluginElement(XNodeparent)throwsException{ if(parent!=null){ for(XNodechild:parent.getChildren()){ Stringinterceptor=child.getStringAttribute("interceptor");Propertiesproperties=child.getChildrenAsProperties();InterceptorinterceptorInstance=(Interceptor)resolveClass(interceptor).getDeclaredConstructor().newInstance();interceptorInstance.setProperties(properties);configuration.addInterceptor(interceptorInstance);}}}

       pluginElement干了几件事情：

       创建Interceptor实例

       设置实例的属性变量

       添加到Configuration的interceptorChain拦截器链中

       mybatis的插件是通过动态代理实现的，那肯定要生成代理对象，生成的逻辑就是前面提到的pluginAll方法，比如对于Executor生成代理对象就是，

executor=(Executor)interceptorChain.pluginAll(executor);

       接着看pluginAll方法，

/***该方法会遍历用户定义的插件实现类（Interceptor），并调用Interceptor的plugin方法，对target进行插件化处理，*即我们在实现自定义的Interceptor方法时，在plugin中需要根据自己的逻辑，对目标对象进行包装（代理），创建代理对象，*那我们就可以在该方法中使用Plugin#wrap来创建代理类。*/publicObjectpluginAll(Objecttarget){ for(Interceptorinterceptor:interceptors){ target=interceptor.plugin(target);}returntarget;}

       这里遍历所有我们定义的拦截器，调用拦截器的plugin方法生成代理对象。有人可能有疑问：如果有多个拦截器，target不是被覆盖了吗？

       其实不会，所以如果有多个拦截器的话，生成的代理对象会被另一个代理对象代理，从而形成一个代理链条，执行的时候，依次执行所有拦截器的拦截逻辑代码。

       plugin方法是密码破解源码接口Interceptor的默认实现类，

defaultObjectplugin(Objecttarget){ returnPlugin.wrap(target,this);}

       然后进入org.apache.ibatis.plugin.Plugin#wrap，

publicstaticObjectwrap(Objecttarget,Interceptorinterceptor){ Map<Class<?>,Set<Method>>signatureMap=getSignatureMap(interceptor);Class<?>type=target.getClass();Class<?>[]interfaces=getAllInterfaces(type,signatureMap);if(interfaces.length>0){ returnProxy.newProxyInstance(type.getClassLoader(),interfaces,newPlugin(target,interceptor,signatureMap));}returntarget;}

       首先是获取我们自己实现的Interceptor的方法签名映射表。然后获取需要代理的对象的Class上声明的所有接口。比如如果我们wrap的是Executor，就是Executor的所有接口。然后就是最关键的一步，用Proxy类创建一个代理对象（newProxyInstance）。

       注意，newProxyInstance方法的第三个参数，接收的是一个InvocationHandler对象，表示的是当动态代理对象调用方法的时候会关联到哪一个InvocationHandler对象上，并最终由其调用。

       我们这里传入的是Plugin类，故在动态运行过程中会执行Plugin的invoker方法。

       如果对这一段不是很理解，建议先了解下java动态代理的原理。java动态代理机制中有两个重要的角色：InvocationHandler（接口）和Proxy（类），这个是背景知识需要掌握的。

       我们在深入看下上面的getSignatureMap方法，

privatestaticMap<Class<?>,Set<Method>>getSignatureMap(Interceptorinterceptor){ //从Interceptor的类上获取Intercepts注解，说明我们自定义拦截器需要带注解InterceptsinterceptsAnnotation=interceptor.getClass().getAnnotation(Intercepts.class);//issue#if(interceptsAnnotation==null){ thrownewPluginException("No@Interceptsannotationwasfoundininterceptor"+interceptor.getClass().getName());}Signature[]sigs=interceptsAnnotation.value();Map<Class<?>,Set<Method>>signatureMap=newHashMap<>();//解析Interceptor的values属性（Signature[]）数组，存入HashMap,Set<Method>>for(Signaturesig:sigs){ Set<Method>methods=MapUtil.computeIfAbsent(signatureMap,sig.type(),k->newHashSet<>());try{ Methodmethod=sig.type().getMethod(sig.method(),sig.args());methods.add(method);}catch(NoSuchMethodExceptione){ thrownewPluginException("Couldnotfindmethodon"+sig.type()+"named"+sig.method()+".Cause:"+e,e);}}returnsignatureMap;}

       首先需要从Interceptor的类上获取Intercepts注解，说明我们自定义拦截器需要带注解，比如PageHelper插件的定义如下：

<plugins><plugininterceptor="com.github.pagehelper.PageInterceptor"><!--configparamsasthefollowing--><propertyname="param1"value="value1"/></plugin></plugins>0

       所以我们可以知道，getSignatureMap其实就是拿到我们自定义拦截器声明需要拦截的类以及类对应的方法。

       前面说过，当我们调用代理对象时，最终会执行Plugin类的invoker方法，我们看下Plugin的invoker方法，

<plugins><plugininterceptor="com.github.pagehelper.PageInterceptor"><!--configparamsasthefollowing--><propertyname="param1"value="value1"/></plugin></plugins>1

       Interceptor接口的牛小妹源码intercept方法就是我们自定义拦截器需要实现的逻辑，其参数为Invocation，可从Invocation参数中拿到执行方法的对象，方法，方法参数，比如我们可以从statementHandler拿到SQL语句，实现自己的特殊逻辑。

       在该方法的结束需要调用invocation#proceed()方法，进行拦截器链的传播。

       参考：

       blogs.com/chenpi/p/.html

Mybatis拼接sql出错及源码解析

       结论是，Mybatis在拼接SQL时出现意外条件添加，可能是由于别名与参数名冲突导致的。作者猜测，当在foreach循环中设置了别名exemptNo，Mybatis可能误将这个别名与参数关联，即使exemptNo值为空，也会在SQL中添加条件。这个行为实际上是一个潜在的bug，源于Mybatis在处理一次性使用的别名时的内存管理问题。

       深入分析，当在org.apache.ibatis.scripting.xmltags.DynamicSqlSource的getBoundSql方法中设置断点，可以看到exemptNo的空值状态表明该条件不应被添加。进一步在rootSqlNode.apply(context)的applyItem方法中，问题集中在DynamicContext对象的ContextMap上。它在遍历时将别名作为键存储，然而在操作结束后没有及时清理，导致了不必要的参数混淆。

       Mybatis的ContextMap设计用于存储SQL参数和临时键值对，但这里的问题在于，别名被永久性地存储在map中，而不是作为一次性使用的变量。因此，为了避免这类问题，应确保SQL的别名与实际参数名不冲突，以防止Mybatis的内存管理不当。

       总结来说，Mybatis在处理别名时的临时性考虑不足，导致了这个bug，提醒我们在使用Mybatis时，要注意别名的命名规则，以避免意外的SQL拼接错误。

MyBatis 源码解析：映射文件的加载与解析（上）

       MyBatis 的映射文件是其核心组成部分，用于配置 SQL 语句、二级缓存及结果集映射等功能，是其区别于其他 ORM 框架的重要特色。

       在解析映射文件时，MyBatis 通过调用 XMLMapperBuilder#parse 方法实现加载与解析操作。此方法首先判断映射文件是否已解析，若未解析则调用 XMLMapperBuilder#configurationElement 方法解析所有配置，并注册当前映射文件关联的 Mapper 接口。对于处理异常的标签，MyBatis 会记录至 Configuration 对象并尝试二次解析。

       解析流程主要涉及以下几个关键步骤：

       缓存配置（cache 标签）：MyBatis 采用缓存设计，分为一级缓存和二级缓存。解析 cache 标签时，首先获取相关属性配置，然后使用 CacheBuilder 创建缓存对象，并记录到 Configuration 对象。

       缓存引用（cache-ref 标签）：标签默认限定在 namespace 范围内，用于引用其它命名空间中的缓存对象。解析过程中记录引用关系，然后从 Configuration 中获取引用的缓存对象。

       结果集映射（resultMap 标签）：解析 resultMap 标签配置，构建 ResultMap 对象，并将其记录到 Configuration 中。

       SQL 语句（sql 标签）：通过 sql 标签配置复用的 SQL 语句片段，解析后记录至 Configuration 的 sqlFragments 属性中。

       核心数据库操作（select / insert / update / delete 标签）：解析这些标签时，构建 MappedStatement 对象并记录到 Configuration 中。

       每个标签解析实现由 MyBatis 提供的多个方法执行，如 XMLMapperBuilder 的 configurationElement 方法和解析具体标签的子方法，如 cacheElement、sqlElement 等。解析过程中，MyBatis 会调用不同的构造器和工厂方法来创建、初始化和配置相应的对象。

       在解析完成之后，MyBatis 将所有配置对象封装在 Configuration 对象中，该对象包含所有映射文件中定义的配置信息，供后续的 SQL 语句执行和映射操作使用。

从源码角度分析 Mybatis 工作原理

       本文以入门级示例说明 MyBatis 工作原理，涵盖数据库准备、添加 MyBatis、配置、Mapper、测试程序、生命周期、映射器、架构、SqlSession 机制等内容。通过源码解析详细展现 MyBatis 如何将 Java 代码与数据库操作紧密结合。

       数据库准备：针对用户表进行 CRUD 操作，设计数据模型。

       添加 MyBatis：Maven 依赖配置，引入 MyBatis 依赖。

       MyBatis 配置：XML 配置文件设置数据源、事务管理器。

       Mapper：包含 Mapper.xml 和 Mapper.java 文件，实现 SQL 模板与 Java 对象绑定。

       测试程序：MyBatisDemo.java 文件，展示如何使用 SqlSession 执行操作。

       MyBatis 生命周期：SqlSessionFactoryBuilder、SqlSessionFactory、SqlSession 的创建、使用与释放。

       映射器：接口定义与动态代理生成，完成 SQL 与 Java 方法的映射。

       架构：配置层、接口层、数据处理层、框架支撑层，展现 MyBatis 体系结构。

       SqlSession 内部工作机制：解析 SQL、管理缓存、执行事务、处理结果集。

       总结：MyBatis 通过封装、映射、执行等机制，简化了 Java 与数据库的交互过程，实现数据操作的便捷与高效。

Mybatis源码剖析（懒加载原理）

       懒加载，即按需加载，旨在优化查询性能。以一个包含订单列表的User对象为例，当仅获取用户信息时，若启用懒加载模式，执行SQL不会查询订单列表。需获取订单列表时，才会发起数据库查询。实现方式包括在核心配置文件中设置或在相关映射文件中通过fetchType属性配置懒加载策略。

       懒加载的配置如何加载到项目中呢？首先，这些配置保存在全局Configuration对象中，通常在解析核心配置文件的代码中实现。在settingsElement方法中，懒加载配置被保存在lazyLoadingEnabled属性中。对于resultMap标签中collection | association的fetchType属性，其配置通过解析mappers标签下的resultMap标签实现，最终调用buildResultMappingFromContext方法处理子标签。该方法结合全局配置判断是否需要执行懒加载。

       懒加载的实现原理涉及动态代理。当调用代理对象的延迟加载属性方法时，如访问a.getB().getName()，代理对象会调用拦截器方法。若发现需要延迟加载，代理对象会单独发送SQL查询关联对象，加载数据后设置属性值，完成方法调用。简而言之，懒加载通过动态代理实现，拦截指定方法并执行数据加载。

       深入剖析懒加载源码，会发现它涉及查询和数据处理的多步操作。查询完成后，结果集处理、列值获取、判断是否进行懒加载等步骤共同构建懒加载机制。动态代理在访问对象属性时触发，最终通过Javassist库创建代理对象，实现懒加载逻辑。当访问如userList2.get(0).getOrderList()时，若满足条件，代理对象会调用懒加载查询方法获取数据。判断懒加载条件的关键在于结果集处理阶段，通过访问映射关系和查询映射值来确定是否执行后续懒加载查询。

       综上所述，Mybatis的懒加载机制通过动态代理和结果集处理实现，旨在优化性能，按需加载数据，提高查询效率。通过核心配置和映射文件中的配置，懒加载逻辑被加载到项目中，为开发者提供灵活的加载策略。