这里写目录标题
起点
回到最初的起点，我们回顾一下mybatis执行一次查询的过程
从上面的图中可以看到与数据库交互最为密切的是SqlSession对象，一般来说我们通过调用org.apache.ibatis.session.SqlSessionFactory#openSession()来获得一个SqlSession对象，然后有两种方式来执行SQL，一种是直接执行SQL，一种是通过SqlSession获取到Mapper对象，然后调用Mapper的方法来执行SQL。但是，其实调用Mapper的方法访问数据库，其实在底层也是调用SqlSession的方法来访问数据库的
getMapper
DefaultSqlSession在实现getMapper时，是从Configuration里获取Mapper的，代码如下：Configuration.getMapper又调用到了MapperRegistry
最终调用到了这里org.apache.ibatis.binding.MapperRegistry#getMapper
从这个代码片段中可以看出，Mapper对象其实是由一个代理工厂MapperProxyFactory创建的，并且创建时，传入了SqlSession对象。org.apache.ibatis.binding.MapperProxyFactory#newInstance的源码如下：
从这里已经可以很明显的看出来Mybatis先是new了一个InvocationHandler，然后创建了一个代理。
我们看下org.apache.ibatis.binding.MapperProxy#invoke的具体逻辑
在上面的代码中，Mybatis先是判断了一下是都是需要被代理的方法，如果不需要被代理，放行即可。值得注意的是，在执行代理的方法时，Mybatis先获取了一个mapperMethod对象，然后调用了mapperMethod.execute方法
看下mapperMethod对象的创建方法，其实逻辑也很简单，每一个被代理的Method对象都对应着一个MapperMethod对象，然后将它们的对应关系维护在一个Map中，源码如下：
由于最终在MapperProxy.invoke中调用的是mapperMethod.execute，所以搞懂MapperMethod很重要。
在MapperMethod的构造器中，new了两个对象，如下：
其中，SqlCommand对象相对简单，在这个对象中计算出了当前方法需要执行的MappedStatementId，因为在Mapper中，方法名需要跟XML中的SQL Id一致，所以当获取到类名+方法名时，具体要执行的SQL Id也就知道了，关键逻辑如下：MethodSignature相对复杂一些，在MethodSignature中主要就是分析了返回值的类型（不同的返回值类型将来需要调用SqlSession不同的方法）和参数类型以及解析参数上的注解（参数的解析是由ParamNameResolver完成的）
其中ParamNameResolver的源码如下：
public ParamNameResolver(Configuration config, Method method) {
final Class<?>[] paramTypes = method.getParameterTypes();
final Annotation[][] paramAnnotations = method.getParameterAnnotations();
final SortedMap<Integer, String> map = new TreeMap<Integer, String>();
int paramCount = paramAnnotations.length;
// get names from @Param annotations
for (int paramIndex = 0; paramIndex < paramCount; paramIndex++) {
if (isSpecialParameter(paramTypes[paramIndex])) {
// skip special parameters
continue;
}
String name = null;
for (Annotation annotation : paramAnnotations[paramIndex]) {
if (annotation instanceof Param) {
hasParamAnnotation = true;
name = ((Param) annotation).value();
break;
}
}
if (name == null) {
// @Param was not specified.
if (config.isUseActualParamName()) {
name = getActualParamName(method, paramIndex);
}
if (name == null) {
// use the parameter index as the name ("0", "1", ...)
// gcode issue #71
name = String.valueOf(map.size());
}
}
map.put(paramIndex, name);
}
names = Collections.unmodifiableSortedMap(map);
}
如果Mapper的参数是@Param("parenId")String parentId,Map<String,Object> param最后生成{1:"parentId",2:arg1}这样的map对象
最后，在调用mapperMethod.execute时，如果是SELECT语句，那么就会执行下面的这段代码：
假如当前调用的方法返回的是列表，那么将会调用链路将会是这样的MapperMethod.executeForMany->SqlSession.selectList->Executor.query，最后会调用到这里，org.apache.ibatis.executor.BaseExecutor#query(org.apache.ibatis.mapping.MappedStatement, java.lang.Object, org.apache.ibatis.session.RowBounds, org.apache.ibatis.session.ResultHandler)，如下图：
之前我们说过，Mybatis在解析XML中的SQL后，会生成MappedStatement对象，但是这个对象是一个定义期的对象，当传入上下文参数后，才能被解析为运行期对象BoundSql，MappedStatement的getBoundSql方法其实是由SqlSource来执行的，我们主要看下DynamicSqlSource的处理逻辑：
图中的rootSqlNode是一个SqlNode对象，关键的处理逻辑在于rootSqlNode.apply(context)，大家各自处理自己的逻辑即可，如下图所示：
最后，我们看下真正执行查询的地方：org.apache.ibatis.executor.SimpleExecutor#doQuery
这里需要关注一下Statement对象的获取，在获取Statement之前，程序先获取了一下Connection
从图中可以看到，如果启用了日志，那么返回的Connection对象其实是一个代理对象，通过代理Connection对象创建的PreparedStatement对象也是个代理对象org.apache.ibatis.logging.jdbc.ConnectionLogger#invoke代码如下：
到这里为止，通过Mapper调用方法最后查询数据库的整个流程就基本走完了，在整个流程中有三个地方都用到了代理，Mapper本身、Connection、Statement，从这些源码中我也感受到代理可以让整个程序变得更加灵活，尤其是记录日志那块（Connection代理和Statement代理），如果要是我写的话，估计就直接logger.info了。这次学到了，可以创建代理，然后在代理中输出日志，这样接口统一，对外层调用的代码非常友好