皮皮网

1.阿里技术官架构使用总结：Spring源码+MyBatis源码+Tomcat架构解析等
2.MyBatis 码解源码解析：映射文件的加载与解析（上）
3.mybatis插件机制源码解析
4.Mybatis拼接sql出错及源码解析
5.MyBatis源码解析之基础模块—TypeHandler
6.一文搞懂Mybatis插件原理

阿里技术官架构使用总结：Spring源码+MyBatis源码+Tomcat架构解析等

       分享Java技术文以及学习经验也有一段时间了，实际作为程序员，码解我们都清楚学习的码解重要性，毕竟时代在发展，码解互联网之下，码解稍有落后可能就会被淘汰掉，码解saas租房系统源码因此我们需要不断审视自己，码解通过学习来提升自己。码解

       对于大多数程序员而言，码解阿里一直是码解目标，但进入大厂工作并非易事。码解今日，码解由阿里一线P8架构师揭秘，码解对其使用的码解技术进行总结，此PDF总结主要涉及Spring源码、码解MyBatis源码以及Tomcat架构解析等，以期帮助大家提升。

       如果你需要PDF版本，可直接点击下方链接免费获取。

       第一部分：Spring源码深度解析

       一、核心实现

       二、企业应用

       第二部分：MyBatis源码解析

       一、MyBatis入门

       二、配置文件解析过程

       三、映射文件解析过程

       四、SQL执行流程

       五、内置数据源

       六、缓存机制

       七、插件机制

       第三部分：Tomcat架构解析

       一、Tomcat介绍

       二、投票网站 源码Tomcat总体架构

       三、Catalina

       四、Coyote

       五、Jasper

       六、Tomcat配置管理

       七、Web服务器集成

       八、Tomcat集群

       九、Tomcat安全

       十、Tomcat性能调优

       十一、Tomcat附加功能

       总结：

       作为Java程序员，务必不断充实自己的知识储备，关于阿里等一线大厂所使用的技术，应心中有数。

       最后，提醒一句，所学知识均为己有，如果你需要这些架构技术使用总结，我愿意免费分享，有兴趣的老铁请点击下方链接免费领取。若支持我这篇文章，不妨点赞+喜欢+收藏一键三连，谢谢！

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

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

       在解析映射文件时，MyBatis 通过调用 XMLMapperBuilder#parse 方法实现加载与解析操作。此方法首先判断映射文件是php 房产源码否已解析，若未解析则调用 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 会调用不同的构造器和工厂方法来创建、初始化和配置相应的对象。

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

mybatis插件机制源码解析

       引言

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

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

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

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

正文

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

       解释下几个相关概念：

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

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

       Invocation拦截器执行时的上下文环境，其实就是目标方法的调用信息，包含目标对象、调用的方法信息、参数信息。kdj指标源码核心方法是proceed。该方法的主要目的就是进行处理链的传播，执行完拦截器的方法后，最终需要调用目标方法的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源码解析之基础模块—TypeHandler

       MyBatis源码解析之基础模块—TypeHandler

       在MyBatis的上一章节中，我们探讨了Plugin模块的拦截器配置和自定义。接下来，我们将深入理解数据库与Java对象之间转换的核心机制，即Type模块的源码。

       Type模块位于org.apache.ibatis.type，其架构设计包含IntegerTypeHandler和UnknownTypeHandler等实现类，用于处理不同类型的转换。JdbcType枚举定义了常见的数据库数据类型，MappedTypes和MappedJdbcTypes注解用于标注Java类型和数据库类型的映射。

       对于类型转换，TypeHandler是核心接口，它定义了处理方法。BaseTypeHandler是抽象基类，采用模板方法模式，提供了通用逻辑，而具体实现由子类如IntegerTypeHandler完成。对于没有明确泛型类型的转换，UnknownTypeHandler则负责处理。

       TypeAliasRegister负责注册Java常用数据类型的别名，而TypeHandlerRegister是类型转换器的注册中心，MyBatis在初始化时已经自动注册了常用TypeHandler。ResultSetWrapper则负责包装ResultSet，提供类型转换器的获取，最终由ResultSetHandler处理实际的数据处理。

       总结来说，Type模块在MyBatis中负责数据的类型转换，通过TypeHandler和相关的注册机制，确保了数据库操作与Java对象之间的无缝对接。在实际开发中，无需过多配置，MyBatis就能自动完成类型转换，使得开发更为便捷。

一文搞懂Mybatis插件原理

       Mybatis插件原理详解，让你轻松实现自定义功能

       在深入Mybatis源码时，你可能会遇到名为"plugin"的包，这实际上用于扩展框架的功能，如PageHelper分页插件。本文将揭示插件的运作机制，教你如何理解其内部工作并自行实现，如分页或慢SQL统计。

       使用PageHelper插件分页的简单步骤是：一，在pom.xml中添加依赖；二，在mybatis-config.xml中配置插件；三，在需要分页的mapper接口前调用startPage方法，并确保每次查询后关闭Page对象以避免数据冲突。

       接下来，我们将探索插件的总体流程：首先，通过拦截器接口实现动态代理，如PageInterceptor，它会在Executor的query方法执行前后添加自定义逻辑。拦截器通过Invocation对象获取目标对象和方法参数，实现增强功能。

       分页拦截器如PageInterceptor拦截query方法，若需要分页，会获取原始SQL并添加limit语句。配置插件时，在mybatis-config.xml中添加相应拦截器，如``标签和Interceptor实现类的全限定名。

       当我们创建SqlSession时，拦截器通过Configuration的newExecutor方法注册并应用到Executor对象上，利用JDK动态代理生成增强的代理对象，从而在执行SQL时调用拦截器的intercept方法。

       自定义慢SQL统计插件同样基于Interceptor，只需配置目标对象为StatementHandler，拦截方法为query、update或batch，然后在配置文件中添加插件的全限定名。