通过前面两篇文章，我们完成了对 MyBatis 所有配置文件（包括配置文件和映射文件）解析过程的分析。回忆一下我们最开始给出的小示例（如下），经过前面的跋山涉水，我们终于完成了第一行代码的 99% （手动滑稽），这最后的 1% 就是创建 SqlSessionFactory 对象。所有的配置解析最后都会封装到 Configuration 对象中，接下去就是调用 SqlSessionFactoryBuilder#build 方法创建 SqlSessionFactory 对象，实际使用的是 DefaultSqlSessionFactory 实现类进行实例化。

上一篇我们分析了配置文件的加载与解析过程，本文将继续对映射文件的加载与解析实现进行分析。MyBatis 的映射文件用于配置 SQL 语句、二级缓存，以及结果集映射等，是区别于其它 ORM 框架的主要特色之一。

在上一篇分析配置文件 <mappers/> 标签的解析实现时，了解到 MyBatis 最终通过调用 XMLMapperBuilder#parse 方法实现对映射文件的解析操作，本文我们将以此方法作为入口，探究 MyBatis 加载和解析映射文件的实现机制。

上一篇我们曾约定 mybatis-config.xml 文件为配置文件，SQL 语句配置文件为映射文件，本文我们将沿用上一篇中的示例程序，一起探究一下 MyBatis 加载和解析配置文件（即 mybatis-config.xml）的过程。

配置文件的加载过程

在示例程序中，执行配置文件（包括后面要介绍的映射文件）加载与解析的过程位于第一行代码中（如下）。其中，Resources 是一个简单的基于类路径或其它位置获取数据流的工具类，借助该工具类可以获取配置文件的 InputStream 流对象，然后将其传递给 SqlSessionFactoryBuilder#build 方法以构造 SqlSessionFactory 对象。

MyBatis 是一个易用、轻量，且强大的半自动化 ORM 框架，在设计思想和代码实现上都有许多值得我们借鉴的地方，例如动态代理机制的应用，资源文件的加载与解析，缓存模块的设计、反射机制的应用，插件模块的设计，架构分层，以及对设计模式的应用等，是一个非常适合初入源码阅读领域的练手项目。本系列文章将从配置文件解析、映射文件解析，以及 SQL 语句执行机制这三个大方向对整个框架的实现展开分析。本文是本系列的第一篇文章，主要从整体的角度对 MyBatis 的架构设计做一个综述性的介绍。

什么？Paxos 号称是最难理解的算法？虽然有些夸张，那也得看一下！

直接入正题，在分布式系统中存在多个主机节点，这些主机之间的通信机制一般分为 共享内存 和 消息传递 两种。这两种方式各有优劣，而 paxos 算法主要用来解决基于消息机制的分布式一致性问题。

在分布式系统中，网络一般被认为是不可靠的，所以传递的消息可能会存在延迟、丢失、重复等问题，发送消息的进程也可能出现运行缓慢、重启，甚至被杀死等情况。Paxos 算法解决的问题是在一个可能发生这些异常（不包括消息可能被篡改的情况）的分布式系统中如何就某个值达成一致，保证不论发生以上任何异常，都不会破坏决策一致性的问题。

Java 多线程类库对于共享数据的读写访问主要采用同步机制来保证线程安全，而本文所要探究的 ThreadLocal 则采用了一种完全不同的策略，它不是用来解决共享数据的并发访问问题的，ThreadLocal 让每个线程都将目标数据复制一份作为线程私有，后续对于该数据的操作都是在各自私有的副本上进行，线程之间彼此相互隔离，也就不存在竞争问题。

下面的例子演示了 ThreadLocal 的典型应用场景。在 jdk 1.8 之前，如果我们希望对日期和时间进行格式化操作，则需要使用 SimpleDateFormat 类，而我们知道它是是线程不安全的，在多线程并发执行时会出现一些奇怪的问题。

上一篇我们分析了 web 环境下容器的初始化过程，探究了在 web 项目启动过程中，Spring MVC 所执行的一系列初始化工作，本篇中我们将一起来跟踪一次 Spring MVC 对于请求的具体处理过程，从整体上对 Spring MVC 的逻辑处理进行感知，先把握整体，后追究细节。

Spring MVC 是目前最流行的 java web 框架（之一），是对传统 servlet 的高级封装，以提升 servlet 的灵活性和易用性。从广义上来说，Spring MVC 的执行过程可以分为 容器初始化 和 请求响应处理 两大部分，前者在 servlet 容器启动过程中完成，为后者的执行提供基本的运行环境，而后者则是 Spring MVC 的核心所在，负责接收请求到最终返回响应数据的复杂处理过程。

IoC 和 AOP 被称为 Spring 两大基础模块，支撑着上层扩展的实现和运行。虽然 AOP 同样建立在 IoC 的实现基础之上，但是作为对 OOP(Object-Oriented Programing) 的补充，AOP(Aspect-Oriented Programming) 在程序设计领域拥有其不可替代的适用场景和地位。Spring AOP 作为 AOP 思想的实现，被誉为 Spring 框架的基础模块也算是实至名归。Spring 在 1.0 版本的时候就引入了对 AOP 的支持，并且随着版本的迭代逐渐提供了基于 XML 配置、注解，以及 schema 配置的使用方式，考虑到实际开发中使用注解配置的方式相对较多，所以本文主要分析注解式 AOP 的实现和运行机制。

Spring 为开发人员提供了极其灵活和强大的配置使用方式，在方便开发的同时也为容器的初始化过程带来了不确定性。本文所要介绍的循环依赖就是其中之一，尤其在一些大型项目中，循环依赖的配置往往是我们不经意而为之的，幸好 Spring 能够在初始化的过程中检测到对象之间的循环依赖，并能够在一定程度上予以处理。