spring原理解析

一、spring整体架构

1、spring IOC：

spring核心与基础，包含最基本的IOC容器BeanFactory接口的实现和该接口的扩展上下文，例如：XMLBeanFactory、SimpleJndiBeanFactory，还有一些上下文的实现，如：FileSystemXMLApplicationContext、ClassPathXMLApplicationContext

2、spring aop

spring的核心模块，围绕着aop的增强功能，spring继承了aspectJ作为aop的一个特定实现，同事还在jvm动态代理CGLIB的基础上，实现了一个aop框架，作为spring集成其他模块的工具，比如TransactioProxyFactoryBean声明式事务处理，就是通过aop集成到spring中的；

3、spring mvc

构建web应用的模块，该模块一DispatcherServlet为核心，实现了mvc模式；

4、spring jdbc/spring orm 

spring 数据持久化，类似于hibernate和mybatis；

5、spring事务处理

spring事务处理是一个通过spring aop实现自身功能增强的典型模块；在这个模块中，spring把在企业应用开发中事务处理的主要过程抽象出来，并且简洁的通过aop的切面增强实现了声明式事务处理的过程；而且这些事务处理的过程和具体的事务处理器的实现是无关的，应用可以选择不同的事务实现机制；

6、spring 远程调用

7、spring应用

二、spring IOC实现

从Spring要做到的目标，也就是从简化Java EE开发的出发点来看，简单的来说，它是通过对POJO开发的支持，来具体实现的；具体的说，Spring通过为应用开发提供基于POJO的开发模式，把应用开发和复杂的Java EE服务，实现解耦，并通过提高单元测试的覆盖率，从而有效的提高整个应用的开发质量。这样一来，实际上，就需要把为POJO提供支持的，各种Java EE服务支持抽象到应用平台中去，去封装起来；而这种封装功能的实现，在Spring中，就是由IOC容器以及AOP来具体提供的，这两个模块，在很大程度上，体现了Spring作为应用开发平台的核心价值。

对Spring IOC的理解离不开对依赖反转模式的理解，我们知道，关于如何反转对依赖的控制，把控制权从具体业务对象手中转交到平台或者框架中，是解决面向对象系统设计复杂性和提高面向对象系统可测试性的一个有效的解决方案。这个问题触发了IoC设计模式的发展，是IoC容器要解决的核心问题。同时，也是产品化的IoC容器出现的推动力。而我觉得Spring的IoC容器，就是一个开源的实现依赖反转模式的产品。 

那具体什么是IoC容器呢？它在Spring框架中到底长什么样？说了这么多，其实对IoC容器的使用者来说，我们常常接触到的BeanFactory和ApplicationContext都可以看成是容器的具体表现形式。这些就是IoC容器，或者说在Spring中提IoC容器，从实现来说，指的是一个容器系列。这也就是说，我们通常所说的IoC容器，如果深入到Spring的实现去看，会发现IoC容器实际上代表着一系列功能各异的容器产品。只是容器的功能有大有小，有各自的特点。打个比方来说，就像是百货商店里出售的商品，我们举水桶为例子，在商店中出售的水桶有大有小；制作材料也各不相同，有金属的，有塑料的等等，总之是各式各样，但只要能装水，具备水桶的基本特性，那就可以作为水桶来出售来让用户使用。这在Spring中也是一样，它有各式各样的IoC容器的实现供用户选择和使用；使用什么样的容器完全取决于用户的需要，但在使用之前如果能够了解容器的基本情况，那会对容器的使用是非常有帮助的；就像我们在购买商品时进行的对商品的考察和挑选那样。 
我们从最基本的XmlBeanFactory看起，它是容器系列的最底层实现，这个容器的实现与我们在Spring应用中用到的那些上下文相比，有一个非常明显的特点，它只提供了最基本的IoC容器的功能。从它的名字中可以看出，这个IoC容器可以读取以XML形式定义的BeanDefinition。理解这一点有助于我们理解ApplicationContext与基本的BeanFactory之间的区别和联系。我们可以认为直接的BeanFactory实现是IoC容器的基本形式，而各种ApplicationContext的实现是IoC容器的高级表现形式。

XmlBeanFactory的功能是建立在DefaultListableBeanFactory这个基本容器的基础上的，在这个基本容器的基础上实现了其他诸如XML读取的附加功能。对于这些功能的实现原理，看一看XmlBeanFactory的代码实现就能很容易地理解。在如下的代码中可以看到，在XmlBeanFactory构造方法中需要得到Resource对象。对XmlBeanDefinitionReader对象的初始化，以及使用这个这个对象来完成loadBeanDefinitions的调用，就是这个调用启动了从Resource中载入BeanDefinitions的过程，这个loadBeanDefinitions同时也是IoC容器初始化的重要组成部分。 

简单来说，IoC容器的初始化包括BeanDefinition的Resouce定位、载入和注册这三个基本的过程。我觉得重点是在载入和对BeanDefinition做解析的这个过程。可以从DefaultListableBeanFactory来入手看看IoC容器是怎样完成BeanDefinition载入的。在refresh调用完成以后，可以看到loadDefinition的调用。

三、spring AOP

AOP联盟定义的AOP体系结构把与AOP相关的概念大致分为了由高到低、从使用到实现的三个层次。关于这个体系结构，个人的理解是这样的，从上往下，最高层是语言和开发环境，在这个环境中可以看到几个重要的概念：base可以视为待增强对象，或者说目标对象；aspect指切面，通常包含对于base的增强应用；configuration可以看成是一种编织或者说配置，通过在AOP体系中提供这个configuration配置环境，可以把base和aspect结合起来，从而完成切面对目标对象的编织实现。

Spring AOP的实现和其他特性的实现一样，非常丰富，除了可以使用Spring本身提供的AOP实现之外，还封装了业界优秀的AOP解决方案AspectJ来让应用使用。在这里，主要对Spring自身的AOP实现原理做一些解析；在这个AOP实现中，Spring充分利用了IOC容器Proxy代理对象以及AOP拦截器的功能特性，通过这些对AOP基本功能的封装机制，为用户提供了AOP的实现框架。所以，要了解这些AOP的基本实现，需要我们对Java 的Proxy机制有一些基本了解，Java动态代理是通过反射来实现的。

AOP实现中，可以看到三个主要的步骤，一个是代理对象的生成，然后是拦截器的作用，然后是Aspect编织的实现。AOP框架的丰富，很大程度体现在这三个具体实现中，所具有的丰富的技术选择，以及如何实现与IOC容器的无缝结合。毕竟这也是一个非常核心的模块，需要满足不同的应用需求带来的解决方案需求。 

在Spring AOP的实现原理中，我们主要举ProxyFactoryBean的实现作为例子和实现的基本线索进行分析；很大一个原因，是因为ProxyFactoryBean是在Spring IoC环境中，创建AOP应用的最底层方法，从中，可以看到一条实现AOP的基本线索。在ProxyFactoryBean中，它的AOP实现需要依赖JDK或者CGLIB提供的Proxy特性。从FactoryBean中获取对象，是从getObject()方法作为入口完成的。然后为proxy代理对象配置advisor链，这个配置是在initializeAdvisorChain方法中完成的；

代理对象的生成，有CGLIB和JDK两种生成方式，在CGLIB中，对拦截器设计是通过在Cglib2AopProxy的AopProxy代理对象生成的时候，在回调DynamicAdvisedInterceptor对象中实现的，这个回调的实现在intercept方法中完成。对于AOP是怎样完成对目标对象的增强的，这些实现是封装在AOP拦截器链中，由一个个具体的拦截器来完成的。具体拦截器的运行是在以下的代码实现中完成的，这些调用在ReflectiveMethodInvocation中。 

在调用拦截器的时候，我们接下去就可以看到对advice的通知的调用。而经过一系列的注册，适配的过程以后，拦截器在拦截的时候，会调用到预置好的一个通知适配器，设置通知拦截器，这是一系列Spring设计好为通知服务的类的一个，是最终完成通知拦截和实现的地方，非常的关键。

Spring aop是通过Java的动态代理来实现，在运行期织入切面。而asptctj则是通过直接修改字节码来实现，在编译期或则类加载期织入，所以，asptctj的功能要比spring aop强大很多。

四、spring jdbc

spring jdbc 是通过Java template来实现的。

在使用数据库的时候，有一个很重要的地方就是对数据库连接的管理，在这里，是由DataSourceUtils来完成的。Spring通过这个辅助类来对数据的Connection进行管理。比如通过它来完成打开和关闭Connection等操作。

从JdbcTemplate中，我们看到，他提供了许多简单查询和更新的功能。但是，如果需要更高层次的抽象，以及更面向对象的方法来访问数据库，Spring为我们提供了org.springframework.jdbc.object包，里面包含了SqlQuery、SqlMappingQuery、SqlUpdate和StoredProcedure等类，这些类都是Spring JDBC应用程序可以使用的。但要注意，在使用这些类时需要为它们配置好JdbcTemplate作为其基本的操作实现，因为在它们的功能实现中，对数据库操作的那部分实现基本上还是依赖于JdbcTemplate来完成的。 

比如，对MappingSqlQuery使用的过程，是非常简洁的；在设计好数据的映射代码之后，查询得到的记录已经按照前面的设计转换为对象List了，一条查询记录对应于一个数据对象，可以把数据库的数据记录直接映射成Java对象在程序中使用，同时又可避免使用第三方ORM工具的配置，对于简单的数据映射场合是非常方便的；在mapRow方法的实现中提供的数据转换规则，和我们使用Hibernate时，Hibernate的hbm文件起到的作用是非常类似的。

五、spring mvc

在了解IOC容器的基本实现的基础上，下面我们来看看，在典型的Web环境中，Spring IOC容器是如何在Web环境中被载入并起作用的。我们可以看到，对于MVC这部分，主要建立在IOC的基础上，AOP的特性应用得并不多。Spring并不是天生就能在Web容器中起作用的，同样也需要一个启动过程，把自己的IOC容器导入，并在Web容器中建立起来。 

与对IoC容器的初始化的分析一样，我们同样看到了loadBeanDefinition对BeanDefinition的载入。在Web环境中，对定位BeanDefinition的Resource有特别的要求，对这个要求的处理体现在getDefaultConfigLocations方法的处理中。可以看到，在这里，使用了默认的BeanDefinition的配置路径，这个路径在XmlWebApplicationContext中，已经作为一个常量定义好了，这个常量就是/WEB-INF/applicationContext.xml。

完成了在Web环境中，IoC容器的建立以后，也就是在完成对ContextLoaderListener的初始化以后，Web容器开始初始化DispatcherServlet，接着，会执行DispatcherServlet持有的IoC容器的初始化过程，在这个初始化过程中，一个新的上下文被建立起来，这个DispatcherServlet持有的上下文，被设置为根上下文的子上下文。可以大致认为，根上下文是和Web应用相对应的一个上下文，而DispatcherServlet持有的上下文是和Servlet对应的一个上下文，在一个Web应用中，往往可以容纳多个Servlet存在；与此相对应，对于应用在Web容器中的上下体系，也是很类似的，一个根上下文可以作为许多Servlet上下文的双亲上下文。在DispatcherServlet，我们可以看到对MVC的初始化，是在DispatcherServlet的initStrategies完成的。 
在这个初始化完成以后，会在上下文中建立器一个执行器于url的对应关系，这个对应关系可以让在url请求到来的时候，MVC可以检索到相应的控制器来进行处理。