1.简介 在上一篇文章中，我详细分析了 MyBatis 配置文件的解析过程。由于上一篇文章的篇幅比较大，加之映射文件解析过程也比较复杂的原因。所以我将映射文件解析过程的分析内容从上一篇文章中抽取出来，独立成文，于是就有了本篇文章。在本篇文章中，我将分析映射文件中出现的一些及节点，比如 ，，, 等。除了分析常规的 XML 解析过程外，我还会向大家介绍 Mapper 接口的绑定过程等。综上所述，本篇文章内容会比较丰富，如果大家对此感兴趣，不妨花点时间读一读，会有新的收获。当然，本篇文章通篇是关于源码分析的，所以阅读本文需要大家对 MyBatis 有一定的了解。如果大家对 MyBatis 还不是很了解，建议阅读一下 MyBatis 的官方文档。 其他的就不多说了，下面开始我们的 MyBatis 源码之旅。 2.映射文件解析过程分析 我在前面说过，映射文件的解析过程是 MyBatis 配置文件解析过程的一部分。MyBatis 的配置文件由 XMLConfigBuilder 的 parseConfiguration 进行解析，该方法依次解析了 、、 等节点。至于 节点，parseConfiguration 则是在方法的结尾对其进行了解析。该部分的解析逻辑封装在 mapperElement 方法中，下面来看一下。 // -☆- XMLConfigBuilder private void mapperElement(XNode parent) throws Exception { if (parent != null) { for (XNode child : parent.getChildren()) { if ("package".equals(child.getName())) { // 获取 节点中的 name 属性 String mapperPackage = child.getStringAttribute("name"); // 从指定包中查找 mapper 接口，并根据 mapper 接口解析映射配置 configuration.addMappers(mapperPackage); } else { // 获取 resource/url/class 等属性 String resource = child.getStringAttribute("resource"); String url = child.getStringAttribute("url"); String mapperClass = child.getStringAttribute("class"); // resource 不为空，且其他两者为空，则从指定路径中加载配置 if (resource != null && url == null && mapperClass == null) { ErrorContext.instance().resource(resource); InputStream inputStream = Resources.getResourceAsStream(resource); XMLMapperBuilder mapperParser = new XMLMapperBuilder(inputStream, configuration, resource, configuration.getSqlFragments()); // 解析映射文件 mapperParser.parse(); // url 不为空，且其他两者为空，则通过 url 加载配置 } else if (resource == null && url != null && mapperClass == null) { ErrorContext.instance().resource(url); InputStream inputStream = Resources.getUrlAsStream(url); XMLMapperBuilder mapperParser = new XMLMapperBuilder(inputStream, configuration, url, configuration.getSqlFragments()); // 解析映射文件 mapperParser.parse(); // mapperClass 不为空，且其他两者为空，则通过 mapperClass 解析映射配置 } else if (resource == null && url == null && mapperClass != null) { Class mapperInterface = Resources.classForName(mapperClass); configuration.addMapper(mapperInterface); // 以上条件不满足，则抛出异常 } else { throw new BuilderException("A mapper element may only specify a url, resource or class, but not more than one."); } } } } } 上面的代码比较简单，主要逻辑是遍历 mappers 的子节点，并根据节点属性值判断通过什么方式加载映射文件或映射信息。这里，我把配置在注解中的内容称为映射信息，以 XML 为载体的配置称为映射文件。在 MyBatis 中，共有四种加载映射文件或信息的方式。第一种是从文件系统中加载映射文件；第二种是通过 URL 的方式加载和解析映射文件；第三种是通过 mapper 接口加载映射信息，映射信息可以配置在注解中，也可以配置在映射文件中。最后一种是通过包扫描的方式获取到某个包下的所有类，并使用第三种方式为每个类解析映射信息。 以上简单介绍了 MyBatis 加载映射文件或信息的几种方式。需要注意的是，在 MyBatis 中，通过注解配置映射信息的方式是有一定局限性的，这一点 MyBatis 官方文档中描述的比较清楚。这里引用一下： 因为最初设计时，MyBatis 是一个 XML 驱动的框架。配置信息是基于 XML 的，而且映射语句也是定义在 XML 中的。而到了 MyBatis 3，就有新选择了。MyBatis 3 构建在全面且强大的基于 Java 语言的配置 API 之上。这个配置 API 是基于 XML 的 MyBatis 配置的基础，也是新的基于注解配置的基础。注解提供了一种简单的方式来实现简单映射语句，而不会引入大量的开销。 注意： 不幸的是，Java 注解的的表达力和灵活性十分有限。尽管很多时间都花在调查、设计和试验上，最强大的 MyBatis 映射并不能用注解来构建——并不是在开玩笑，的确是这样。 如上所示，重点语句我用黑体标注了出来。限于 Java 注解的表达力和灵活性，通过注解的方式并不能完全发挥 MyBatis 的能力。所以，对于一些较为复杂的配置信息，我们还是应该通过 XML 的方式进行配置。正因此，在接下的章节中，我会重点分析基于 XML 的映射文件的解析过程。如果能弄懂此种配置方式的解析过程，那么基于注解的解析过程也不在话下。 下面开始分析映射文件的解析过程，在展开分析之前，先来看一下映射文件解析入口。如下： // -☆- XMLMapperBuilder public void parse() { // 检测映射文件是否已经被解析过 if (!configuration.isResourceLoaded(resource)) { // 解析 mapper 节点 configurationElement(parser.evalNode("/mapper")); // 添加资源路径到“已解析资源集合”中 configuration.addLoadedResource(resource); // 通过命名空间绑定 Mapper 接口 bindMapperForNamespace(); } // 处理未完成解析的节点 parsePendingResultMaps(); parsePendingCacheRefs(); parsePendingStatements(); } 如上，映射文件解析入口逻辑包含三个核心操作，分别如下： 解析 mapper 节点 通过命名空间绑定 Mapper 接口 处理未完成解析的节点 这三个操作对应的逻辑，我将会在随后的章节中依次进行分析。下面，先来分析第一个操作对应的逻辑。 2.1 解析映射文件 在 MyBatis 映射文件中，可以配置多种节点。比如 ，， 以及 等。下面我们来看一个映射文件配置示例。 author SELECT id, name, age, sex, email FROM WHERE id = #{id} 上面是一个比较简单的映射文件，还有一些的节点没有出现在上面。以上每种配置中的每种节点的解析逻辑都封装在了相应的方法中，这些方法由 XMLMapperBuilder 类的 configurationElement 方法统一调用。该方法的逻辑如下： private void configurationElement(XNode context) { try { // 获取 mapper 命名空间 String namespace = context.getStringAttribute("namespace"); if (namespace == null || namespace.equals("")) { throw new BuilderException("Mapper's namespace cannot be empty"); } // 设置命名空间到 builderAssistant 中 builderAssistant.setCurrentNamespace(namespace); // 解析 节点 cacheRefElement(context.evalNode("cache-ref")); // 解析 节点 cacheElement(context.evalNode("cache")); // 已废弃配置，这里不做分析 parameterMapElement(context.evalNodes("/mapper/parameterMap")); // 解析 节点 resultMapElements(context.evalNodes("/mapper/resultMap")); // 解析 节点 sqlElement(context.evalNodes("/mapper/sql")); // 解析 、...、 等节点 buildStatementFromContext(context.evalNodes("select|insert|update|delete")); } catch (Exception e) { throw new BuilderException("Error parsing Mapper XML. The XML location is '" + resource + "'. Cause: " + e, e); } } 上面代码的执行流程清晰明了。在阅读源码时，我们可以按部就班的分析每个方法调用即可。不过在写文章进行叙述时，需要做一些调整。下面我将会先分析 节点的解析过程，然后再分析 节点，之后会按照顺序分析其他节点的解析过程。接下来，我们来看看 节点的解析过程。 2.1.1 解析 节点 MyBatis 提供了一、二级缓存，其中一级缓存是 SqlSession 级别的，默认为开启状态。二级缓存配置在映射文件中，使用者需要显示配置才能开启。如果没有特殊要求，二级缓存的配置很容易。如下： 如果我们想修改缓存的一些属性，可以像下面这样配置。 根据上面的配置创建出的缓存有以下特点： 按先进先出的策略淘汰缓存项 缓存的容量为 512 个对象引用 缓存每隔60秒刷新一次 缓存返回的对象是写安全的，即在外部修改对象不会影响到缓存内部存储对象 除了上面两种配置方式，我们还可以给 MyBatis 配置第三方缓存或者自己实现的缓存等。比如，我们将 Ehcache 缓存整合到 MyBatis 中，可以这样配置。 以上简单介绍了几种缓存配置方式，关于 MyBatis 缓存更多的知识，后面我会独立成文进行分析，这里就不深入说明了。下面我们来分析一下缓存配置的解析逻辑，如下： private void cacheElement(XNode context) throws Exception { if (context != null) { // 获取各种属性 String type = context.getStringAttribute("type", "PERPETUAL"); Class typeClass = typeAliasRegistry.resolveAlias(type); String eviction = context.getStringAttribute("eviction", "LRU"); Class evictionClass = typeAliasRegistry.resolveAlias(eviction); Long flushInterval = context.getLongAttribute("flushInterval"); Integer size = context.getIntAttribute("size"); boolean readWrite = !context.getBooleanAttribute("readOnly", false); boolean blocking = context.getBooleanAttribute("blocking", false); // 获取子节点配置 Properties props = context.getChildrenAsProperties(); // 构建缓存对象 builderAssistant.useNewCache(typeClass, evictionClass, flushInterval, size, readWrite, blocking, props); } } 上面代码中，大段代码用来解析 节点的属性和子节点，这些代码没什么好说的。缓存的构建逻辑封装在 BuilderAssistant 类的 useNewCache 方法中，下面我们来看一下该方法的逻辑。 // -☆- MapperBuilderAssistant public Cache useNewCache(Class typeClass, Class evictionClass,Long flushInterval, Integer size,boolean readWrite,boolean blocking,Properties props) { // 使用建造模式构建缓存实例 Cache cache = new CacheBuilder(currentNamespace) .implementation(valueOrDefault(typeClass, PerpetualCache.class)) .addDecorator(valueOrDefault(evictionClass, LruCache.class)) .clearInterval(flushInterval) .size(size) .readWrite(readWrite) .blocking(blocking) .properties(props) .build(); // 添加缓存到 Configuration 对象中 configuration.addCache(cache); // 设置 currentCache 遍历，即当前使用的缓存 currentCache = cache; return cache; } 上面使用了建造模式构建 Cache 实例，Cache 实例的构建过程略为复杂，我们跟下去看看。 // -☆- CacheBuilder public Cache build() { // 设置默认的缓存类型（PerpetualCache）和缓存装饰器（LruCache） setDefaultImplementations(); // 通过反射创建缓存 Cache cache = newBaseCacheInstance(implementation, id); setCacheProperties(cache); // 仅对内置缓存 PerpetualCache 应用装饰器 if (PerpetualCache.class.equals(cache.getClass())) { // 遍历装饰器集合，应用装饰器 for (Class decorator : decorators) { // 通过反射创建装饰器实例 cache = newCacheDecoratorInstance(decorator, cache); // 设置属性值到缓存实例中 setCacheProperties(cache); } // 应用标准的装饰器，比如 LoggingCache、SynchronizedCache cache = setStandardDecorators(cache); } else if (!LoggingCache.class.isAssignableFrom(cache.getClass())) { // 应用具有日志功能的缓存装饰器 cache = new LoggingCache(cache); } return cache; } 上面的构建过程流程较为复杂，这里总结一下。如下： 设置默认的缓存类型及装饰器 应用装饰器到 PerpetualCache 对象上 遍历装饰器类型集合，并通过反射创建装饰器实例 将属性设置到实例中 应用一些标准的装饰器 对非 LoggingCache 类型的缓存应用 LoggingCache 装饰器 在以上4个步骤中，最后一步的逻辑很简单，无需多说。下面按顺序分析前3个步骤对应的逻辑，如下： private void setDefaultImplementations() { if (implementation == null) { // 设置默认的缓存实现类 implementation = PerpetualCache.class; if (decorators.isEmpty()) { // 添加 LruCache 装饰器 decorators.add(LruCache.class); } } } 以上逻辑比较简单，主要做的事情是在 implementation 为空的情况下，为它设置一个默认值。如果大家仔细看前面的方法，会发现 MyBatis 做了不少判空的操作。比如： // 判空操作1，若用户未设置 cache 节点的 type 和 eviction 属性，这里设置默认值 PERPETUAL String type = context.getStringAttribute("type", "PERPETUAL"); String eviction = context.getStringAttribute("eviction", "LRU"); // 判空操作2，若 typeClass 或 evictionClass 为空，valueOrDefault 方法会为它们设置默认值 Cache cache = new CacheBuilder(currentNamespace) .implementation(valueOrDefault(typeClass, PerpetualCache.class)) .addDecorator(valueOrDefault(evictionClass, LruCache.class)) // 省略部分代码 .build(); 既然前面已经做了两次判空操作，implementation 不可能为空，那么 setDefaultImplementations 方法似乎没有存在的必要了。其实不然，如果有人不按套路写代码。比如： Cache cache = new CacheBuilder(currentNamespace) // 忘记设置 implementation .build(); 这里忘记设置 implementation，或人为的将 implementation 设为空。如果不对 implementation 进行判空，会导致 build 方法在构建实例时触发空指针异常，对于框架来说，出现空指针异常是很尴尬的，这是一个低级错误。这里以及之前做了这么多判空，就是为了避免出现空指针的情况，以提高框架的健壮性。好了，关于 setDefaultImplementations 方法的分析先到这，继续往下分析。 我们在使用 MyBatis 内置缓存时，一般不用为它们配置自定义属性。但使用第三方缓存时，则应按需进行配置。比如前面演示 MyBatis 整合 Ehcache 时，就为 Ehcache 配置了一些必要的属性。下面我们来看一下这部分配置是如何设置到缓存实例中的。 private void setCacheProperties(Cache cache) { if (properties != null) { /* * 为缓存实例生成一个“元信息”实例，forObject 方法调用层次比较深，但最终调用了 * MetaClass 的 forClass 方法。关于 MetaClass 的源码，我在上一篇文章中已经 * 详细分析过了，这里不再赘述。 */ MetaObject metaCache = SystemMetaObject.forObject(cache); for (Map.Entry entry : properties.entrySet()) { String name = (String) entry.getKey(); String value = (String) entry.getValue(); if (metaCache.hasSetter(name)) { // 获取 setter 方法的参数类型 Class type = metaCache.getSetterType(name); /* * 根据参数类型对属性值进行转换，并将转换后的值 * 通过 setter 方法设置到 Cache 实例中 */ if (String.class == type) { metaCache.setValue(name, value); } else if (int.class == type || Integer.class == type) { /* * 此处及以下分支包含两个步骤： * 1.类型转换 → Integer.valueOf(value) * 2.将转换后的值设置到缓存实例中 → metaCache.setValue(name, value) */ metaCache.setValue(name, Integer.valueOf(value)); } else if (long.class == type || Long.class == type) { metaCache.setValue(name, Long.valueOf(value)); } else if (short.class == type || Short.class == type) {...} else if (byte.class == type || Byte.class == type) {...} else if (float.class == type || Float.class == type) {...} else if (boolean.class == type || Boolean.class == type) {...} else if (double.class == type || Double.class == type) {...} else { throw new CacheException("Unsupported property type for cache: '" + name + "' of type " + type); } } } } // 如果缓存类实现了 InitializingObject 接口，则

关键字：

青岛软件培训

可能你正在寻找一家靠谱的IT培训机构， 渴望突破职业瓶颈， 找一份得体的工作。 恰巧万码学堂正在寻找像你这样不甘平凡的追光者！ 我们拒绝纸上谈兵，直接参与真实开发流程！
现在行动，未来可期‌
立即拨打0532-85025005，预约免费职业规划咨询 前20名咨询者赠送《2025高薪技术岗位白皮书》!
你不是在报名课程，而是在投资五年后的自己！

申请免费试听课程

50000+

5万行代码练就真实本领

17年

创办于2008年老牌培训机构

1000+

合作企业

98%

就业率

联系我们

电话咨询

0532-85025005

扫码添加微信