MyBatis 源码分析

* 本文速览

本篇文章较为详细的介绍了 MyBatis 执行 SQL 的过程。该过程本身比较复杂，牵涉到的技术点比较多。包括但不限于 Mapper 接口代理类的生成、接口方法的解析、SQL 语句的解析、运行时参数的绑定、查询结果自动映射、延迟加载等。本文对所列举的技术点，以及部分未列举的技术点都做了较为详细的分析。全文篇幅很大，需要大家耐心阅读。下面来看一下本文的目录：

源码分析类文章通常比较枯燥。因此，我在分析源码的过程中写了一些示例，同时也绘制了一些图片。希望通过这些示例和图片，帮助大家理解 MyBatis 的源码。

本篇文章篇幅很大，全文字数约 26000 字，阅读时间预计超过 100 分钟。通读本文可能会比较累，大家可以分次阅读。好了，本文的速览就先到这，下面进入正文。

1.简介

在前面的文章中，我分析了配置文件和映射文件的解析过程。经过前面复杂的解析过程后，现在，MyBatis 已经进入了就绪状态，等待使用者发号施令。本篇文章我将分析MyBatis 执行 SQL 的过程，该过程比较复杂，涉及的技术点很多。包括但不限于以下技术点：

1. 为 mapper 接口生成实现类
2. 根据配置信息生成 SQL，并将运行时参数设置到 SQL 中
3. 一二级缓存的实现
4. 插件机制
5. 数据库连接的获取与管理
6. 查询结果的处理，以及延迟加载等

如果大家能掌握上面的技术点，那么对 MyBatis 的原理将会有很深入的理解。若将以上技术点一一展开分析，会导致文章篇幅很大，因此我打算将以上知识点分成数篇文章进行分析。本篇文章将分析以上列表中的第1个、第2个以及第6个技术点，其他技术点将会在随后的文章中进行分析。好了，其他的就不多说了，下面开始我们的源码分析之旅。

2.SQL 执行过程分析

2.1 SQL 执行入口分析

在单独使用 MyBatis 进行数据库操作时，我们通常都会先调用 SqlSession 接口的 getMapper 方法为我们的 Mapper 接口生成实现类。然后就可以通过 Mapper 进行数据库操作。比如像下面这样：

1ArticleMapper articleMapper = session.getMapper(ArticleMapper.class);
2Article article = articleMapper.findOne(1);

如果大家对 MyBatis 较为理解，会知道 SqlSession 是通过 JDK 动态代理的方式为接口生成代理对象的。在调用接口方法时，方法调用会被代理逻辑拦截。在代理逻辑中可根据方法名及方法归属接口获取到当前方法对应的 SQL 以及其他一些信息，拿到这些信息即可进行数据库操作。

上面是一个简版的 SQL 执行过程，省略了很多细节。下面我们先按照这个简版的流程进行分析，首先我们来看一下 Mapper 接口的代理对象创建过程。

2.1.1 为 Mapper 接口创建代理对象

本节，我们从 DefaultSqlSession 的 getMapper 方法开始看起，如下：

1// -☆- DefaultSqlSession
2public <T> T getMapper(Class<T> type) {
3    return configuration.<T>getMapper(type, this);
4}
5
6// -☆- Configuration
7public <T> T getMapper(Class<T> type, SqlSession sqlSession) {
8    return mapperRegistry.getMapper(type, sqlSession);
9}
10
11// -☆- MapperRegistry
12public <T> T getMapper(Class<T> type, SqlSession sqlSession) {
13    // 从 knownMappers 中获取与 type 对应的 MapperProxyFactory
14    final MapperProxyFactory<T> mapperProxyFactory = (MapperProxyFactory<T>) knownMappers.get(type);
15    if (mapperProxyFactory == null) {
16        throw new BindingException("Type " + type + " is not known to the MapperRegistry.");
17    }
18    try {
19        // 创建代理对象
20        return mapperProxyFactory.newInstance(sqlSession);
21    } catch (Exception e) {
22        throw new BindingException("Error getting mapper instance. Cause: " + e, e);
23    }
24}

如上，经过连续的调用，Mapper 接口代理对象的创建逻辑初现端倪。如果没看过我前面的分析文章，大家可能不知道 knownMappers 集合中的元素是何时存入的。这里再说一遍吧，MyBatis 在解析配置文件的 <mappers> 节点的过程中，会调用 MapperRegistry 的 addMapper 方法将 Class 到 MapperProxyFactory 对象的映射关系存入到 knownMappers。具体的代码就不分析了，大家可以阅读我之前写的文章，或者自行分析相关的代码。

在获取到 MapperProxyFactory 对象后，即可调用工厂方法为 Mapper 接口生成代理对象了。相关逻辑如下：

1// -☆- MapperProxyFactory
2public T newInstance(SqlSession sqlSession) {
3    /*
4     * 创建 MapperProxy 对象，MapperProxy 实现了 
5     * InvocationHandler 接口，代理逻辑封装在此类中
6     */
7    final MapperProxy<T> mapperProxy = new MapperProxy<T>(sqlSession, mapperInterface, methodCache);
8    return newInstance(mapperProxy);
9}
10
11protected T newInstance(MapperProxy<T> mapperProxy) {
12    // 通过 JDK 动态代理创建代理对象
13    return (T) Proxy.newProxyInstance(mapperInterface.getClassLoader(), new Class[]{mapperInterface}, mapperProxy);
14}

上面的代码首先创建了一个 MapperProxy 对象，该对象实现了 InvocationHandler 接口。然后将对象作为参数传给重载方法，并在重载方法中调用 JDK 动态代理接口为 Mapper 生成代理对象。

到此，关于 Mapper 接口代理对象的创建过程就分析完了。现在我们的 ArticleMapper 接口指向的代理对象已经创建完毕，下面就可以调用接口方法进行数据库操作了。由于接口方法会被代理逻辑拦截，所以下面我们把目光聚焦在代理逻辑上面，看看代理逻辑会做哪些事情。

2.1.2 执行代理逻辑

在 MyBatis 中，Mapper 接口方法的代理逻辑实现的比较简单。该逻辑首先会对拦截的方法进行一些检测，以决定是否执行后续的数据库操作。对应的代码如下：

1public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
2    try {
3        // 如果方法是定义在 Object 类中的，则直接调用
4        if (Object.class.equals(method.getDeclaringClass())) {
5            return method.invoke(this, args);
6            
7        /*
8         * 下面的代码最早出现在 mybatis-3.4.2 版本中，用于支持 JDK 1.8 中的
9         * 新特性 - 默认方法。这段代码的逻辑就不分析了，有兴趣的同学可以
10         * 去 Github 上看一下相关的相关的讨论（issue #709），链接如下：
11         * 
12         *   https://github.com/mybatis/mybatis-3/issues/709
13         */  
14        } else if (isDefaultMethod(method)) {
15            return invokeDefaultMethod(proxy, method, args);
16        }
17    } catch (Throwable t) {
18        throw ExceptionUtil.unwrapThrowable(t);
19    }
20    
21    // 从缓存中获取 MapperMethod 对象，若缓存未命中，则创建 MapperMethod 对象
22    final MapperMethod mapperMethod = cachedMapperMethod(method);
23    
24    // 调用 execute 方法执行 SQL
25    return mapperMethod.execute(sqlSession, args);
26}

如上，代理逻辑会首先检测被拦截的方法是不是定义在 Object 中的，比如 equals、hashCode 方法等。对于这类方法，直接执行即可。除此之外，MyBatis 从 3.4.2 版本开始，对 JDK 1.8 接口的默认方法提供了支持，具体就不分析了。完成相关检测后，紧接着从缓存中获取或者创建 MapperMethod 对象，然后通过该对象中的 execute 方法执行 SQL。在分析 execute 方法之前，我们先来看一下 MapperMethod 对象的创建过程。MapperMethod 的创建过程看似普通，但却包含了一些重要的逻辑，所以不能忽视。

2.1.2.1 创建 MapperMethod 对象

本节来分析一下 MapperMethod 的构造方法，看看它的构造方法中都包含了哪些逻辑。如下：

1public class MapperMethod {
2
3    private final SqlCommand command;
4    private final MethodSignature method;
5
6    public MapperMethod(Class<?> mapperInterface, Method method, Configuration config) {
7        // 创建 SqlCommand 对象，该对象包含一些和 SQL 相关的信息
8        this.command = new SqlCommand(config, mapperInterface, method);
9        // 创建 MethodSignature 对象，从类名中可知，该对象包含了被拦截方法的一些信息
10        this.method = new MethodSignature(config, mapperInterface, method);
11    }
12}

如上，MapperMethod 构造方法的逻辑很简单，主要是创建 SqlCommand 和 MethodSignature 对象。这两个对象分别记录了不同的信息，这些信息在后续的方法调用中都会被用到。下面我们深入到这两个类的构造方法中，探索它们的初始化逻辑。

① 创建 SqlCommand 对象

前面说了 SqlCommand 中保存了一些和 SQL 相关的信息，那具体有哪些信息呢？答案在下面的代码中。

1public static class SqlCommand {
2
3    private final String name;
4    private final SqlCommandType type;
5
6    public SqlCommand(Configuration configuration, Class<?> mapperInterface, Method method) {
7        final String methodName = method.getName();
8        final Class<?> declaringClass = method.getDeclaringClass();
9        // 解析 MappedStatement
10        MappedStatement ms = resolveMappedStatement(mapperInterface, methodName, declaringClass, configuration);
11        
12        // 检测当前方法是否有对应的 MappedStatement
13        if (ms == null) {
14            // 检测当前方法是否有 @Flush 注解
15            if (method.getAnnotation(Flush.class) != null) {
16                // 设置 name 和 type 遍历
17                name = null;
18                type = SqlCommandType.FLUSH;
19            } else {
20                /*
21                 * 若 ms == null 且方法无 @Flush 注解，此时抛出异常。
22                 * 这个异常比较常见，大家应该眼熟吧
23                 */ 
24                throw new BindingException("Invalid bound statement (not found): "
25                    + mapperInterface.getName() + "." + methodName);
26            }
27        } else {
28            // 设置 name 和 type 变量
29            name = ms.getId();
30            type = ms.getSqlCommandType();
31            if (type == SqlCommandType.UNKNOWN) {
32                throw new BindingException("Unknown execution method for: " + name);
33            }
34        }
35    }
36}

如上，SqlCommand 的构造方法主要用于初始化它的两个成员变量。代码不是很长，逻辑也不难理解，就不多说了。继续往下看。

② 创建 MethodSignature 对象

MethodSignature 即方法签名，顾名思义，该类保存了一些和目标方法相关的信息。比如目标方法的返回类型，目标方法的参数列表信息等。下面，我们来分析一下 MethodSignature 的构造方法。

1public static class MethodSignature {
2
3    private final boolean returnsMany;
4    private final boolean returnsMap;
5    private final boolean returnsVoid;
6    private final boolean returnsCursor;
7    private final Class<?> returnType;
8    private final String mapKey;
9    private final Integer resultHandlerIndex;
10    private final Integer rowBoundsIndex;
11    private final ParamNameResolver paramNameResolver;
12
13    public MethodSignature(Configuration configuration, Class<?> mapperInterface, Method method) {
14
15        // 通过反射解析方法返回类型
16        Type resolvedReturnType = TypeParameterResolver.resolveReturnType(method, mapperInterface);
17        if (resolvedReturnType instanceof Class<?>) {
18            this.returnType = (Class<?>) resolvedReturnType;
19        } else if (resolvedReturnType instanceof ParameterizedType) {
20            this.returnType = (Class<?>) ((ParameterizedType) resolvedReturnType).getRawType();
21        } else {
22            this.returnType = method.getReturnType();
23        }
24        
25        // 检测返回值类型是否是 void、集合或数组、Cursor、Map 等
26        this.returnsVoid = void.class.equals(this.returnType);
27        this.returnsMany = configuration.getObjectFactory().isCollection(this.returnType) || this.returnType.isArray();
28        this.returnsCursor = Cursor.class.equals(this.returnType);
29        // 解析 @MapKey 注解，获取注解内容
30        this.mapKey = getMapKey(method);
31        this.returnsMap = this.mapKey != null;
32        /*
33         * 获取 RowBounds 参数在参数列表中的位置，如果参数列表中
34         * 包含多个 RowBounds 参数，此方法会抛出异常
35         */ 
36        this.rowBoundsIndex = getUniqueParamIndex(method, RowBounds.class);
37        // 获取 ResultHandler 参数在参数列表中的位置
38        this.resultHandlerIndex = getUniqueParamIndex(method, ResultHandler.class);
39        // 解析参数列表
40        this.paramNameResolver = new ParamNameResolver(configuration, method);
41    }
42}

上面的代码用于检测目标方法的返回类型，以及解析目标方法参数列表。其中，检测返回类型的目的是为避免查询方法返回错误的类型。比如我们要求接口方法返回一个对象，结果却返回了对象集合，这会导致类型转换错误。关于返回值类型的解析过程先说到这，下面分析参数列表的解析过程。

1public class ParamNameResolver {
2
3    private static final String GENERIC_NAME_PREFIX = "param";
4    private final SortedMap<Integer, String> names;
5
6    public ParamNameResolver(Configuration config, Method method) {
7        // 获取参数类型列表
8        final Class<?>[] paramTypes = method.getParameterTypes();
9        // 获取参数注解
10        final Annotation[][] paramAnnotations = method.getParameterAnnotations();
11        final SortedMap<Integer, String> map = new TreeMap<Integer, String>();
12        int paramCount = paramAnnotations.length;
13
14        for (int paramIndex = 0; paramIndex < paramCount; paramIndex++) {
15            // 检测当前的参数类型是否为 RowBounds 或 ResultHandler
16            if (isSpecialParameter(paramTypes[paramIndex])) {
17                continue;
18            }
19            String name = null;
20            for (Annotation annotation : paramAnnotations[paramIndex]) {
21                if (annotation instanceof Param) {
22                    hasParamAnnotation = true;
23                    // 获取 @Param 注解内容
24                    name = ((Param) annotation).value();
25                    break;
26                }
27            }
28            // name 为空，表明未给参数配置 @Param 注解
29            if (name == null) {
30                // 检测是否设置了 useActualParamName 全局配置
31                if (config.isUseActualParamName()) {
32                    /*
33                     * 通过反射获取参数名称。此种方式要求 JDK 版本为 1.8+，
34                     * 且要求编译时加入 -parameters 参数，否则获取到的参数名
35                     * 仍然是 arg1, arg2, ..., argN
36                     */
37                    name = getActualParamName(method, paramIndex);
38                }
39                if (name == null) {
40                    /*
41                     * 使用 map.size() 返回值作为名称，思考一下为什么不这样写：
42                     *   name = String.valueOf(paramIndex);
43                     * 因为如果参数列表中包含 RowBounds 或 ResultHandler，这两个参数
44                     * 会被忽略掉，这样将导致名称不连续。
45                     *
46                     * 比如参数列表 (int p1, int p2, RowBounds rb, int p3)
47                     *  - 期望得到名称列表为 ["0", "1", "2"]
48                     *  - 实际得到名称列表为 ["0", "1", "3"]
49                     */
50                    name = String.valueOf(map.size());
51                }
52            }
53            // 存储 paramIndex 到 name 的映射
54            map.put(paramIndex, name);
55        }
56        names = Collections.unmodifiableSortedMap(map);
57    }
58}

以上就是方法参数列表的解析过程，解析完毕后，可得到参数下标到参数名的映射关系，这些映射关系最终存储在 ParamNameResolver 的 names 成员变量中。这些映射关系将会在后面的代码中被用到，大家留意一下。

下面写点代码测试一下 ParamNameResolver 的解析逻辑。如下：

1public class ParamNameResolverTest {
2
3    @Test
4    public void test() throws NoSuchMethodException, NoSuchFieldException, IllegalAccessException {
5        Configuration config = new Configuration();
6        config.setUseActualParamName(false);
7        Method method = ArticleMapper.class.getMethod("select", Integer.class, String.class, RowBounds.class, Article.class);
8
9        ParamNameResolver resolver = new ParamNameResolver(config, method);
10        Field field = resolver.getClass().getDeclaredField("names");
11        field.setAccessible(true);
12        // 通过反射获取 ParamNameResolver 私有成员变量 names
13        Object names = field.get(resolver);
14
15        System.out.println("names: " + names);
16    }
17
18    class ArticleMapper {
19        public void select(@Param("id") Integer id, @Param("author") String author, RowBounds rb, Article article) {}
20    }
21}

测试结果如下：

参数索引与名称映射图如下：

到此，关于 MapperMethod 的初始化逻辑就分析完了，继续往下分析。

2.1.2.2 执行 execute 方法

前面已经分析了 MapperMethod 的初始化过程，现在 MapperMethod 创建好了。那么，接下来要做的事情是调用 MapperMethod 的 execute 方法，执行 SQL。代码如下：

1// -☆- MapperMethod
2public Object execute(SqlSession sqlSession, Object[] args) {
3    Object result;
4    
5    // 根据 SQL 类型执行相应的数据库操作
6    switch (command.getType()) {
7        case INSERT: {
8            // 对用户传入的参数进行转换，下同
9            Object param = method.convertArgsToSqlCommandParam(args);
10            // 执行插入操作，rowCountResult 方法用于处理返回值
11            result = rowCountResult(sqlSession.insert(command.getName(), param));
12            break;
13        }
14        case UPDATE: {
15            Object param = method.convertArgsToSqlCommandParam(args);
16            // 执行更新操作
17            result = rowCountResult(sqlSession.update(command.getName(), param));
18            break;
19        }
20        case DELETE: {
21            Object param = method.convertArgsToSqlCommandParam(args);
22            // 执行删除操作
23            result = rowCountResult(sqlSession.delete(command.getName(), param));
24            break;
25        }
26        case SELECT:
27            // 根据目标方法的返回类型进行相应的查询操作
28            if (method.returnsVoid() && method.hasResultHandler()) {
29                /*
30                 * 如果方法返回值为 void，但参数列表中包含 ResultHandler，表明使用者
31                 * 想通过 ResultHandler 的方式获取查询结果，而非通过返回值获取结果
32                 */
33                executeWithResultHandler(sqlSession, args);
34                result = null;
35            } else if (method.returnsMany()) {
36                // 执行查询操作，并返回多个结果 
37                result = executeForMany(sqlSession, args);
38            } else if (method.returnsMap()) {
39                // 执行查询操作，并将结果封装在 Map 中返回
40                result = executeForMap(sqlSession, args);
41            } else if (method.returnsCursor()) {
42                // 执行查询操作，并返回一个 Cursor 对象
43                result = executeForCursor(sqlSession, args);
44            } else {
45                Object param = method.convertArgsToSqlCommandParam(args);
46                // 执行查询操作，并返回一个结果
47                result = sqlSession.selectOne(command.getName(), param);
48            }
49            break;
50        case FLUSH:
51            // 执行刷新操作
52            result = sqlSession.flushStatements();
53            break;
54        default:
55            throw new BindingException("Unknown execution method for: " + command.getName());
56    }
57    
58    // 如果方法的返回值为基本类型，而返回值却为 null，此种情况下应抛出异常
59    if (result == null && method.getReturnType().isPrimitive() && !method.returnsVoid()) {
60        throw new BindingException("Mapper method '" + command.getName()
61            + " attempted to return null from a method with a primitive return type (" + method.getReturnType()
62            + ").");
63    }
64    return result;
65}

如上，execute 方法主要由一个 switch 语句组成，用于根据 SQL 类型执行相应的数据库操作。该方法的逻辑清晰，不需要太多的分析。不过在上面的方法中 convertArgsToSqlCommandParam 方法出现次数比较频繁，这里分析一下：

1// -☆- MapperMethod
2public Object convertArgsToSqlCommandParam(Object[] args) {
3    return paramNameResolver.getNamedParams(args);
4}
5
6public Object getNamedParams(Object[] args) {
7    final int paramCount = names.size();
8    if (args == null || paramCount == 0) {
9        return null;
10    } else if (!hasParamAnnotation && paramCount == 1) {
11        /*
12         * 如果方法参数列表无 @Param 注解，且仅有一个非特别参数，则返回该参数的值。
13         * 比如如下方法：
14         *     List findList(RowBounds rb, String name)
15         * names 如下：
16         *     names = {1 : "0"}
17         * 此种情况下，返回 args[names.firstKey()]，即 args[1] -> name
18         */
19        return args[names.firstKey()];
20    } else {
21        final Map<String, Object> param = new ParamMap<Object>();
22        int i = 0;
23        for (Map.Entry<Integer, String> entry : names.entrySet()) {
24            // 添加 <参数名, 参数值> 键值对到 param 中
25            param.put(entry.getValue(), args[entry.getKey()]);
26            // genericParamName = param + index。比如 param1, param2, ... paramN
27            final String genericParamName = GENERIC_NAME_PREFIX + String.valueOf(i + 1);
28            /*
29             * 检测 names 中是否包含 genericParamName，什么情况下会包含？答案如下：
30             *
31             *   使用者显式将参数名称配置为 param1，即 @Param("param1")
32             */
33            if (!names.containsValue(genericParamName)) {
34                // 添加 <param*, value> 到 param 中
35                param.put(genericParamName, args[entry.getKey()]);
36            }
37            i++;
38        }
39        return param;
40    }
41}

如上，convertArgsToSqlCommandParam 是一个空壳方法，该方法最终调用了 ParamNameResolver 的 getNamedParams 方法。getNamedParams 方法的主要逻辑是根据条件返回不同的结果，该方法的代码不是很难理解，我也进行了比较详细的注释，就不多说了。

分析完 convertArgsToSqlCommandParam 的逻辑，接下来说说 MyBatis 对哪些 SQL 指令提供了支持，如下：

• 查询语句：SELECT
• 更新语句：INSERT/UPDATE/DELETE
• 存储过程：CALL

在上面的列表中，我刻意对 SELECT/INSERT/UPDATE/DELETE 等指令进行了分类，分类依据指令的功能以及 MyBatis 执行这些指令的过程。这里把 SELECT 称为查询语句，INSERT/UPDATE/DELETE 等称为更新语句。接下来，先来分析查询语句的执行过程。

2.2 查询语句的执行过程分析

查询语句对应的方法比较多，有如下几种：

• executeWithResultHandler
• executeForMany
• executeForMap
• executeForCursor

这些方法在内部调用了 SqlSession 中的一些 select* 方法，比如 selectList、selectMap、selectCursor 等。这些方法的返回值类型是不同的，因此对于每种返回类型，需要有专门的处理方法。以 selectList 方法为例，该方法的返回值类型为 List。但如果我们的 Mapper 或 Dao 的接口方法返回值类型为数组，或者 Set，直接将 List 类型的结果返回给 Mapper/Dao 就不合适了。execute* 等方法只是对 select* 等方法做了一层简单的封装，因此接下来我们应该把目光放在这些 select* 方法上。下面我们来分析一下 selectOne 方法的源码，如下：

2.2.1 selectOne 方法分析

本节选择分析 selectOne 方法，而不是其他的方法，大家或许会觉得奇怪。前面提及了 selectList、selectMap、selectCursor 等方法，这里却分析一个未提及的方法。这样做并没什么特别之处，主要原因是 selectOne 在内部会调用 selectList 方法。这里分析 selectOne 方法是为了告知大家，selectOne 和 selectList 方法是有联系的，同时分析 selectOne 方法等同于分析 selectList 方法。如果你不信的话，那我们看源码吧，源码面前了无秘密。

1// -☆- DefaultSqlSession
2public <T> T selectOne(String statement, Object parameter) {
3    // 调用 selectList 获取结果
4    List<T> list = this.<T>selectList(statement, parameter);
5    if (list.size() == 1) {
6        // 返回结果
7        return list.get(0);
8    } else if (list.size() > 1) {
9        // 如果查询结果大于1则抛出异常，这个异常也是很常见的
10        throw new TooManyResultsException(
11            "Expected one result (or null) to be returned by selectOne(), but found: " + list.size());
12    } else {
13        return null;
14    }
15}

如上，selectOne 方法在内部调用 selectList 了方法，并取 selectList 返回值的第1个元素作为自己的返回值。如果 selectList 返回的列表元素大于1，则抛出异常。上面代码比较易懂，就不多说了。下面我们来看看 selectList 方法的实现。

1// -☆- DefaultSqlSession
2public <E> List<E> selectList(String statement, Object parameter) {
3    // 调用重载方法
4    return this.selectList(statement, parameter, RowBounds.DEFAULT);
5}
6
7private final Executor executor;
8
9public <E> List<E> selectList(String statement, Object parameter, RowBounds rowBounds) {
10    try {
11        // 获取 MappedStatement
12        MappedStatement ms = configuration.getMappedStatement(statement);
13        // 调用 Executor 实现类中的 query 方法
14        return executor.query(ms, wrapCollection(parameter), rowBounds, Executor.NO_RESULT_HANDLER);
15    } catch (Exception e) {
16        throw ExceptionFactory.wrapException("Error querying database.  Cause: " + e, e);
17    } finally {
18        ErrorContext.instance().reset();
19    }
20}

如上，这里要来说说 executor 变量，该变量类型为 Executor。Executor 是一个接口，它的实现类如下：

如上，Executor 有这么多的实现类，大家猜一下 executor 变量对应哪个实现类。要弄清楚这个问题，需要大家到源头去查证。这里提示一下，大家可以跟踪一下 DefaultSqlSessionFactory 的 openSession 方法，很快就能发现executor 变量创建的踪迹。限于篇幅原因，本文就不分析 openSession 方法的源码了。好了，下面我来直接告诉大家 executor 变量对应哪个实现类吧。默认情况下，executor 的类型为 CachingExecutor，该类是一个装饰器类，用于给目标 Executor 增加二级缓存功能。那目标 Executor 是谁呢？默认情况下是 SimpleExecutor。

现在大家搞清楚 executor 变量的身份了，接下来继续分析 selectOne 方法的调用栈。先来看看 CachingExecutor 的 query 方法是怎样实现的。如下：

1// -☆- CachingExecutor
2public <E> List<E> query(MappedStatement ms, Object parameterObject, RowBounds rowBounds, ResultHandler resultHandler) throws SQLException {
3    // 获取 BoundSql
4    BoundSql boundSql = ms.getBoundSql(parameterObject);
5    // 创建 CacheKey
6    CacheKey key = createCacheKey(ms, parameterObject, rowBounds, boundSql);
7    // 调用重载方法
8    return query(ms, parameterObject, rowBounds, resultHandler, key, boundSql);
9}

上面的代码用于获取 BoundSql 对象，创建 CacheKey 对象，然后再将这两个对象传给重载方法。关于 BoundSql 的获取过程较为复杂，我将在下一节进行分析。CacheKey 以及接下来即将出现的一二级缓存将会独立成文进行分析。

上面的方法和 SimpleExecutor 父类 BaseExecutor 中的实现没什么区别，有区别的地方在于这个方法所调用的重载方法。我们继续往下看。

1// -☆- CachingExecutor
2public <E> List<E> query(MappedStatement ms, Object parameterObject, RowBounds rowBounds, ResultHandler resultHandler, CacheKey key, BoundSql boundSql) throws SQLException {
3    // 从 MappedStatement 中获取缓存
4    Cache cache = ms.getCache();
5    // 若映射文件中未配置缓存或参照缓存，此时 cache = null
6    if (cache != null) {
7        flushCacheIfRequired(ms);
8        if (ms.isUseCache() && resultHandler == null) {
9            ensureNoOutParams(ms, boundSql);
10            List<E> list = (List<E>) tcm.getObject(cache, key);
11            if (list == null) {
12                // 若缓存未命中，则调用被装饰类的 query 方法
13                list = delegate.<E>query(ms, parameterObject, rowBounds, resultHandler, key, boundSql);
14                tcm.putObject(cache, key, list); // issue #578 and #116
15            }
16            return list;
17        }
18    }
19    // 调用被装饰类的 query 方法
20    return delegate.<E>query(ms, parameterObject, rowBounds, resultHandler, key, boundSql);
21}

上面的代码涉及到了二级缓存，若二级缓存为空，或未命中，则调用被装饰类的 query 方法。下面来看一下 BaseExecutor 的中签名相同的 query 方法是如何实现的。

1// -☆- BaseExecutor
2public <E> List<E> query(MappedStatement ms, Object parameter, RowBounds rowBounds, ResultHandler resultHandler, CacheKey key, BoundSql boundSql) throws SQLException {
3    if (closed) {
4        throw new ExecutorException("Executor was closed.");
5    }
6    if (queryStack == 0 && ms.isFlushCacheRequired()) {
7        clearLocalCache();
8    }
9    List<E> list;
10    try {
11        queryStack++;
12        // 从一级缓存中获取缓存项
13        list = resultHandler == null ? (List<E>) localCache.getObject(key) : null;
14        if (list != null) {
15            // 存储过程相关处理逻辑，本文不分析存储过程，故该方法不分析了
16            handleLocallyCachedOutputParameters(ms, key, parameter, boundSql);
17        } else {
18            // 一级缓存未命中，则从数据库中查询
19            list = queryFromDatabase(ms, parameter, rowBounds, resultHandler, key, boundSql);
20        }
21    } finally {
22        queryStack--;
23    }
24    if (queryStack == 0) {
25        // 从一级缓存中延迟加载嵌套查询结果
26        for (DeferredLoad deferredLoad : deferredLoads) {
27            deferredLoad.load();
28        }
29        deferredLoads.clear();
30        if (configuration.getLocalCacheScope() == LocalCacheScope.STATEMENT) {
31            clearLocalCache();
32        }
33    }
34    return list;
35}

如上，上面的方法主要用于从一级缓存中查找查询结果。若缓存未命中，再向数据库进行查询。在上面的代码中，出现了一个新的类 DeferredLoad，这个类用于延迟加载。该类的实现并不复杂，但是具体用途让我有点疑惑。这个我目前也未完全搞清楚，就不强行分析了。接下来，我们来看一下 queryFromDatabase 方法的实现。

1// -☆- BaseExecutor
2private <E> List<E> queryFromDatabase(MappedStatement ms, Object parameter, RowBounds rowBounds,
3    ResultHandler resultHandler, CacheKey key, BoundSql boundSql) throws SQLException {
4    List<E> list;
5    // 向缓存中存储一个占位符
6    localCache.putObject(key, EXECUTION_PLACEHOLDER);
7    try {
8        // 调用 doQuery 进行查询
9        list = doQuery(ms, parameter, rowBounds, resultHandler, boundSql);
10    } finally {
11        // 移除占位符
12        localCache.removeObject(key);
13    }
14    // 缓存查询结果
15    localCache.putObject(key, list);
16    if (ms.getStatementType() == StatementType.CALLABLE) {
17        localOutputParameterCache.putObject(key, parameter);
18    }
19    return list;
20}

上面的代码仍然不是 selectOne 方法调用栈的终点，抛开缓存操作，queryFromDatabase 最终还会调用 doQuery 进行查询。下面我们继续进行跟踪。

1// -☆- SimpleExecutor
2public <E> List<E> doQuery(MappedStatement ms, Object parameter, RowBounds rowBounds, ResultHandler resultHandler, BoundSql boundSql) throws SQLException {
3    Statement stmt = null;
4    try {
5        Configuration configuration = ms.getConfiguration();
6        // 创建 StatementHandler
7        StatementHandler handler = configuration.newStatementHandler(wrapper, ms, parameter, rowBounds, resultHandler, boundSql);
8        // 创建 Statement
9        stmt = prepareStatement(handler, ms.getStatementLog());
10        // 执行查询操作
11        return handler.<E>query(stmt, resultHandler);
12    } finally {
13        // 关闭 Statement
14        closeStatement(stmt);
15    }
16}

上面的方法中仍然有不少的逻辑，完全看不到即将要到达终点的趋势，不过这离终点又近了一步。接下来，我们先跳过 StatementHandler 和 Statement 创建过程，这两个对象的创建过程会在后面进行说明。这里，我们以 PreparedStatementHandler 为例，看看它的 query 方法是怎样实现的。如下：

1// -☆- PreparedStatementHandler
2public <E> List<E> query(Statement statement, ResultHandler resultHandler) throws SQLException {
3    PreparedStatement ps = (PreparedStatement) statement;
4    // 执行 SQL
5    ps.execute();
6    // 处理执行结果
7    return resultSetHandler.<E>handleResultSets(ps);
8}

到这里似乎看到了希望，整个调用过程总算要结束了。不过先别高兴的太早，SQL 执行结果的处理过程也很复杂，稍后将会专门拿出一节内容进行分析。

以上就是 selectOne 方法的执行过程，尽管我已经简化了代码分析，但是整个过程看起来还是很复杂的。查询过程涉及到了很多方法调用，不把这些调用方法搞清楚，很难对 MyBatis 的查询过程有深入的理解。所以在接下来的章节中，我将会对一些重要的调用进行分析。如果大家不满足于泛泛而谈，那么接下来咱们一起进行更为深入的探索吧。

2.2.2 获取 BoundSql

我们在执行 SQL 时，一个重要的任务是将 SQL 语句解析出来。我们都知道 SQL 是配置在映射文件中的，但由于映射文件中的 SQL 可能会包含占位符 #{}，以及动态 SQL 标签，比如 <if>、<where> 等。因此，我们并不能直接使用映射文件中配置的 SQL。MyBatis 会将映射文件中的 SQL 解析成一组 SQL 片段。如果某个片段中也包含动态 SQL 相关的标签，那么，MyBatis 会对该片段再次进行分片。最终，一个 SQL 配置将会被解析成一个 SQL 片段树。形如下面的图片：

我们需要对片段树进行解析，以便从每个片段对象中获取相应的内容。然后将这些内容组合起来即可得到一个完成的 SQL 语句，这个完整的 SQL 以及其他的一些信息最终会存储在 BoundSql 对象中。下面我们来看一下 BoundSql 类的成员变量信息，如下：

1private final String sql;
2private final List<ParameterMapping> parameterMappings;
3private final Object parameterObject;
4private final Map<String, Object> additionalParameters;
5private final MetaObject metaParameters;

下面用一个表格列举各个成员变量的含义。

变量名

类型

用途

sql

String

一个完整的 SQL 语句，可能会包含问号 ? 占位符

parameterMappings

List

参数映射列表，SQL 中的每个 #{xxx} 占位符都会被解析成相应的 ParameterMapping 对象

parameterObject

Object

运行时参数，即用户传入的参数，比如 Article 对象，或是其他的参数

additionalParameters

Map

附加参数集合，用于存储一些额外的信息，比如 datebaseId 等

metaParameters

MetaObject

additionalParameters 的元信息对象

以上对 BoundSql 的成员变量做了简要的说明，部分参数的用途大家现在可能不是很明白。不过不用着急，这些变量在接下来的源码分析过程中会陆续的出现。到时候对着源码多思考，或是写点测试代码调试一下，即可弄懂。

好了，现在准备工作已经做好。接下来，开始分析 BoundSql 的构建过程。我们源码之旅的第一站是 MappedStatement 的 getBoundSql 方法，代码如下：

1// -☆- MappedStatement
2public BoundSql getBoundSql(Object parameterObject) {
3
4    // 调用 sqlSource 的 getBoundSql 获取 BoundSql
5    BoundSql boundSql = sqlSource.getBoundSql(parameterObject);
6    List<ParameterMapping> parameterMappings = boundSql.getParameterMappings();
7    if (parameterMappings == null || parameterMappings.isEmpty()) {
8        /*
9         * 创建新的 BoundSql，这里的 parameterMap 是 ParameterMap 类型。
10         * 由<ParameterMap> 节点进行配置，该节点已经废弃，不推荐使用。默认情况下，
11         * parameterMap.getParameterMappings() 返回空集合
12         */ 
13        boundSql = new BoundSql(configuration, boundSql.getSql(), parameterMap.getParameterMappings(), parameterObject);
14    }
15
16    // 省略不重要的逻辑
17
18    return boundSql;
19}

如上，MappedStatement 的 getBoundSql 在内部调用了 SqlSource 实现类的 getBoundSql 方法。处理此处的调用，余下的逻辑都不是重要逻辑，就不啰嗦了。接下来，我们把目光转移到 SqlSource 实现类的 getBoundSql 方法上。SqlSource 是一个接口，它有如下几个实现类：

• DynamicSqlSource
• RawSqlSource
• StaticSqlSource
• ProviderSqlSource
• VelocitySqlSource

在如上几个实现类中，我们应该选择分析哪个实现类的逻辑呢？如果大家分析过 MyBatis 映射文件的解析过程，或者阅读过我上一篇的关于MyBatis 映射文件分析的文章，那么这个问题不难回答。好了，不卖关子了，我来回答一下这个问题吧。首先我们把最后两个排除掉，不常用。剩下的三个实现类中，仅前两个实现类会在映射文件解析的过程中被使用。当 SQL 配置中包含 ${}（不是 #{}）占位符，或者包含 <if>、<where> 等标签时，会被认为是动态 SQL，此时使用 DynamicSqlSource 存储 SQL 片段。否则，使用 RawSqlSource 存储 SQL 配置信息。相比之下 DynamicSqlSource 存储的 SQL 片段类型较多，解析起来也更为复杂一些。因此下面我将分析 DynamicSqlSource 的 getBoundSql 方法。弄懂这个，RawSqlSource 也不在话下。好了，下面开始分析。

1// -☆- DynamicSqlSource
2public BoundSql getBoundSql(Object parameterObject) {
3    // 创建 DynamicContext
4    DynamicContext context = new DynamicContext(configuration, parameterObject);
5
6    // 解析 SQL 片段，并将解析结果存储到 DynamicContext 中
7    rootSqlNode.apply(context);
8    
9    SqlSourceBuilder sqlSourceParser = new SqlSourceBuilder(configuration);
10    Class<?> parameterType = parameterObject == null ? Object.class : parameterObject.getClass();
11    /*
12     * 构建 StaticSqlSource，在此过程中将 sql 语句中的占位符 #{} 替换为问号 ?，
13     * 并为每个占位符构建相应的 ParameterMapping
14     */
15    SqlSource sqlSource = sqlSourceParser.parse(context.getSql(), parameterType, context.getBindings());
16    
17    // 调用 StaticSqlSource 的 getBoundSql 获取 BoundSql
18    BoundSql boundSql = sqlSource.getBoundSql(parameterObject);
19
20    // 将 DynamicContext 的 ContextMap 中的内容拷贝到 BoundSql 中
21    for (Map.Entry<String, Object> entry : context.getBindings().entrySet()) {
22        boundSql.setAdditionalParameter(entry.getKey(), entry.getValue());
23    }
24    return boundSql;
25}

如上，DynamicSqlSource 的 getBoundSql 方法的代码看起来不多，但是逻辑却并不简单。该方法由数个步骤组成，这里总结一下：

1. 创建 DynamicContext
2. 解析 SQL 片段，并将解析结果存储到 DynamicContext 中
3. 解析 SQL 语句，并构建 StaticSqlSource
4. 调用 StaticSqlSource 的 getBoundSql 获取 BoundSql
5. 将 DynamicContext 的 ContextMap 中的内容拷贝到 BoundSql 中

如上5个步骤中，第5步为常规操作，就不多说了，其他步骤将会在接下来章节中一一进行分析。按照顺序，我们先来分析 DynamicContext 的实现。

2.2.2.1 DynamicContext

DynamicContext 是 SQL 语句构建的上下文，每个 SQL 片段解析完成后，都会将解析结果存入 DynamicContext 中。待所有的 SQL 片段解析完毕后，一条完整的 SQL 语句就会出现在 DynamicContext 对象中。下面我们来看一下 DynamicContext 类的定义。

1public class DynamicContext {
2
3    public static final String PARAMETER_OBJECT_KEY = "_parameter";
4    public static final String DATABASE_ID_KEY = "_databaseId";
5
6    private final ContextMap bindings;
7    private final StringBuilder sqlBuilder = new StringBuilder();
8
9    public DynamicContext(Configuration configuration, Object parameterObject) {
10        // 创建 ContextMap
11        if (parameterObject != null && !(parameterObject instanceof Map)) {
12            MetaObject metaObject = configuration.newMetaObject(parameterObject);
13            bindings = new ContextMap(metaObject);
14        } else {
15            bindings = new ContextMap(null);
16        }
17
18        // 存放运行时参数 parameterObject 以及 databaseId
19        bindings.put(PARAMETER_OBJECT_KEY, parameterObject);
20        bindings.put(DATABASE_ID_KEY, configuration.getDatabaseId());
21    }
22
23    // 省略部分代码
24}

如上，上面只贴了 DynamicContext 类的部分代码。其中 sqlBuilder 变量用于存放 SQL 片段的解析结果，bindings 则用于存储一些额外的信息，比如运行时参数 和 databaseId 等。bindings 类型为 ContextMap，ContextMap 定义在 DynamicContext 中，是一个静态内部类。该类继承自 HashMap，并覆写了 get 方法。它的代码如下：

1static class ContextMap extends HashMap<String, Object> {
2
3    private MetaObject parameterMetaObject;
4
5    public ContextMap(MetaObject parameterMetaObject) {
6        this.parameterMetaObject = parameterMetaObject;
7    }
8
9    @Override
10    public Object get(Object key) {
11        String strKey = (String) key;
12        // 检查是否包含 strKey，若包含则直接返回
13        if (super.containsKey(strKey)) {
14            return super.get(strKey);
15        }
16
17        if (parameterMetaObject != null) {
18            // 从运行时参数中查找结果
19            return parameterMetaObject.getValue(strKey);
20        }
21
22        return null;
23    }
24}

DynamicContext 对外提供了两个接口，用于操作 sqlBuilder。分别如下：

1public void appendSql(String sql) {
2    sqlBuilder.append(sql);
3    sqlBuilder.append(" ");
4}
5
6public String getSql() {
7    return sqlBuilder.toString().trim();
8}

以上就是对 DynamicContext 的简单介绍，DynamicContext 的源码不难理解，这里就不多说了。继续往下分析。

2.2.2.2 解析 SQL 片段

对于一个包含了 ${} 占位符，或 <if>、<where> 等标签的 SQL，在解析的过程中，会被分解成多个片段。每个片段都有对应的类型，每种类型的片段都有不同的解析逻辑。在源码中，片段这个概念等价于 sql 节点，即 SqlNode。SqlNode 是一个接口，它有众多的实现类。其继承体系如下：

上图只画出了部分的实现类，还有一小部分没画出来，不过这并不影响接下来的分析。在众多实现类中，StaticTextSqlNode 用于存储静态文本，TextSqlNode 用于存储带有 ${} 占位符的文本，IfSqlNode 则用于存储 <if> 节点的内容。MixedSqlNode 内部维护了一个 SqlNode 集合，用于存储各种各样的 SqlNode。接下来，我将会对 MixedSqlNode 、StaticTextSqlNode、TextSqlNode、IfSqlNode、WhereSqlNode 以及 TrimSqlNode 等进行分析，其他的实现类请大家自行分析。Talk is cheap，show you the code.

1public class MixedSqlNode implements SqlNode {
2    private final List<SqlNode> contents;
3
4    public MixedSqlNode(List<SqlNode> contents) {
5        this.contents = contents;
6    }
7
8    @Override
9    public boolean apply(DynamicContext context) {
10        // 遍历 SqlNode 集合
11        for (SqlNode sqlNode : contents) {
12            // 调用 salNode 对象本身的 apply 方法解析 sql
13            sqlNode.apply(context);
14        }
15        return true;
16    }
17}

MixedSqlNode 可以看做是 SqlNode 实现类对象的容器，凡是实现了 SqlNode 接口的类都可以存储到 MixedSqlNode 中，包括它自己。MixedSqlNode 解析方法 apply 逻辑比较简单，即遍历 SqlNode 集合，并调用其他 SalNode 实现类对象的 apply 方法解析 sql。那下面我们来看看其他 SalNode 实现类的 apply 方法是怎样实现的。

1public class StaticTextSqlNode implements SqlNode {
2
3    private final String text;
4
5    public StaticTextSqlNode(String text) {
6        this.text = text;
7    }
8
9    @Override
10    public boolean apply(DynamicContext context) {
11        context.appendSql(text);
12        return true;
13    }
14}

StaticTextSqlNode 用于存储静态文本，所以它不需要什么解析逻辑，直接将其存储的 SQL 片段添加到 DynamicContext 中即可。StaticTextSqlNode 的实现比较简单，看起来很轻松。下面分析一下 TextSqlNode。

1public class TextSqlNode implements SqlNode {
2
3    private final String text;
4    private final Pattern injectionFilter;
5
6    @Override
7    public boolean apply(DynamicContext context) {
8        // 创建 ${} 占位符解析器
9        GenericTokenParser parser = createParser(new BindingTokenParser(context, injectionFilter));
10        // 解析 ${} 占位符，并将解析结果添加到 DynamicContext 中
11        context.appendSql(parser.parse(text));
12        return true;
13    }
14
15    private GenericTokenParser createParser(TokenHandler handler) {
16        // 创建占位符解析器，GenericTokenParser 是一个通用解析器，并非只能解析 ${}
17        return new GenericTokenParser("${", "}", handler);
18    }
19
20    private static class BindingTokenParser implements TokenHandler {
21
22        private DynamicContext context;
23        private Pattern injectionFilter;
24
25        public BindingTokenParser(DynamicContext context, Pattern injectionFilter) {
26            this.context = context;
27            this.injectionFilter = injectionFilter;
28        }
29
30        @Override
31        public String handleToken(String content) {
32            Object parameter = context.getBindings().get("_parameter");
33            if (parameter == null) {
34                context.getBindings().put("value", null);
35            } else if (SimpleTypeRegistry.isSimpleType(parameter.getClass())) {
36                context.getBindings().put("value", parameter);
37            }
38            // 通过 ONGL 从用户传入的参数中获取结果
39            Object value = OgnlCache.getValue(content, context.getBindings());
40            String srtValue = (value == null ? "" : String.valueOf(value));
41            // 通过正则表达式检测 srtValue 有效性
42            checkInjection(srtValue);
43            return srtValue;
44        }
45    }
46}

如上，GenericTokenParser 是一个通用的标记解析器，用于解析形如 ${xxx}，#{xxx} 等标记。GenericTokenParser 负责将标记中的内容抽取出来，并将标记内容交给相应的 TokenHandler 去处理。BindingTokenParser 负责解析标记内容，并将解析结果返回给 GenericTokenParser，用于替换 ${xxx} 标记。举个例子说明一下吧，如下。

我们有这样一个 SQL 语句，用于从 article 表中查询某个作者所写的文章。如下：

SELECT * FROM article WHERE author = '${author}'

假设我们我们传入的 author 值为 tianxiaobo，那么该 SQL 最终会被解析成如下的结果：

SELECT * FROM article WHERE author = 'tianxiaobo'

一般情况下，使用 ${author} 接受参数都没什么问题。但是怕就怕在有人不怀好意，构建了一些恶意的参数。当用这些恶意的参数替换 ${author} 时就会出现灾难性问题 -- SQL 注入。比如我们构建这样一个参数 author = tianxiaobo'; DELETE FROM article;# ，然后我们把这个参数传给 TextSqlNode 进行解析。得到的结果如下：

SELECT * FROM article WHERE author = 'tianxiaobo'; DELETE FROM article;#'

看到没，由于传入的参数没有经过转义，最终导致了一条 SQL 被恶意参数拼接成了两条 SQL。更要命的是，第二天 SQL 会把 article 表的数据清空，这个后果就很严重了（从删库到跑路）。这就是为什么我们不应该在 SQL 语句中是用 ${} 占位符，风险太大。

分析完 TextSqlNode 的逻辑，接下来，分析 IfSqlNode 的实现。

1public class IfSqlNode implements SqlNode {
2
3    private final ExpressionEvaluator evaluator;
4    private final String test;
5    private final SqlNode contents;
6
7    public IfSqlNode(SqlNode contents, String test) {
8        this.test = test;
9        this.contents = contents;
10        this.evaluator = new ExpressionEvaluator();
11    }
12
13    @Override
14    public boolean apply(DynamicContext context) {
15        // 通过 ONGL 评估 test 表达式的结果
16        if (evaluator.evaluateBoolean(test, context.getBindings())) {
17            // 若 test 表达式中的条件成立，则调用其他节点的 apply 方法进行解析
18            contents.apply(context);
19            return true;
20        }
21        return false;
22    }
23}

IfSqlNode 对应的是 <if test='xxx'> 节点，<if> 节点是日常开发中使用频次比较高的一个节点。它的具体用法我想大家都很熟悉了，这里就不多啰嗦。IfSqlNode 的 apply 方法逻辑并不复杂，首先是通过 ONGL 检测 test 表达式是否为 true，如果为 true，则调用其他节点的 apply 方法继续进行解析。需要注意的是 <if> 节点中也可嵌套其他的动态节点，并非只有纯文本。因此 contents 变量遍历指向的是 MixedSqlNode，而非 StaticTextSqlNode。

关于 IfSqlNode 就说到这，接下来分析 WhereSqlNode 的实现。

1public class WhereSqlNode extends TrimSqlNode {
2
3    /** 前缀列表 */
4    private static List<String> prefixList = Arrays.asList("AND ", "OR ", "AND\n", "OR\n", "AND\r", "OR\r", "AND\t", "OR\t");
5
6    public WhereSqlNode(Configuration configuration, SqlNode contents) {
7        // 调用父类的构造方法
8        super(configuration, contents, "WHERE", prefixList, null, null);
9    }
10}

在 MyBatis 中，WhereSqlNode 和 SetSqlNode 都是基于 TrimSqlNode 实现的，所以上面的代码看起来很简单。WhereSqlNode 对应于 <where> 节点，关于该节点的用法以及它的应用场景，大家请自行查阅资料。我在分析源码的过程中，默认大家已经知道了该节点的用途和应用场景。

接下来，我们把目光聚焦在 TrimSqlNode 的实现上。

1public class TrimSqlNode implements SqlNode {
2
3    private final SqlNode contents;
4    private final String prefix;
5    private final String suffix;
6    private final List<String> prefixesToOverride;
7    private final List<String> suffixesToOverride;
8    private final Configuration configuration;
9
10   // 省略构造方法
11
12    @Override
13    public boolean apply(DynamicContext context) {
14        // 创建具有过滤功能的 DynamicContext
15        FilteredDynamicContext filteredDynamicContext = new FilteredDynamicContext(context);
16        // 解析节点内容
17        boolean result = contents.apply(filteredDynamicContext);
18        // 过滤掉前缀和后缀
19        filteredDynamicContext.applyAll();
20        return result;
21    }
22}

如上，apply 方法首选调用了其他 SqlNode 的 apply 方法解析节点内容，这步操作完成后，FilteredDynamicContext 中会得到一条 SQL 片段字符串。接下里需要做的事情是过滤字符串前缀后和后缀，并添加相应的前缀和后缀。这个事情由 FilteredDynamicContext 负责，FilteredDynamicContext 是 TrimSqlNode 的私有内部类。我们去看一下它的代码。

1private class FilteredDynamicContext extends DynamicContext {
2
3    private DynamicContext delegate;
4    /** 构造方法会将下面两个布尔值置为 false */
5    private boolean prefixApplied;
6    private boolean suffixApplied;
7    private StringBuilder sqlBuffer;
8    
9    // 省略构造方法
10
11    public void applyAll() {
12        sqlBuffer = new StringBuilder(sqlBuffer.toString().trim());
13        String trimmedUppercaseSql = sqlBuffer.toString().toUpperCase(Locale.ENGLISH);
14        if (trimmedUppercaseSql.length() > 0) {
15            // 引用前缀和后缀，也就是对 sql 进行过滤操作，移除掉前缀或后缀
16            applyPrefix(sqlBuffer, trimmedUppercaseSql);
17            applySuffix(sqlBuffer, trimmedUppercaseSql);
18        }
19        // 将当前对象的 sqlBuffer 内容添加到代理类中
20        delegate.appendSql(sqlBuffer.toString());
21    }
22
23    // 省略部分方法
24
25    private void applyPrefix(StringBuilder sql, String trimmedUppercaseSql) {
26        if (!prefixApplied) {
27            // 设置 prefixApplied 为 true，以下逻辑仅会被执行一次
28            prefixApplied = true;
29            if (prefixesToOverride != null) {
30                for (String toRemove : prefixesToOverride) {
31                    // 检测当前 sql 字符串是否包含 toRemove 前缀，比如 'AND ', 'AND\t'
32                    if (trimmedUppercaseSql.startsWith(toRemove)) {
33                        // 移除前缀
34                        sql.delete(0, toRemove.trim().length());
35                        break;
36                    }
37                }
38            }
39
40            // 插入前缀，比如 WHERE
41            if (prefix != null) {
42                sql.insert(0, " ");
43                sql.insert(0, prefix);
44            }
45        }
46    }
47
48    // 该方法逻辑与 applyPrefix 大同小异，大家自行分析
49    private void applySuffix(StringBuilder sql, String trimmedUppercaseSql) {...}
50}

在上面的代码中，我们重点关注 applyAll 和 applyPrefix 方法，其他的方法大家自行分析。applyAll 方法的逻辑比较简单，首先从 sqlBuffer 中获取 SQL 字符串。然后调用 applyPrefix 和 applySuffix 进行过滤操作。最后将过滤后的 SQL 字符串添加到被装饰的类中。applyPrefix 方法会首先检测 SQL 字符串是不是以 "AND "，"OR "，或 "AND\n"， "OR\n" 等前缀开头，若是则将前缀从 sqlBuffer 中移除。然后将前缀插入到 sqlBuffer 的首部，整个逻辑就结束了。下面写点代码简单验证一下，如下：

1public class SqlNodeTest {
2
3    @Test
4    public void testWhereSqlNode() throws IOException {
5        String sqlFragment = "AND id = #{id}";
6        MixedSqlNode msn = new MixedSqlNode(Arrays.asList(new StaticTextSqlNode(sqlFragment)));
7        WhereSqlNode wsn = new WhereSqlNode(new Configuration(), msn);
8        DynamicContext dc = new DynamicContext(new Configuration(), new ParamMap<>());
9        wsn.apply(dc);
10        System.out.println("解析前：" + sqlFragment);
11        System.out.println("解析后：" + dc.getSql());
12    }
13}

测试结果如下：

2.2.2.3 解析 #{} 占位符

经过前面的解析，我们已经能从 DynamicContext 获取到完整的 SQL 语句了。但这并不意味着解析过程就结束了，因为当前的 SQL 语句中还有一种占位符没有处理，即 #{}。与 ${} 占位符的处理方式不同，MyBatis 并不会直接将 #{} 占位符替换为相应的参数值。#{} 占位符的解析逻辑这里先不多说，等相应的源码分析完了，答案就明了了。

#{} 占位符的解析逻辑是包含在 SqlSourceBuilder 的 parse 方法中，该方法最终会将解析后的 SQL 以及其他的一些数据封装到 StaticSqlSource 中。下面，一起来看一下 SqlSourceBuilder 的 parse 方法。

1// -☆- SqlSourceBuilder
2public SqlSource parse(String originalSql, Class<?> parameterType, Map<String, Object> additionalParameters) {
3    // 创建 #{} 占位符处理器
4    ParameterMappingTokenHandler handler = new ParameterMappingTokenHandler(configuration, parameterType, additionalParameters);
5    // 创建 #{} 占位符解析器
6    GenericTokenParser parser = new GenericTokenParser("#{", "}", handler);
7    // 解析 #{} 占位符，并返回解析结果
8    String sql = parser.parse(originalSql);
9    // 封装解析结果到 StaticSqlSource 中，并返回
10    return new StaticSqlSource(configuration, sql, handler.getParameterMappings());
11}

如上，GenericTokenParser 的用途上一节已经介绍过了，就不多说了。接下来，我们重点关注 #{} 占位符处理器 ParameterMappingTokenHandler 的逻辑。

1public String handleToken(String content) {
2    // 获取 content 的对应的 ParameterMapping
3    parameterMappings.add(buildParameterMapping(content));
4    // 返回 ?
5    return "?";
6}

ParameterMappingTokenHandler 的 handleToken 方法看起来比较简单，但实际上并非如此。GenericTokenParser 负责将 #{} 占位符中的内容抽取出来，并将抽取出的内容传给 handleToken 方法。handleToken 方法负责将传入的参数解析成对应的 ParameterMapping 对象，这步操作由 buildParameterMapping 方法完成。下面我们看一下 buildParameterMapping 的源码。

1private ParameterMapping buildParameterMapping(String content) {
2    /*
3     * 将 #{xxx} 占位符中的内容解析成 Map。大家可能很好奇一个普通的字符串是怎么解析成 Map 的，
4     * 举例说明一下。如下：
5     * 
6     *    #{age,javaType=int,jdbcType=NUMERIC,typeHandler=MyTypeHandler}
7     *    
8     * 上面占位符中的内容最终会被解析成如下的结果：
9     * 
10     *  {
11     *      "property": "age",
12     *      "typeHandler": "MyTypeHandler", 
13     *      "jdbcType": "NUMERIC", 
14     *      "javaType": "int"
15     *  }
16     * 
17     * parseParameterMapping 内部依赖 ParameterExpression 对字符串进行解析，ParameterExpression 的
18     * 逻辑不是很复杂，这里就不分析了。大家若有兴趣，可自行分析
19     */
20    Map<String, String> propertiesMap = parseParameterMapping(content);
21    String property = propertiesMap.get("property");
22    Class<?> propertyType;
23    // metaParameters 为 DynamicContext 成员变量 bindings 的元信息对象
24    if (metaParameters.hasGetter(property)) {
25        propertyType = metaParameters.getGetterType(property);
26    
27    /*
28     * parameterType 是运行时参数的类型。如果用户传入的是单个参数，比如 Article 对象，此时 
29     * parameterType 为 Article.class。如果用户传入的多个参数，比如 [id = 1, author = "coolblog"]，
30     * MyBatis 会使用 ParamMap 封装这些参数，此时 parameterType 为 ParamMap.class。如果 
31     * parameterType 有相应的 TypeHandler，这里则把 parameterType 设为 propertyType
32     */
33    } else if (typeHandlerRegistry.hasTypeHandler(parameterType)) {
34        propertyType = parameterType;
35    } else if (JdbcType.CURSOR.name().equals(propertiesMap.get("jdbcType"))) {
36        propertyType = java.sql.ResultSet.class;
37    } else if (property == null || Map.class.isAssignableFrom(parameterType)) {
38        // 如果 property 为空，或 parameterType 是 Map 类型，则将 propertyType 设为 Object.class
39        propertyType = Object.class;
40    } else {
41        /*
42         * 代码逻辑走到此分支中，表明 parameterType 是一个自定义的类，
43         * 比如 Article，此时为该类创建一个元信息对象
44         */
45        MetaClass metaClass = MetaClass.forClass(parameterType, configuration.getReflectorFactory());
46        // 检测参数对象有没有与 property 想对应的 getter 方法
47        if (metaClass.hasGetter(property)) {
48            // 获取成员变量的类型
49            propertyType = metaClass.getGetterType(property);
50        } else {
51            propertyType = Object.class;
52        }
53    }
54    
55    // -------------------------- 分割线 ---------------------------
56    
57    ParameterMapping.Builder builder = new ParameterMapping.Builder(configuration, property, propertyType);
58    
59    // 将 propertyType 赋值给 javaType
60    Class<?> javaType = propertyType;
61    String typeHandlerAlias = null;
62    
63    // 遍历 propertiesMap
64    for (Map.Entry<String, String> entry : propertiesMap.entrySet()) {
65        String name = entry.getKey();
66        String value = entry.getValue();
67        if ("javaType".equals(name)) {
68            // 如果用户明确配置了 javaType，则以用户的配置为准
69            javaType = resolveClass(value);
70            builder.javaType(javaType);
71        } else if ("jdbcType".equals(name)) {
72            // 解析 jdbcType
73            builder.jdbcType(resolveJdbcType(value));
74        } else if ("mode".equals(name)) {...} 
75        else if ("numericScale".equals(name)) {...} 
76        else if ("resultMap".equals(name)) {...} 
77        else if ("typeHandler".equals(name)) {
78            typeHandlerAlias = value;    
79        } 
80        else if ("jdbcTypeName".equals(name)) {...} 
81        else if ("property".equals(name)) {...} 
82        else if ("expression".equals(name)) {
83            throw new BuilderException("Expression based parameters are not supported yet");
84        } else {
85            throw new BuilderException("An invalid property '" + name + "' was found in mapping #{" + content
86                + "}.  Valid properties are " + parameterProperties);
87        }
88    }
89    if (typeHandlerAlias != null) {
90        // 解析 TypeHandler
91        builder.typeHandler(resolveTypeHandler(javaType, typeHandlerAlias));
92    }
93    
94    // 构建 ParameterMapping 对象
95    return builder.build();
96}