JAVA知识点（三）：Spring与ORM框架

文章目录

• • Spring
  • • SpringIOC
    • SpringAOP
    • SpringMVC
    • Spring中运用了那些设计模式
    • Spring中的Bean是线程安全的吗
    • Spring中的Bean的作用域
    • Spring中的Bean的生命周期
    • Spring事务的传播行为
    • Spring事务默认抛出什么异常*斜体样式*
  • Mybatis
  • • Mybatis源码解析
    • Mybatis缓存
    • Mybatis中运用了那些设计模式
    • 静态代理、JDK动态代理与cglib动态代理区别

Spring

SpringIOC

谈谈对Spring IOC的理解

学习过Spring框架的人一定都会听过Spring的IoC(控制反转) 、DI(依赖注入)这两个概念，对于初学Spring的人来说，总觉得IoC 、DI这两个概念是模糊不清的，是很难理解的，今天和大家分享网上的一些技术大牛们对Spring框架的IOC的理解以及谈谈我对Spring Ioc的理解。

一、分享Iteye的开涛对Ioc的精彩讲解

首先要分享的是Iteye的开涛这位技术牛人对Spring框架的IOC的理解，写得非常通俗易懂，以下内容全部来自原文，原文地址：http://jinnianshilongnian.iteye.com/blog/1413846

1.1、IoC是什么

Ioc---Inversion of Control，即"控制反转"，不是什么技术，而是一种设计思想。在Java开发中，Ioc意味着将你设计好的对象交给容器控制，而不是传统的在你的对象内部直接控制。如何理解好Ioc呢？理解好Ioc的关键是要明确"谁控制谁，控制什么，为何是反转（有反转就应该有正转了），哪些方面反转了"，那我们来深入分析一下：

●谁控制谁，控制什么：传统Java SE程序设计，我们直接在对象内部通过new进行创建对象，是程序主动去创建依赖对象；而IoC是有专门一个容器来创建这些对象，即由Ioc容器来控制对 象的创建；谁控制谁？当然是IoC 容器控制了对象；控制什么？那就是主要控制了外部资源获取（不只是对象包括比如文件等）。

●为何是反转，哪些方面反转了：有反转就有正转，传统应用程序是由我们自己在对象中主动控制去直接获取依赖对象，也就是正转；而反转则是由容器来帮忙创建及注入依赖对象；为何是反转？因为由容器帮我们查找及注入依赖对象，对象只是被动的接受依赖对象，所以是反转；哪些方面反转了？依赖对象的获取被反转了。

用图例说明一下，传统程序设计如图2-1，都是主动去创建相关对象然后再组合起来：

图1-1 传统应用程序示意图

当有了IoC/DI的容器后，在客户端类中不再主动去创建这些对象了，如图2-2所示:

图1-2有IoC/DI容器后程序结构示意图

1.2、IoC能做什么

IoC 不是一种技术，只是一种思想，一个重要的面向对象编程的法则，它能指导我们如何设计出松耦合、更优良的程序。传统应用程序都是由我们在类内部主动创建依赖对象，从而导致类与类之间高耦合，难于测试；有了IoC容器后，把创建和查找依赖对象的控制权交给了容器，由容器进行注入组合对象，所以对象与对象之间是 松散耦合，这样也方便测试，利于功能复用，更重要的是使得程序的整个体系结构变得非常灵活。

其实IoC对编程带来的最大改变不是从代码上，而是从思想上，发生了"主从换位"的变化。应用程序原本是老大，要获取什么资源都是主动出击，但是在IoC/DI思想中，应用程序就变成被动的了，被动的等待IoC容器来创建并注入它所需要的资源了。

IoC很好的体现了面向对象设计法则之一------ 好莱坞法则："别找我们，我们找你"；即由IoC容器帮对象找相应的依赖对象并注入，而不是由对象主动去找。

1.3、IoC和DI

DI---Dependency Injection，即"依赖注入"：组件之间依赖关系由容器在运行期决定，形象的说，即由容器动态的将某个依赖关系注入到组件之中。依赖注入的目的并非为软件系统带来更多功能，而是为了提升组件重用的频率，并为系统搭建一个灵活、可扩展的平台。通过依赖注入机制，我们只需要通过简单的配置，而无需任何代码就可指定目标需要的资源，完成自身的业务逻辑，而不需要关心具体的资源来自何处，由谁实现。

理解DI的关键是："谁依赖谁，为什么需要依赖，谁注入谁，注入了什么"，那我们来深入分析一下：

●谁依赖于谁：当然是应用程序依赖于IoC容器；

●为什么需要依赖：应用程序需要IoC容器来提供对象需要的外部资源；

●谁注入谁：很明显是IoC容器注入应用程序某个对象，应用程序依赖的对象；

●注入了什么：就是注入某个对象所需要的外部资源（包括对象、资源、常量数据）。

IoC和DI由什么关系呢？其实它们是同一个概念的不同角度描述，由于控制反转概念比较含糊（可能只是理解为容器控制对象这一个层面，很难让人想到谁来维护对象关系），所以2004年大师级人物Martin Fowler又给出了一个新的名字："依赖注入"，相对IoC 而言，"依赖注入"明确描述了"被注入对象依赖IoC容器配置依赖对象"。

看过很多对Spring的Ioc理解的文章，好多人对Ioc和DI的解释都晦涩难懂，反正就是一种说不清，道不明的感觉，读完之后依然是一头雾水，感觉就是开涛这位技术牛人写得特别通俗易懂，他清楚地解释了IoC(控制反转) 和DI(依赖注入)中的每一个字，读完之后给人一种豁然开朗的感觉。我相信对于初学Spring框架的人对Ioc的理解应该是有很大帮助的。

二、分享Bromon的blog上对IoC与DI浅显易懂的讲解

2.1、IoC(控制反转)

首先想说说IoC（Inversion of Control，控制反转）。这是spring的核心，贯穿始终。所谓IoC，对于spring框架来说，就是由spring来负责控制对象的生命周期和对象间的关系。这是什么意思呢，举个简单的例子，我们是如何找女朋友的？常见的情况是，我们到处去看哪里有长得漂亮身材又好的mm，然后打听她们的兴趣爱好、qq号、电话号、ip号、iq号.........，想办法认识她们，投其所好送其所要，然后嘿嘿......这个过程是复杂深奥的，我们必须自己设计和面对每个环节。传统的程序开发也是如此，在一个对象中，如果要使用另外的对象，就必须得到它（自己new一个，或者从JNDI中查询一个），使用完之后还要将对象销毁（比如Connection等），对象始终会和其他的接口或类藕合起来。

那么IoC是如何做的呢？有点像通过婚介找女朋友，在我和女朋友之间引入了一个第三者：婚姻介绍所。婚介管理了很多男男女女的资料，我可以向婚介提出一个列表，告诉它我想找个什么样的女朋友，比如长得像李嘉欣，身材像林熙雷，唱歌像周杰伦，速度像卡洛斯，技术像齐达内之类的，然后婚介就会按照我们的要求，提供一个mm，我们只需要去和她谈恋爱、结婚就行了。简单明了，如果婚介给我们的人选不符合要求，我们就会抛出异常。整个过程不再由我自己控制，而是有婚介这样一个类似容器的机构来控制。Spring所倡导的开发方式就是如此，所有的类都会在spring容器中登记，告诉spring你是个什么东西，你需要什么东西，然后spring会在系统运行到适当的时候，把你要的东西主动给你，同时也把你交给其他需要你的东西。所有的类的创建、销毁都由 spring来控制，也就是说控制对象生存周期的不再是引用它的对象，而是spring。对于某个具体的对象而言，以前是它控制其他对象，现在是所有对象都被spring控制，所以这叫控制反转。

2.2、DI(依赖注入)

IoC的一个重点是在系统运行中，动态的向某个对象提供它所需要的其他对象。这一点是通过DI（Dependency Injection，依赖注入）来实现的。比如对象A需要操作数据库，以前我们总是要在A中自己编写代码来获得一个Connection对象，有了 spring我们就只需要告诉spring，A中需要一个Connection，至于这个Connection怎么构造，何时构造，A不需要知道。在系统运行时，spring会在适当的时候制造一个Connection，然后像打针一样，注射到A当中，这样就完成了对各个对象之间关系的控制。A需要依赖 Connection才能正常运行，而这个Connection是由spring注入到A中的，依赖注入的名字就这么来的。那么DI是如何实现的呢？ Java 1.3之后一个重要特征是反射（reflection），它允许程序在运行的时候动态的生成对象、执行对象的方法、改变对象的属性，spring就是通过反射来实现注入的。

理解了IoC和DI的概念后，一切都将变得简单明了，剩下的工作只是在spring的框架中堆积木而已。

三、我对IoC(控制反转)和DI(依赖注入)的理解

在平时的java应用开发中，我们要实现某一个功能或者说是完成某个业务逻辑时至少需要两个或以上的对象来协作完成，在没有使用Spring的时候，每个对象在需要使用他的合作对象时，自己均要使用像new object() 这样的语法来将合作对象创建出来，这个合作对象是由自己主动创建出来的，创建合作对象的主动权在自己手上，自己需要哪个合作对象，就主动去创建，创建合作对象的主动权和创建时机是由自己把控的，而这样就会使得对象间的耦合度高了，A对象需要使用合作对象B来共同完成一件事，A要使用B，那么A就对B产生了依赖，也就是A和B之间存在一种耦合关系，并且是紧密耦合在一起，而使用了Spring之后就不一样了，创建合作对象B的工作是由Spring来做的，Spring创建好B对象，然后存储到一个容器里面，当A对象需要使用B对象时，Spring就从存放对象的那个容器里面取出A要使用的那个B对象，然后交给A对象使用，至于Spring是如何创建那个对象，以及什么时候创建好对象的，A对象不需要关心这些细节问题(你是什么时候生的，怎么生出来的我可不关心，能帮我干活就行)，A得到Spring给我们的对象之后，两个人一起协作完成要完成的工作即可。

所以控制反转IoC(Inversion of Control)是说创建对象的控制权进行转移，以前创建对象的主动权和创建时机是由自己把控的，而现在这种权力转移到第三方，比如转移交给了IoC容器，它就是一个专门用来创建对象的工厂，你要什么对象，它就给你什么对象，有了 IoC容器，依赖关系就变了，原先的依赖关系就没了，它们都依赖IoC容器了，通过IoC容器来建立它们之间的关系。

这是我对Spring的IoC(控制反转)的理解。DI(依赖注入)其实就是IOC的另外一种说法，DI是由Martin Fowler 在2004年初的一篇论文中首次提出的。他总结：控制的什么被反转了？就是：获得依赖对象的方式反转了。

四、小结

对于Spring Ioc这个核心概念，我相信每一个学习Spring的人都会有自己的理解。这种概念上的理解没有绝对的标准答案，仁者见仁智者见智。如果有理解不到位或者理解错的地方，欢迎广大园友指正！

Spring容器高层视图

Spring 启动时读取应用程序提供的Bean配置信息，并在Spring容器中生成一份相应的Bean配置注册表，然后根据这张注册表实例化Bean，装配好Bean之间的依赖关系，为上层应用提供准备就绪的运行环境。

Bean缓存池：HashMap实现

IOC容器介绍

Spring 通过一个配置文件描述 Bean 及 Bean 之间的依赖关系，利用 Java 语言的反射功能实例化 Bean 并建立 Bean 之间的依赖关系。 Spring 的 IoC 容器在完成这些底层工作的基础上，还提供了 Bean 实例缓存、生命周期管理、 Bean 实例代理、事件发布、资源装载等高级服务。

BeanFactory 是 Spring 框架的基础设施，面向 Spring 本身；

ApplicationContext 面向使用 Spring 框架的开发者，几乎所有的应用场合我们都直接使用 ApplicationContext 而非底层的 BeanFactory。

BeanFactory

BeanFactory体系架构：

BeanDefinitionRegistry： Spring 配置文件中每一个节点元素在 Spring 容器里都通过一个 BeanDefinition 对象表示，它描述了 Bean 的配置信息。而 BeanDefinitionRegistry 接口提供了向容器手工注册 BeanDefinition 对象的方法。

BeanFactory 接口位于类结构树的顶端 ，它最主要的方法就是 getBean(String beanName)，该方法从容器中返回特定名称的 Bean，BeanFactory 的功能通过其他的接口得到不断扩展：

ListableBeanFactory：该接口定义了访问容器中 Bean 基本信息的若干方法，如查看Bean 的个数、获取某一类型 Bean 的配置名、查看容器中是否包括某一 Bean 等方法；

HierarchicalBeanFactory：父子级联 IoC 容器的接口，子容器可以通过接口方法访问父容器； 通过 HierarchicalBeanFactory 接口， Spring 的 IoC 容器可以建立父子层级关联的容器体系，子容器可以访问父容器中的 Bean，但父容器不能访问子容器的 Bean。Spring 使用父子容器实现了很多功能，比如在 Spring MVC 中，展现层 Bean 位于一个子容器中，而业务层和持久层的 Bean 位于父容器中。这样，展现层 Bean 就可以引用业务层和持久层的 Bean，而业务层和持久层的 Bean 则看不到展现层的 Bean。

ConfigurableBeanFactory：是一个重要的接口，增强了 IoC 容器的可定制性，它定义了设置类装载器、属性编辑器、容器初始化后置处理器等方法；

AutowireCapableBeanFactory：定义了将容器中的 Bean 按某种规则（如按名字匹配、按类型匹配等）进行自动装配的方法；

SingletonBeanRegistry：定义了允许在运行期间向容器注册单实例 Bean 的方法；

例子：

使用 Spring 配置文件为 Car 提供配置信息：beans.xml：

通过 BeanFactory 装载配置文件，启动 Spring IoC 容器：

XmlBeanFactory 通过 Resource 装载 Spring 配置信息并启动 IoC 容器，然后就可以通过 BeanFactory#getBean(beanName)方法从 IoC 容器中获取 Bean 了。通过 BeanFactory 启动IoC 容器时，并不会初始化配置文件中定义的 Bean，初始化动作发生在第一个调用时。

对于单实例（ singleton）的 Bean 来说，BeanFactory会缓存 Bean 实例，所以第二次使用 getBean() 获取 Bean 时将直接从 IoC 容器的缓存中获取 Bean 实例。Spring 在 DefaultSingletonBeanRegistry 类中提供了一个用于缓存单实例 Bean 的缓存器，它是一个用HashMap 实现的缓存器，单实例的 Bean 以 beanName 为键保存在这个HashMap 中。

值得一提的是，在初始化 BeanFactory 时，必须为其提供一种日志框架，比如使用Log4J， 即在类路径下提供 Log4J 配置文件，这样启动 Spring 容器才不会报错。

ApplicationContext

ApplicationContext 由 BeanFactory 派生而来，提供了更多面向实际应用的功能。

在BeanFactory 中，很多功能需要以编程的方式实现，而在 ApplicationContext 中则可以通过配置的方式实现。

ApplicationContext 继承了 HierarchicalBeanFactory 和 ListableBeanFactory 接口，在此基础上，还通过多个其他的接口扩展了 BeanFactory 的功能：

ClassPathXmlApplicationContext：默认从类路径加载配置文件

FileSystemXmlApplicationContext：默认从文件系统中装载配置文件

ApplicationEventPublisher：让容器拥有发布应用上下文事件的功能，包括容器启动事件、关闭事件等。实现了 ApplicationListener 事件监听接口的 Bean 可以接收到容器事件 ， 并对事件进行响应处理 。 在 ApplicationContext 抽象实现类AbstractApplicationContext 中，我们可以发现存在一个 ApplicationEventMulticaster，它负责保存所有监听器，以便在容器产生上下文事件时通知这些事件监听者。

MessageSource：为应用提供 i18n 国际化消息访问的功能；

ResourcePatternResolver ： 所 有 ApplicationContext 实现类都实现了类似于PathMatchingResourcePatternResolver 的功能，可以通过带前缀的 Ant 风格的资源文件路径装载 Spring 的配置文件。

LifeCycle：该接口是 Spring 2.0 加入的，该接口提供了 start()和 stop()两个方法，主要用于控制异步处理过程。在具体使用时，该接口同时被 ApplicationContext 实现及具体 Bean 实现， ApplicationContext 会将 start/stop 的信息传递给容器中所有实现了该接口的 Bean，以达到管理和控制 JMX、任务调度等目的。

ConfigurableApplicationContext 扩展于 ApplicationContext，它新增加了两个主要的方法： refresh()和 close()，让 ApplicationContext 具有启动、刷新和关闭应用上下文的能力。在应用上下文关闭的情况下调用 refresh()即可启动应用上下文，在已经启动的状态下，调用 refresh()则清除缓存并重新装载配置信息，而调用close()则可关闭应用上下文。这些接口方法为容器的控制管理带来了便利，但作为开发者，我们并不需要过多关心这些方法。

使用：

如果配置文件放置在类路径下，用户可以优先使用 ClassPathXmlApplicationContext 实现类：

如果配置文件放置在文件系统的路径下，则可以优先考虑使用 FileSystemXmlApplicationContext 实现类：

Spring 3.0 支持基于类注解的配置方式，主要功能来自于 Spring 的一个名为 JavaConfig 子项目，目前 JavaConfig已经升级为 Spring核心框架的一部分。

ApplicationContext 在初始化应用上下文时就实例化所有单实例的 Bean。

WebApplicationContext

WebApplication体系架构：

WebApplicationContext 是专门为 Web 应用准备的，它允许从相对于 Web 根目录的路径中装载配置文件完成初始化工作。从WebApplicationContext 中可以获得 ServletContext 的引用，整个 Web 应用上下文对象将作为属性放置到 ServletContext 中，以便 Web 应用环境可以访问 Spring 应用上下文。 WebApplicationContext 定义了一个常量ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE，在上下文启动时， WebApplicationContext 实例即以此为键放置在 ServletContext 的属性列表中，因此我们可以直接通过以下语句从 Web 容器中获取WebApplicationContext：

Spring 和 Web 应用的上下文融合：

WebApplicationContext 的初始化方式：WebApplicationContext 需要 ServletContext 实例，它必须在拥有 Web 容器的前提下才能完成启动的工作。可以在 web.xml 中配置自启动的 Servlet 或定义 Web 容器监听器（ ServletContextListener），借助这两者中的任何一个就可以完成启动 Spring Web 应用上下文的工作。Spring 分别提供了用于启动 WebApplicationContext 的 Servlet 和 Web 容器监听器：

org.springframework.web.context.ContextLoaderServlet；

org.springframework.web.context.ContextLoaderListener

由于 WebApplicationContext 需要使用日志功能，比如日志框架使用Log4J，用户可以将 Log4J 的配置文件放置到类路径 WEB-INF/classes 下，这时 Log4J 引擎即可顺利启动。如果 Log4J 配置文件放置在其他位置，用户还必须在 web.xml 指定 Log4J 配置文件位置。

Bean的生命周期

1．当调用者通过 getBean(beanName)向容器请求某一个 Bean 时，如果容器注册了org.springframework.beans.factory.config.InstantiationAwareBeanPostProcessor 接口，在实例化 Bean 之前，将调用接口的 postProcessBeforeInstantiation()方法；

2．根据配置情况调用 Bean 构造函数或工厂方法实例化 Bean；

3．如果容器注册了 InstantiationAwareBeanPostProcessor 接口，在实例化 Bean 之后，调用该接口的 postProcessAfterInstantiation()方法，可在这里对已经实例化的对象进行一些"梳妆打扮"；

4．如果 Bean 配置了属性信息，容器在这一步着手将配置值设置到 Bean 对应的属性中，不过在设置每个属性之前将先调用InstantiationAwareBeanPostProcessor 接口的postProcessPropertyValues()方法；

5．调用 Bean 的属性设置方法设置属性值；

6．如果 Bean 实现了 org.springframework.beans.factory.BeanNameAware 接口，将调用setBeanName()接口方法，将配置文件中该 Bean 对应的名称设置到 Bean 中；

7．如果 Bean 实现了 org.springframework.beans.factory.BeanFactoryAware 接口，将调用 setBeanFactory()接口方法，将 BeanFactory 容器实例设置到 Bean 中；

8．如果 BeanFactory 装配了 org.springframework.beans.factory.config.BeanPostProcessor后处理器，将调用 BeanPostProcessor 的 Object postProcessBeforeInitialization(Object bean, String beanName)接口方法对 Bean 进行加工操作。其中入参 bean 是当前正在处理的 Bean，而 beanName 是当前 Bean 的配置名，返回的对象为加工处理后的 Bean。用户可以使用该方法对某些 Bean 进行特殊的处理，甚至改变 Bean 的行为， BeanPostProcessor 在 Spring 框架中占有重要的地位，为容器提供对 Bean 进行后续加工处理的切入点， Spring 容器所提供的各种"神奇功能"（如 AOP，动态代理等）都通过 BeanPostProcessor 实施；

9．如果 Bean 实现了 InitializingBean 的接口，将调用接口的 afterPropertiesSet()方法；

10．如果在通过 init-method 属性定义了初始化方法，将执行这个方法；

11．BeanPostProcessor 后处理器定义了两个方法：其一是 postProcessBeforeInitialization() 在第 8 步调用；其二是 Object postProcessAfterInitialization(Object bean, String beanName)方法，这个方法在此时调用，容器再次获得对 Bean 进行加工处理的机会；

12．如果在中指定 Bean 的作用范围为 scope="prototype"，将 Bean 返回给调用者，调用者负责 Bean 后续生命的管理， Spring 不再管理这个 Bean 的生命周期。如果作用范围设置为 scope="singleton"，则将 Bean 放入到 Spring IoC 容器的缓存池中，并将 Bean引用返回给调用者， Spring 继续对这些 Bean 进行后续的生命管理；

13．对于 scope="singleton"的 Bean，当容器关闭时，将触发 Spring 对 Bean 的后续生命周期的管理工作，首先如果 Bean 实现了 DisposableBean 接口，则将调用接口的afterPropertiesSet()方法，可以在此编写释放资源、记录日志等操作；

14．对于 scope="singleton"的 Bean，如果通过的 destroy-method 属性指定了 Bean 的销毁方法， Spring 将执行 Bean 的这个方法，完成 Bean 资源的释放等操作。

可以将这些方法大致划分为三类：

Bean 自身的方法：如调用 Bean 构造函数实例化 Bean，调用 Setter 设置 Bean 的属性值以及通过的 init-method 和 destroy-method 所指定的方法；

Bean 级生命周期接口方法：如 BeanNameAware、 BeanFactoryAware、 InitializingBean 和 DisposableBean，这些接口方法由 Bean 类直接实现；

容器级生命周期接口方法：在上图中带"★" 的步骤是由 InstantiationAwareBean PostProcessor 和BeanPostProcessor 这两个接口实现，一般称它们的实现类为" 后处理器" 。 后处理器接口一般不由 Bean 本身实现，它们独立于 Bean，实现类以容器附加装置的形式注册到 Spring 容器中并通过接口反射为 Spring 容器预先识别。当Spring 容器创建任何 Bean 的时候，这些后处理器都会发生作用，所以这些后处理器的影响是全局性的。当然，用户可以通过合理地编写后处理器，让其仅对感兴趣Bean 进行加工处理

ApplicationContext 和 BeanFactory 另一个最大的不同之处在于：ApplicationContext会利用 Java 反射机制自动识别出配置文件中定义的 BeanPostProcessor、 InstantiationAwareBeanPostProcessor 和 BeanFactoryPostProcessor，并自动将它们注册到应用上下文中；而后者需要在代码中通过手工调用 addBeanPostProcessor()方法进行注册。这也是为什么在应用开发时，我们普遍使用 ApplicationContext 而很少使用 BeanFactory 的原因之一

IOC容器工作机制

容器启动过程

web环境下Spring容器、SpringMVC容器启动过程：

首先，对于一个web应用，其部署在web容器中，web容器提供其一个全局的上下文环境，这个上下文就是ServletContext，其为后面的spring IoC容器提供宿主环境；

其次，在web.xml中会提供有contextLoaderListener（或ContextLoaderServlet）。在web容器启动时，会触发容器初始化事件，此时contextLoaderListener会监听到这个事件，其contextInitialized方法会被调用，在这个方法中，spring会初始化一个启动上下文，这个上下文被称为根上下文，即WebApplicationContext，这是一个接口类，确切的说，其实际的实现类是XmlWebApplicationContext。这个就是spring的IoC容器，其对应的Bean定义的配置由web.xml中的context-param标签指定。在这个IoC容器初始化完毕后，spring容器以WebApplicationContext.ROOTWEBAPPLICATIONCONTEXTATTRIBUTE为属性Key，将其存储到ServletContext中，便于获取；

再次，contextLoaderListener监听器初始化完毕后，开始初始化web.xml中配置的Servlet，这个servlet可以配置多个，以最常见的DispatcherServlet为例（Spring MVC），这个servlet实际上是一个标准的前端控制器，用以转发、匹配、处理每个servlet请求。DispatcherServlet上下文在初始化的时候会建立自己的IoC上下文容器，用以持有spring mvc相关的bean，这个servlet自己持有的上下文默认实现类也是XmlWebApplicationContext。在建立DispatcherServlet自己的IoC上下文时，会利用WebApplicationContext.ROOTWEBAPPLICATIONCONTEXTATTRIBUTE先从ServletContext中获取之前的根上下文(即WebApplicationContext)作为自己上下文的parent上下文（即第2步中初始化的XmlWebApplicationContext作为自己的父容器）。有了这个parent上下文之后，再初始化自己持有的上下文（这个DispatcherServlet初始化自己上下文的工作在其initStrategies方法中可以看到，大概的工作就是初始化处理器映射、视图解析等）。初始化完毕后，spring以与servlet的名字相关(此处不是简单的以servlet名为Key，而是通过一些转换)的属性为属性Key，也将其存到ServletContext中，以便后续使用。这样每个servlet就持有自己的上下文，即拥有自己独立的bean空间，同时各个servlet共享相同的bean，即根上下文定义的那些bean。

Bean加载过程

Spring的高明之处在于，它使用众多接口描绘出了所有装置的蓝图，构建好Spring的骨架，继而通过继承体系层层推演，不断丰富，最终让Spring成为有血有肉的完整的框架。所以查看Spring框架的源码时，有两条清晰可见的脉络：

1）接口层描述了容器的重要组件及组件间的协作关系；

2）继承体系逐步实现组件的各项功能。

接口层清晰地勾勒出Spring框架的高层功能，框架脉络呼之欲出。有了接口层抽象的描述后，不但Spring自己可以提供具体的实现，任何第三方组织也可以提供不同实现， 可以说Spring完善的接口层使框架的扩展性得到了很好的保证。纵向继承体系的逐步扩展，分步骤地实现框架的功能，这种实现方案保证了框架功能不会堆积在某些类的身上，造成过重的代码逻辑负载，框架的复杂度被完美地分解开了。

Spring组件按其所承担的角色可以划分为两类：

1）物料组件：Resource、BeanDefinition、PropertyEditor以及最终的Bean等，它们是加工流程中被加工、被消费的组件，就像流水线上被加工的物料；

BeanDefinition：Spring通过BeanDefinition将配置文件中的配置信息转换为容器的内部表示，并将这些BeanDefinition注册到BeanDefinitionRegistry中。Spring容器的后续操作直接从BeanDefinitionRegistry中读取配置信息。

2）加工设备组件：ResourceLoader、BeanDefinitionReader、BeanFactoryPostProcessor、InstantiationStrategy以及BeanWrapper等组件像是流水线上不同环节的加工设备，对物料组件进行加工处理。

InstantiationStrategy：负责实例化Bean操作，相当于Java语言中new的功能，并不会参与Bean属性的配置工作。属性填充工作留待BeanWrapper完成

BeanWrapper：继承了PropertyAccessor和PropertyEditorRegistry接口，BeanWrapperImpl内部封装了两类组件：（1）被封装的目标Bean（2）一套用于设置Bean属性的属性编辑器；具有三重身份：（1）Bean包裹器（2）属性访问器 （3）属性编辑器注册表。PropertyAccessor：定义了各种访问Bean属性的方法。PropertyEditorRegistry：属性编辑器的注册表

该图描述了Spring容器从加载配置文件到创建出一个完整Bean的作业流程：

１、ResourceLoader从存储介质中加载Spring配置信息，并使用Resource表示这个配置文件的资源；

２、BeanDefinitionReader读取Resource所指向的配置文件资源，然后解析配置文件。配置文件中每一个解析成一个BeanDefinition对象，并保存到BeanDefinitionRegistry中；

３、容器扫描BeanDefinitionRegistry中的BeanDefinition，使用Java的反射机制自动识别出Bean工厂后处理后器（实现BeanFactoryPostProcessor接口）的Bean，然后调用这些Bean工厂后处理器对BeanDefinitionRegistry中的BeanDefinition进行加工处理。主要完成以下两项工作：

1）对使用到占位符的元素标签进行解析，得到最终的配置值，这意味对一些半成品式的BeanDefinition对象进行加工处理并得到成品的BeanDefinition对象；

2）对BeanDefinitionRegistry中的BeanDefinition进行扫描，通过Java反射机制找出所有属性编辑器的Bean（实现java.beans.PropertyEditor接口的Bean），并自动将它们注册到Spring容器的属性编辑器注册表中（PropertyEditorRegistry）；

4．Spring容器从BeanDefinitionRegistry中取出加工后的BeanDefinition，并调用InstantiationStrategy着手进行Bean实例化的工作；

5．在实例化Bean时，Spring容器使用BeanWrapper对Bean进行封装，BeanWrapper提供了很多以Java反射机制操作Bean的方法，它将结合该Bean的BeanDefinition以及容器中属性编辑器，完成Bean属性的设置工作；

6．利用容器中注册的Bean后处理器（实现BeanPostProcessor接口的Bean）对已经完成属性设置工作的Bean进行后续加工，直接装配出一个准备就绪的Bean。

总结

Spring IOC容器主要有继承体系底层的BeanFactory、高层的ApplicationContext和WebApplicationContext

Bean有自己的生命周期

容器启动原理：Spring应用的IOC容器通过tomcat的Servlet或Listener监听启动加载；Spring MVC的容器由DispatchServlet作为入口加载；Spring容器是Spring MVC容器的父容器

容器加载Bean原理：

BeanDefinitionReader读取Resource所指向的配置文件资源，然后解析配置文件。配置文件中每一个解析成一个BeanDefinition对象，并保存到BeanDefinitionRegistry中；

容器扫描BeanDefinitionRegistry中的BeanDefinition；调用InstantiationStrategy进行Bean实例化的工作；使用BeanWrapper完成Bean属性的设置工作；

单例Bean缓存池：Spring 在 DefaultSingletonBeanRegistry 类中提供了一个用于缓存单实例 Bean 的缓存器，它是一个用 HashMap 实现的缓存器，单实例的 Bean 以 beanName 为键保存在这个HashMap 中。

SpringAOP

Spring中AOP源码深入解析

有关AOP相关概念以及Spring AOP相关概念和Spring AOP的使用不再重复。关于AOP在Spring中的地位，不用说相信我们都知道，也都会用，但是对于更深入的东西，还未接触过，这里就对Spring AOP的相关源码进行说明一下，看看到底Spring中AOP是怎么实现的。

有关AOP的概念和Spring AOP相关配置，请参考其他两篇文章：AOP概念，原理，应用介绍 和 Spring中AOP的配置从1.0到5.0的演进

另外，本文使用的源码是Spring1.1.1版本的，之所以使用这么老的版本，是觉得相对来说简单一些，并且无关的东西更少，这样更容易去理解。对于后续版本新增功能可以在此基础上进行对比，理解的效果会更好。

示例程序

首先我们还是先使用一个实例来看一下怎么使用，再从实例中一步一步跟进到源码中。

先定义业务接口和实现：

LoginService：

package me.cxis.spring.aop;

/**
 * Created by cheng.xi on 2017-03-29 12:02.
 */
public interface LoginService {
    String login(String userName);
}

LoginServiceImpl：

package me.cxis.spring.aop;

/**
 * Created by cheng.xi on 2017-03-29 10:36.
 */
public class LoginServiceImpl implements LoginService {

    public String login(String userName){
        System.out.println("正在登录");
        return "success";
    }
}

接着是三个通知类：

//这里只是在登录方法调用之前打印一句话
public class LogBeforeLogin implements MethodBeforeAdvice {
    public void before(Method method, Object[] objects, Object o) throws Throwable {
        System.out.println("有人要登录了。。。");
    }
}

package me.cxis.spring.aop.proxyfactory;
import org.springframework.aop.AfterReturningAdvice;
import org.springframework.aop.MethodBeforeAdvice;
import java.lang.reflect.Method;

/**
 * Created by cheng.xi on 2017-03-29 10:56.
 */
public class LogAfterLogin implements AfterReturningAdvice {

    public void afterReturning(Object o, Method method, Object[] objects, Object o1) throws Throwable {
        System.out.println("有人已经登录了。。。");
    }
}

package me.cxis.spring.aop.proxyfactory;
import org.aopalliance.intercept.MethodInterceptor;
import org.aopalliance.intercept.MethodInvocation;

/**
 * Created by cheng.xi on 2017-03-30 23:36.
 */
public class LogAroundLogin implements MethodInterceptor {
    public Object invoke(MethodInvocation invocation) throws Throwable {
        System.out.println("有人要登录。。。");
        Object result = invocation.proceed();
        System.out.println("登录完了");
        return result;
    }
}

测试方法：

package me.cxis.spring.aop.proxyfactory;
import org.springframework.aop.framework.ProxyFactory;
import org.springframework.context.ApplicationContext;
import org.springframework.context.support.ClassPathXmlApplicationContext;

/**
 * Created by cheng.xi on 2017-03-29 10:34.
 */
public class Main {


    public static void main(String[] args) {
        ProxyFactory proxyFactory = new ProxyFactory();//创建代理工厂
        proxyFactory.setTarget(new LoginServiceImpl());//设置目标对象
        proxyFactory.addAdvice(new LogBeforeLogin());//前置增强
        proxyFactory.addAdvice(new LogAfterLogin());//后置增强
        //proxyFactory.addAdvice(new LogAroundLogin());//环绕增强

        LoginService loginService = (LoginService) proxyFactory.getProxy();//从代理工厂中获取代理
        loginService.login("x");
    }
}

关于实例中要说明的：我们看到在使用的时候，直接获取的是一个代理，不是要使用的实现类，这也很好懂，之前文章都说过AOP其实就是代理模式，在编译期或者运行期，给我们原来的代码增加一些功能，变成一个代理。当我们调用的时候，实际就是调用的代理类。

源码解析

对于源码的解析，我们这里使用的是代码的方式，没有选择xml配置文件的方式。关于xml配置的方式，后面再讲解。

创建AOP代理

首先我们要明白，Spring中实现AOP，就是生成一个代理，然后在使用的时候调用代理。

创建代理工厂

代码中首先创建一个代理工厂实例ProxyFactory proxyFactory = new ProxyFactory();代理工厂的作用就是使用编程的方式创建AOP代理。ProxyFactory继承自AdvisedSupport，AdvicedSupport是AOP代理的配置管理器。

设置目标对象

然后是设置要代理的目标对象proxyFactory.setTarget(new LoginServiceImpl());，看下setTarget方法：

public void setTarget(Object target) {
	//先根据给定的目标实现类，创建一个单例的TargetSource
    //然后设置TargetSource
    setTargetSource(new SingletonTargetSource(target));
}

TargetSource

TargetSource用来获取当前的Target，也就是TargetSource中会保存着我们的的实现类。

public interface TargetSource {

	//返回目标类的类型
	Class getTargetClass();
	
	//查看TargetSource是否是static的
    //静态的TargetSource每次都返回同一个Target
	boolean isStatic();
	
	//获取目标类的实例
	Object getTarget() throws Exception;
	
	//释放目标类
	void releaseTarget(Object target) throws Exception;

}

SingletonTargetSource

TargetSource的默认实现，是一个单例的TargetSource，isStatic方法直接返回true。

public final class SingletonTargetSource implements TargetSource, Serializable {

	//用来保存目标类	
	private final Object target;
	//构造方法
	public SingletonTargetSource(Object target) {
		this.target = target;
	}
	//直接返回目标类的类型
	public Class getTargetClass() {
		return target.getClass();
	}
	//返回目标类
	public Object getTarget() {
		return this.target;
	}
	//释放目标类，这里啥也没做
	public void releaseTarget(Object o) {
		// Nothing to do
	}
	//直接返回true
	public boolean isStatic() {
		return true;
	}

	//equals方法
	public boolean equals(Object other) {
    	//相等，返回true
		if (this == other) {
			return true;
		}
        //不是SingletonTargetSource类型的返回false
		if (!(other instanceof SingletonTargetSource)) {
			return false;
		}
		SingletonTargetSource otherTargetSource = (SingletonTargetSource) other;
        //判断目标类是否相等
		return ObjectUtils.nullSafeEquals(this.target, otherTargetSource.target);
	}
	
	//toString方法
	public String toString() {
		return "SingletonTargetSource: target=(" + target + ")";
	}
}

上面是有关TargetSource和SingletonTargetSource的说明，接着往下一步就是设置目标类setTargetSource方法，在AdvisedSupport类中：

public void setTargetSource(TargetSource targetSource) {
    if (isActive() && getOptimize()) {
        throw new AopConfigException("Can't change target with an optimized CGLIB proxy: it has its own target");
    }
    //么有做什么处理，只是将我们构建的TargetSource缓存起来
    this.targetSource = targetSource;
}

添加通知

上面设置了要代理的目标类之后，接着是添加通知，也就是添加增强类，proxyFactory.addAdvice()方法是添加增强类的方法。我们在例子中是这么使用的：

proxyFactory.addAdvice(new LogBeforeLogin());//前置增强
proxyFactory.addAdvice(new LogAfterLogin());//后置增强
//proxyFactory.addAdvice(new LogAroundLogin());//环绕增强

addAdvice方法的参数是一个Advice类型的类，也就是通知或者叫增强，可以去我们的增强类中查看，我们都继承了各种Advice，比如MethodBeforeAdvice，AfterReturningAdvice，MethodInterceptor，这里先讲一下有关通知Advice的代码，然后再继续说明addAdvice方法。

Advice接口

Advice不属于Spring，是AOP联盟定义的接口。Advice接口并没有定义任何方法，是一个空的接口，用来做标记，实现了此接口的的类是一个通知类。Advice有几个子接口：

• BeforeAdvice，前置增强，意思是在我们的目标类之前调用的增强。这个接口也没有定义任何方法。
• AfterReturningAdvice，方法正常返回前的增强，该增强可以看到方法的返回值，但是不能更改返回值，该接口有一个方法afterReturning
• ThrowsAdvice，抛出异常时候的增强，也是一个标志接口，没有定义任何方法。
• Interceptor，拦截器，也没有定义任何方法，表示一个通用的拦截器。不属于Spring，是AOP联盟定义的接口
• DynamicIntroductionAdvice，动态引介增强，有一个方法implementsInterface。

MethodBeforeAdvice

MethodBeforeAdvice接口，是BeforeAdvice的子接口，表示在方法前调用的增强，方法前置增强不能阻止方法的调用，但是能抛异常来使目标方法不继续执行。

public interface MethodBeforeAdvice extends BeforeAdvice {
	
	//在给定的方法调用前，调用该方法
    //参数method是被代理的方法
    //参数args是被代理方法的参数
    //参数target是方法调用的目标，可能为null
	void before(Method m, Object[] args, Object target) throws Throwable;
}

MethodInterceptor

MethodInterceptor不属于Spring，是AOP联盟定义的接口，是Interceptor的子接口，我们通常叫做环绕增强。

public interface MethodInterceptor extends Interceptor {
	
    //在目标方法调用前后做一些事情
    //返回的是invocation.proceed()方法的返回值
    Object invoke(MethodInvocation invocation) throws Throwable;
}

参数MethodInvocation是一个方法调用的连接点，接下来先看看MethodInvocation相关的代码。

Joinpoint连接点

JointPoint接口，是一个通用的运行时连接点，运行时连接点是在一个静态连接点发生的事件。

public interface Joinpoint {

   //开始调用拦截器链中的下一个拦截器
   Object proceed() throws Throwable;

   //
   Object getThis();

   //
   AccessibleObject getStaticPart();   

}

Invocation接口

Invocation接口是Joinpoint的子接口，表示程序的调用，一个Invocation就是一个连接点，可以被拦截器拦截。

public interface Invocation extends Joinpoint {
   
   //获取参数
   Object[] getArguments();

}

MethodInvocation接口

MethodInvocation接口是Invocation的子接口，用来描述一个方法的调用。

public interface MethodInvocation extends Invocation
{

    //获取被调用的方法
    Method getMethod();

}

另外还有一个ConstructorInvocation接口，也是Invocation的子接口，描述的是构造器的调用。

上面介绍完了Advice的相关定义，接着看往代理工厂中添加增强的addAdvice方法，addAdvice方法在AdvisedSupport类中：

public void addAdvice(Advice advice) throws AopConfigException {
	//advisors是Advice列表，是一个LinkedList
    //如果被添加进来的是一个Interceptor，会先被包装成一个Advice
    //添加之前现获取advisor的大小，当做添加的Advice的位置
    int pos = (this.advisors != null) ? this.advisors.size() : 0;
    //添加Advice
    addAdvice(pos, advice);
}

接着看addAdvice(pos, advice)方法：

public void addAdvice(int pos, Advice advice) throws AopConfigException {
	//只能处理实现了AOP联盟的接口的拦截器
    if (advice instanceof Interceptor && !(advice instanceof MethodInterceptor)) {
        throw new AopConfigException(getClass().getName() + " only handles AOP Alliance MethodInterceptors");
    }
	//IntroductionInfo接口类型，表示引介信息
    if (advice instanceof IntroductionInfo) {
    	//不需要IntroductionAdvisor
        addAdvisor(pos, new DefaultIntroductionAdvisor(advice, (IntroductionInfo) advice));
    }
    //动态引介增强的处理
    else if (advice instanceof DynamicIntroductionAdvice) {
        //需要IntroductionAdvisor
        throw new AopConfigException("DynamicIntroductionAdvice may only be added as part of IntroductionAdvisor");
    }
    else {
    	//添加增强器，需要先把我们的增强包装成增强器，然后添加
        addAdvisor(pos, new DefaultPointcutAdvisor(advice));
    }
}

我们看到添加增强的时候，实际调用添加增强器这个方法，首先需要把我们的Advice包装成一个PointCutAdvisor，然后在添加增强器。这里先了解一下有关PointCutAdvisor的相关信息。

Advisor接口

Advisor，增强器，它持有一个增强Advice，还持有一个过滤器，来决定Advice可以用在哪里。

public interface Advisor {
	
	//判断Advice是不是每个实例中都有
	boolean isPerInstance();
	
	//返回持有的Advice
	Advice getAdvice();

}

PointcutAdvisor

是一个持有Pointcut切点的增强器，PointcutAdvisor现在就会持有一个Advice和一个Pointcut。

public interface PointcutAdvisor extends Advisor {

	//获取Pointcut
	Pointcut getPointcut();

}

Pointcut接口

切入点，定义了哪些连接点需要被织入横切逻辑。可以

public interface Pointcut {
	//类过滤器，可以知道哪些类需要拦截
	ClassFilter getClassFilter();
	//方法匹配器，可以知道哪些方法需要拦截
	MethodMatcher getMethodMatcher();
	
	// could add getFieldMatcher() without breaking most existing code
	Pointcut TRUE = TruePointcut.INSTANCE; 

}

ClassFilter接口

public interface ClassFilter {
	
	//判断给定的类是不是要拦截
	boolean matches(Class clazz);

	ClassFilter TRUE = TrueClassFilter.INSTANCE;

}

MethodMatcher接口

public interface MethodMatcher {
	
	/ 静态方法匹配
	boolean matches(Method m, Class targetClass);
	
	//是否是运行时动态匹配
	boolean isRuntime();
	
	//运行是动态匹配
	boolean matches(Method m, Class targetClass, Object[] args);
	
	MethodMatcher TRUE = TrueMethodMatcher.INSTANCE;

}

看完相关的定义之后，接着看方法new DefaultPointcutAdvisor(advice)，将Advice包装成一个DefaultPointcutAdvisor。其实就是将advice和默认的Pointcut包装进DefaultPointcutAdvisor。

DefaultPointcutAdvisor是Advisor的最常用的一个实现，可以使用任意类型的Pointcut和Advice，但是不能使用Introduction。

构造完成了DefaultPointcutAdvisor只有，接着就是添加增强器方法addAdvisor：

public void addAdvisor(int pos, Advisor advisor) throws AopConfigException {
	//引介增强器处理
    if (advisor instanceof IntroductionAdvisor) {
        addAdvisor(pos, (IntroductionAdvisor) advisor);
    }
    else {
    	//其他的增强器处理
        addAdvisorInternal(pos, advisor);
    }
}

首先看下非引介增强器的添加方法addAdvisorInternal：

private void addAdvisorInternal(int pos, Advisor advice) throws AopConfigException {
    if (isFrozen()) {
        throw new AopConfigException("Cannot add advisor: config is frozen");
    }
    //把Advice添加到LinkedList中指定位置
    this.advisors.add(pos, advice);
    //同时更新一下Advisors数组
    updateAdvisorArray();
    //通知监听器
    adviceChanged();
}

然后看下关于引介增强器的添加addAdvisor，我们知道引介就是对目标类增加新的接口，所以引介增强，也就是对接口的处理：

public void addAdvisor(int pos, IntroductionAdvisor advisor) throws AopConfigException {
	//对接口进行校验
    advisor.validateInterfaces();

    // 遍历要添加的接口，添加
    for (int i = 0; i < advisor.getInterfaces().length; i++) {
    	//就是添加到interfaces集合中，interfaces是一个HashSet
        addInterface(advisor.getInterfaces()[i]);
    }
    //然后添加到advisors中
    addAdvisorInternal(pos, advisor);
}

对于添加增强的步骤，就是把我们的增强器添加进代理工厂中，保存在一个LinkedList中，顺序是添加进来的顺序。

获取代理

到目前为止，我们看到的都还是在组装代理工厂，并没有看到代理的生成，接下来proxyFactory.getProxy()这一步就是获取代理的过程，我们继续看ProxyFactory的getProxy方法：

public Object getProxy() {
	//创建一个AOP代理
    AopProxy proxy = createAopProxy();
    //返回代理
    return proxy.getProxy();
}

我们知道一般创建代理会有两种方式，一种是JDK动态代理，另外一种是CGLIB动态代理，而这里的创建AOP代理就是生成这两种代理中的一种。先看createAopProxy()方法，在AdvisedSupport类中：

protected synchronized AopProxy createAopProxy() {
    if (!this.isActive) {
        activate();
    }
    //获取AOP代理工厂，然后创建代理
    return getAopProxyFactory().createAopProxy(this);
}

获取代理工厂这一步，这里就是默认获取一个DefaultAopProxyFactory实例，然后调用createAopProxy创建AOP代理：

public AopProxy createAopProxy(AdvisedSupport advisedSupport) throws AopConfigException {
	//对于指定了使用CGLIB方式，或者代理的是类，或者代理的不是接口，就使用CGLIB的方式来创建代理
    boolean useCglib = advisedSupport.getOptimize() || advisedSupport.getProxyTargetClass() || advisedSupport.getProxiedInterfaces().length == 0;
    if (useCglib) {
        return CglibProxyFactory.createCglibProxy(advisedSupport);
    }
    else {
        //使用JDK动态代理来创建代理
        return new JdkDynamicAopProxy(advisedSupport);
    }
}

获取完AOP代理之后返回，然后就是调用getProxy方法获取代理，这里分为CGLIB的获取方式和JDK动态代理的获取方式两种。

JDK动态代理方式获取代理

JDK动态代理方式获取代理，实现在JdkDynamicAopProxy中：

public Object getProxy() {
    return getProxy(Thread.currentThread().getContextClassLoader());
}

public Object getProxy(ClassLoader cl) {
	//JDK动态代理只能代理接口类型，先获取接口
    //就是从AdvisedSupport中获取保存在interfaces中的接口
    Class[] proxiedInterfaces = AopProxyUtils.completeProxiedInterfaces(this.advisedSupport);
    //使用Java的反射机制创建一个代理实例
    return Proxy.newProxyInstance(cl, proxiedInterfaces, this);
}

关于JDK反射创建代理之类的，这里不做解析。

CGLIB方式获取代理

CGLIB获取方式，实现在Cglib2AopProxy中：

public Object getProxy() {
	//使用CGLIB的方式来获取，CGLIB这里不做解析
    return getProxy(Thread.currentThread().getContextClassLoader());
}

使用代理

上面获取代理之后，就剩最后一步，使用，当我们调用业务方法的时候，实际上是调用代理中的方法，对于CGLIB生成的代理，调用的是DynamicAdvisedInterceptor的intercept方法；JDK动态代理生成的代理是调用invoke方法。

JDK动态代理

看下JDK动态代理的方式，对于方法的调用，实际上调用的是代理类的invoke方法，在JdkDynamicAopProxy中：

public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
    MethodInvocation invocation = null;
    Object oldProxy = null;
    boolean setProxyContext = false;
	//代理的目标对象
    TargetSource targetSource = advisedSupport.targetSource;
    Class targetClass = null;
    Object target = null;		

    try {
        //equals方法
        if (method.getDeclaringClass() == Object.class && "equals".equals(method.getName())) {
            return equals(args[0]) ? Boolean.TRUE : Boolean.FALSE;
        }
        else if (Advised.class == method.getDeclaringClass()) {
            //？？？
            return AopProxyUtils.invokeJoinpointUsingReflection(this.advisedSupport, method, args);
        }

        Object retVal = null;

        //代理目标对象
        target = targetSource.getTarget();
        if (target != null) {
            targetClass = target.getClass();
        }
		//？？？
        if (this.advisedSupport.exposeProxy) {
            // Make invocation available if necessary
            oldProxy = AopContext.setCurrentProxy(proxy);
            setProxyContext = true;
        }

        //获取配置的通知Advicelian
        List chain = this.advisedSupport.advisorChainFactory.getInterceptorsAndDynamicInterceptionAdvice(
                this.advisedSupport, proxy, method, targetClass);

        //没有配置通知
        if (chain.isEmpty()) {
            //直接调用目标对象的方法
            retVal = AopProxyUtils.invokeJoinpointUsingReflection(target, method, args);
        }
        else {
            //配置了通知，创建一个MethodInvocation
            invocation = new ReflectiveMethodInvocation(proxy, target,
                                method, args, targetClass, chain);

            //执行通知链，沿着通知器链调用所有的通知
            retVal = invocation.proceed();
        }

        //返回值
        if (retVal != null && retVal == target) {
            //返回值为自己
            retVal = proxy;
        }
        //返回
        return retVal;
    }
    finally {
        if (target != null && !targetSource.isStatic()) {
            targetSource.releaseTarget(target);
        }

        if (setProxyContext) {
            AopContext.setCurrentProxy(oldProxy);
        }
    }
}

CGLIB动态代理

CGLIB的是调用DynamicAdvisedInterceptor的intercept方法对目标对象进行处理，具体暂先不解析。

使用ProxyFactoryBean创建AOP代理

ProxyFactoryBean对Pointcut和Advice提供了完全的控制，还包括应用的顺序。ProxyFactoryBean的getObject方法会返回一个AOP代理，包装了目标对象。

Spring在初始化的过程中，createBean的时候，如果是FactoryBean的话，会调用((BeanFactoryAware)bean).setBeanFactory(this);：

public void setBeanFactory(BeanFactory beanFactory) throws BeansException {
    this.beanFactory = beanFactory;
    //创建通知器链
    this.createAdvisorChain();
    if(this.singleton) {
    	//刷新目标对象
        this.targetSource = this.freshTargetSource();
        //获取单例实例
        this.getSingletonInstance();
        this.addListener(this);
    }

}

看下获取单例实例的方法：

private Object getSingletonInstance() {
    if(this.singletonInstance == null) {
        this.singletonInstance = this.createAopProxy().getProxy();
    }

    return this.singletonInstance;
}

createAopProxy方法在AdvisedSupport类中，下面创建的流程跟上面解析的都一样了。

SpringMVC

【Spring】Spring MVC原理及配置

1.Spring MVC概述：

Spring MVC是Spring提供的一个强大而灵活的web框架。借助于注解，Spring MVC提供了几乎是POJO的开发模式，使得控制器的开发和测试更加简单。这些控制器一般不直接处理请求，而是将其委托给Spring上下文中的其他bean，通过Spring的依赖注入功能，这些bean被注入到控制器中。

Spring MVC主要由DispatcherServlet、处理器映射、处理器(控制器)、视图解析器、视图组成。他的两个核心是两个核心：

处理器映射：选择使用哪个控制器来处理请求

视图解析器：选择结果应该如何渲染

通过以上两点，Spring MVC保证了如何选择控制处理请求和如何选择视图展现输出之间的松耦合。

2.SpringMVC运行原理

(1) Http请求：客户端请求提交到DispatcherServlet。

(2) 寻找处理器：由DispatcherServlet控制器查询一个或多个HandlerMapping，找到处理请求的Controller。

(3) 调用处理器：DispatcherServlet将请求提交到Controller。

(4)(5)调用业务处理和返回结果：Controller调用业务逻辑处理后，返回ModelAndView。

(6)(7)处理视图映射并返回模型： DispatcherServlet查询一个或多个ViewResoler视图解析器，找到ModelAndView指定的视图。

(8) Http响应：视图负责将结果显示到客户端。

3.SpringMVC接口解释

（1）DispatcherServlet接口：

Spring提供的前端控制器，所有的请求都有经过它来统一分发。在DispatcherServlet将请求分发给Spring Controller之前，需要借助于Spring提供的HandlerMapping定位到具体的Controller。

（2）HandlerMapping接口：

能够完成客户请求到Controller映射。

（3）Controller接口：

需要为并发用户处理上述请求，因此实现Controller接口时，必须保证线程安全并且可重用。

Controller将处理用户请求，这和Struts Action扮演的角色是一致的。一旦Controller处理完用户请求，则返回ModelAndView对象给DispatcherServlet前端控制器，ModelAndView中包含了模型（Model）和视图（View）。

从宏观角度考虑，DispatcherServlet是整个Web应用的控制器；从微观考虑，Controller是单个Http请求处理过程中的控制器，而ModelAndView是Http请求过程中返回的模型（Model）和视图（View）。

（4）ViewResolver接口：

Spring提供的视图解析器（ViewResolver）在Web应用中查找View对象，从而将相应结果渲染给客户。

4.DispatcherServlet：

是整个Spring MVC的核心。它负责接收HTTP请求组织协调Spring MVC的各个组成部分。其主要工作有以下三项：

（1）截获符合特定格式的URL请求。

（2）初始化DispatcherServlet上下文对应WebApplicationContext，并将其与业务层、持久化层的WebApplicationContext建立关联。

（3）初始化Spring MVC的各个组成组件，并装配到DispatcherServlet中。

5. SpringMVC配置

项目整体结构如下：

（1）在web.xml文件中进行配置，在配置中设置springmvc-context.xml的路径，代码如下：

<servlet>
        <servlet-name>appServlet</servlet-name>
        <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
        <init-param>
            <param-name>contextConfigLocation</param-name>
            <param-value>classpath:META-INF/spring/springmvc-context.xml</param-value>
        </init-param>
        <load-on-startup>1</load-on-startup>
    </servlet>
    <servlet-mapping>
        <servlet-name>appServlet</servlet-name>
        <url-pattern>/</url-pattern>
    </servlet-mapping>

（2）配置springmvc-context.xml文件，这一部分主要是开启注解功能、配置试图解析器，代码如下：

<?xml version="1.0" encoding="UTF-8"?>
<beans:beans xmlns:beans="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:context="http://www.springframework.org/schema/context"
    xmlns:mvc="http://www.springframework.org/schema/mvc" xmlns:p="http://www.springframework.org/schema/p"
    xsi:schemaLocation="http://www.springframework.org/schema/mvc http://www.springframework.org/schema/mvc/spring-mvc-3.0.xsd
        http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
        http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-3.0.xsd ">
    <mvc:annotation-driven />
    <!-- ①：对web包中的所有类进行扫描，以完成Bean创建和自动依赖注入的功能 -->
    <context:component-scan base-package="com.zjn" />

    <!-- 这两个类用来启动基于Spring MVC的注解功能，将控制器与方法映射加入到容器中 -->
    <beans:bean
        class="org.springframework.web.servlet.mvc.annotation.DefaultAnnotationHandlerMapping" />
    <beans:bean
        class="org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerAdapter" />

    <!-- 这个类用于Spring MVC视图解析 -->
    <beans:bean id="viewResolver"
        class="org.springframework.web.servlet.view.InternalResourceViewResolver">
        <beans:property name="prefix" value="/WEB-INF/pages/" />
        <beans:property name="suffix" value=".jsp" />
    </beans:bean>

</beans:beans>

（3）配置文件完成了，下面开始写代码，

两个jsp界面：

create.jsp

<%@ page language="java" contentType="text/html; charset=UTF-8"
    pageEncoding="UTF-8"%>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>Add User From</title>
</head>
<body>
    <form action="save" method="post">
        <fieldset>
        <legend>创建用户</legend>
            <p>
                <label>姓名：</label> <input type="text" id="name" name="name"
                    tabindex="1">
            </p>
            <p>
                <label>年龄：</label> <input type="text" id="age" name="age"
                    tabindex="2">
            </p>
            <p>
                <label>密码：</label> <input type="text" id="pwd" name="pwd"
                    tabindex="3">
            </p>
            <p id="buttons">
                <input id="reset" type="reset" tabindex="4" value="取消"> <input
                    id="submit" type="submit" tabindex="5" value="创建">
            </p>
        </fieldset>
    </form>
</body>
</html>

detail.jsp

<%@ page language="java" contentType="text/html; charset=UTF-8"
    pageEncoding="UTF-8"%>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>Insert title here</title>
</head>
<body>
    <div id="gloobal">
        <h4>创建成功</h4>
        <p>
        <h5>详情：</h5>
        姓名：${user.name}<br /> 年龄：${user.age}<br /> 密码：${user.pwd}<br />
        </p>
    </div>
</body>
</html>

UserController.java

package com.zjn.controller;

import org.springframework.stereotype.Controller;
import org.springframework.ui.Model;
import org.springframework.web.bind.annotation.ModelAttribute;
import org.springframework.web.bind.annotation.RequestMapping;

import com.zjn.entity.User;

/**
 * 用户管理
 * 
 * @author zjn
 */
@Controller
public class UserController {

    @RequestMapping("")
    public String Create(Model model) {
        return "create";
    }

    @RequestMapping("/save")
    public String Save(@ModelAttribute("form") User user, Model model) { // user:视图层传给控制层的表单对象；model：控制层返回给视图层的对象
        model.addAttribute("user", user);
        return "detail";
    }
}

User.java

package com.zjn.entity;

import java.io.Serializable;
import java.util.Date;

public class User implements Serializable {
    /**
     * @author zjn
     */
    private static final long serialVersionUID = 1L;
    private Integer id; // id
    private String name; // name
    private String pwd; // pwd
    private Integer age; // age
    private Date creatTime; // creatTime

    public Integer getId() {
        return id;
    }

    public void setId(Integer id) {
        this.id = id;
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public String getPwd() {
        return pwd;
    }

    public void setPwd(String pwd) {
        this.pwd = pwd;
    }

    public Integer getAge() {
        return age;
    }

    public void setAge(Integer age) {
        this.age = age;
    }

    public Date getCreatTime() {
        return creatTime;
    }

    public void setCreatTime(Date creatTime) {
        this.creatTime = creatTime;
    }

}

(4)运行结果

初始页面：

输入参数：

点击创建：

SpringMVC源码分析系列:

SpringMVC源码解析(1)-启动过程
SpringMVC源码解析(2)-DispatcherServlet
SpringMVC源码解析(3)-HandleMapping
SpringMVC源码解析(4)-HandlerAdapter
SpringMVC源码解析(5)-HandlerExceptionResolver
SpringMVC源码解析(6)-异步请求

Spring中运用了那些设计模式

spring中常用的设计模式达到九种，我们举例说明：

第一种：简单工厂

又叫做静态工厂方法（StaticFactory Method）模式，但不属于23种GOF设计模式之一。

简单工厂模式的实质是由一个工厂类根据传入的参数，动态决定应该创建哪一个产品类。

spring中的BeanFactory就是简单工厂模式的体现，根据传入一个唯一的标识来获得bean对象，但是否是在传入参数后创建还是传入参数前创建这个要根据具体情况来定。如下配置，就是在 HelloItxxz 类中创建一个 itxxzBean。

<beans>
    <bean id="singletonBean" class="com.itxxz.HelloItxxz">
        <constructor-arg>
            <value>Hello! 这是singletonBean!value>
        </constructor-arg>
   </ bean>
 
    <bean id="itxxzBean" class="com.itxxz.HelloItxxz"
        singleton="false">
        <constructor-arg>
            <value>Hello! 这是itxxzBean! value>
        </constructor-arg>
    </bean>
 
</beans>

第二种：工厂方法（Factory Method）

通常由应用程序直接使用new创建新的对象，为了将对象的创建和使用相分离，采用工厂模式,即应用程序将对象的创建及初始化职责交给工厂对象。

一般情况下,应用程序有自己的工厂对象来创建bean.如果将应用程序自己的工厂对象交给Spring管理,那么Spring管理的就不是普通的bean,而是工厂Bean。

螃蟹就以工厂方法中的静态方法为例讲解一下：

import java.util.Random;
public class StaticFactoryBean {
      public static Integer createRandom() {
           return new Integer(new Random().nextInt());
       }
}

建一个config.xm配置文件，将其纳入Spring容器来管理,需要通过factory-method指定静态方法名称

<bean id="random"
class="example.chapter3.StaticFactoryBean" factory-method="createRandom" //createRandom方法必须是static的,才能找到 scope="prototype"
/>

测试:

public static void main(String[] args) {
      //调用getBean()时,返回随机数.如果没有指定factory-method,会返回StaticFactoryBean的实例,即返回工厂Bean的实例       XmlBeanFactory factory = new XmlBeanFactory(new ClassPathResource("config.xml"));       System.out.println("我是IT学习者创建的实例:"+factory.getBean("random").toString());
}

第三种：单例模式（Singleton）

保证一个类仅有一个实例，并提供一个访问它的全局访问点。

spring中的单例模式完成了后半句话，即提供了全局的访问点BeanFactory。但没有从构造器级别去控制单例，这是因为spring管理的是是任意的java对象。

核心提示点：Spring下默认的bean均为singleton，可以通过singleton="true|false" 或者 scope="？"来指定

第四种：适配器（Adapter）

在Spring的Aop中，使用的Advice（通知）来增强被代理类的功能。Spring实现这一AOP功能的原理就使用代理模式（1、JDK动态代理。2、CGLib字节码生成技术代理。）对类进行方法级别的切面增强，即，生成被代理类的代理类， 并在代理类的方法前，设置拦截器，通过执行拦截器重的内容增强了代理方法的功能，实现的面向切面编程。

Adapter类接口：Target

public interface AdvisorAdapter {
 
boolean supportsAdvice(Advice advice);
 
      MethodInterceptor getInterceptor(Advisor advisor);
 
} 

MethodBeforeAdviceAdapter类，Adapter

class MethodBeforeAdviceAdapter implements AdvisorAdapter, Serializable {
 
      public boolean supportsAdvice(Advice advice) {
            return (advice instanceof MethodBeforeAdvice);
      }
 
      public MethodInterceptor getInterceptor(Advisor advisor) {
            MethodBeforeAdvice advice = (MethodBeforeAdvice) advisor.getAdvice();
      return new MethodBeforeAdviceInterceptor(advice);
      }
 
}

第五种：包装器（Decorator）

在我们的项目中遇到这样一个问题：我们的项目需要连接多个数据库，而且不同的客户在每次访问中根据需要会去访问不同的数据库。我们以往在spring和hibernate框架中总是配置一个数据源，因而sessionFactory的dataSource属性总是指向这个数据源并且恒定不变，所有DAO在使用sessionFactory的时候都是通过这个数据源访问数据库。但是现在，由于项目的需要，我们的DAO在访问sessionFactory的时候都不得不在多个数据源中不断切换，问题就出现了：如何让sessionFactory在执行数据持久化的时候，根据客户的需求能够动态切换不同的数据源？我们能不能在spring的框架下通过少量修改得到解决？是否有什么设计模式可以利用呢？

首先想到在spring的applicationContext中配置所有的dataSource。这些dataSource可能是各种不同类型的，比如不同的数据库：Oracle、SQL Server、MySQL等，也可能是不同的数据源：比如apache 提供的org.apache.commons.dbcp.BasicDataSource、spring提供的org.springframework.jndi.JndiObjectFactoryBean等。然后sessionFactory根据客户的每次请求，将dataSource属性设置成不同的数据源，以到达切换数据源的目的。

spring中用到的包装器模式在类名上有两种表现：一种是类名中含有Wrapper，另一种是类名中含有Decorator。基本上都是动态地给一个对象添加一些额外的职责。

第六种：代理（Proxy）

为其他对象提供一种代理以控制对这个对象的访问。 从结构上来看和Decorator模式类似，但Proxy是控制，更像是一种对功能的限制，而Decorator是增加职责。

spring的Proxy模式在aop中有体现，比如JdkDynamicAopProxy和Cglib2AopProxy。

第七种：观察者（Observer）

定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。

spring中Observer模式常用的地方是listener的实现。如ApplicationListener。

第八种：策略（Strategy）

定义一系列的算法，把它们一个个封装起来，并且使它们可相互替换。本模式使得算法可独立于使用它的客户而变化。

spring中在实例化对象的时候用到Strategy模式

在SimpleInstantiationStrategy中有如下代码说明了策略模式的使用情况：

第九种：模板方法（Template Method）

定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。Template Method使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。

Template Method模式一般是需要继承的。这里想要探讨另一种对Template Method的理解。spring中的JdbcTemplate，在用这个类时并不想去继承这个类，因为这个类的方法太多，但是我们还是想用到JdbcTemplate已有的稳定的、公用的数据库连接，那么我们怎么办呢？我们可以把变化的东西抽出来作为一个参数传入JdbcTemplate的方法中。但是变化的东西是一段代码，而且这段代码会用到JdbcTemplate中的变量。怎么办？那我们就用回调对象吧。在这个回调对象中定义一个操纵JdbcTemplate中变量的方法，我们去实现这个方法，就把变化的东西集中到这里了。然后我们再传入这个回调对象到JdbcTemplate，从而完成了调用。这可能是Template Method不需要继承的另一种实现方式吧。

以下是一个具体的例子：

JdbcTemplate中的execute方法

JdbcTemplate执行execute方法

Spring中的Bean是线程安全的吗

Spring单例不是线程安全的。Spring通过ThreadLocal实现单例bean的线程安全

Spring容器中的bean默认是单例模式。当多个客户端同时请求一个服务时，容器会给每一个请求分配一个线程。这些线程会并发执行该请求对应的业务处理逻辑（成员方法），如果该处理逻辑中有对该单例bean状态的修改（体现为该单例bean的成员属性），则需要考虑线程同步问题。

Spring使用ThreadLocal解决线程安全问题。一般情况下，只有无状态的Bean才可以在多线程环境下共享。Spring对一些Bean（如RequestContextHolder、TransactionSynchronizationManager、LocaleContextHolder等）中"非线程安全状态"，采用ThreadLocal进行处理，让它们也成为线程安全的状态，因此有状态的Bean也可以在多线程中共享了。

ThreadLocal和线程同步机制（synchronized）都可以解决多线程中"相同变量"的访问冲突问题。

线程同步机制（synchronized）通过"对象锁"，保证同一时间只有一个线程访问变量，让不同的线程排队访问。这时该变量是多个线程共享的，使用同步机制要求程序慎密地分析什么时候对变量进行读写，什么时候需要锁定某个对象，什么时候释放对象锁等繁杂的问题，程序设计和编写难度相对较大。

ThreadLocal会为每一个线程提供一个独立的"变量副本"，从而隔离了多个线程对数据的访问冲突。因为每一个线程都拥有自己的变量副本，从而也就没有必要对该变量进行同步了。ThreadLocal提供了线程安全的共享对象，在编写多线程代码时，可以把不安全的变量封装进ThreadLocal。

如果某一进程中有多个线程在同时运行，而这些线程又同时运行某段代码。假如每次运行结果和单线程运行的结果是一样的，而且其他变量的值也和预期的是一样的，就是线程安全的。如果一个类所提供的方法，对于线程来说是原子操作，或者多个线程之间的切换不会导致该接口的执行结果存在二义性，那么便不用考虑同步的问题。

线程安全问题都是由全局变量及静态变量引起的。若每个线程中对全局变量、静态变量只有读操作，而无写操作，这个全局变量是线程安全的。若有多个线程同时执行写操作，则需要考虑线程同步，否则就可能影响线程安全。

① 常量始终是线程安全的，因为只存在读操作。

② 每次调用方法前都新建一个实例是线程安全的，因为不会访问共享的资源。

③ 局部变量是线程安全的。因为每执行一个方法，都会在独立的空间创建局部变量，它不是共享的资源。局部变量包括方法的参数变量和方法内变量。

有状态就是有数据存储功能。有状态对象(Stateful Bean)，就是有实例变量的对象，可以保存数据，是非线程安全的。在不同方法调用间不保留任何状态。

无状态就是一次操作，不能保存数据。无状态对象(Stateless Bean)，就是没有实例变量的对象，不能保存数据，是不变类，是线程安全的。

Spring中的Bean的作用域

singleton : bean在每个Spring ioc 容器中只有一个实例。

prototype：一个bean的定义可以有多个实例。

request：每次http请求都会创建一个bean，该作用域仅在基于web的Spring ApplicationContext情形下有效。

session：在一个HTTP Session中，一个bean定义对应一个实例。该作用域仅在基于web的Spring ApplicationContext情形下有效。

global-session：在一个全局的HTTP Session中，一个bean定义对应一个实例。该作用域仅在基于web的Spring ApplicationContext情形下有效。

缺省的Spring bean 的作用域是Singleton

Spring中的Bean的生命周期

简单来说如下：
Bean的建立

由BeanFactory读取Bean定义文件，并生成各个实例。

Setter注入

执行Bean的属性依赖注入。

BeanNameAware的setBeanName()

如果Bean类实现了org.springframework.beans.factory.BeanNameAware接口，则执行其setBeanName()方法。

BeanFactoryAware的setBeanFactory()

如果Bean类实现了org.springframework.beans.factory.BeanFactoryAware接口，则执行其setBeanFactory()方法。

BeanPostProcessors的processBeforeInitialization()

容器中如果有实现org.springframework.beans.factory.BeanPostProcessors接口的实例，则任何Bean在初始化之前都会执行这个实例的processBeforeInitialization()方法。

InitializingBean的afterPropertiesSet()

如果Bean类实现了org.springframework.beans.factory.InitializingBean接口，则执行其afterPropertiesSet()方法。

Bean定义文件中定义init-method时会执行initMethod()方法，注意，这个方法是不带参数的。

BeanPostProcessors的processAfterInitialization()

容器中如果有实现org.springframework.beans.factory.BeanPostProcessors接口的实例，则任何Bean在初始化之前都会执行这个实例的processAfterInitialization()方法。

DisposableBean的destroy()

在容器关闭时，如果Bean类实现了org.springframework.beans.factory.DisposableBean接口，则执行它的destroy()方法。

Bean定义文件中定义destroy-method在容器关闭时，可以在Bean定义文件中使用"destory-method"定义的方法。

详细：
Spring学习10- bean的生命周期(阿里面试题目两次面试均提到)

找工作的时候有些人会被问道Spring中Bean的生命周期，其实也就是考察一下对Spring是否熟悉，工作中很少用到其中的内容，那我们简单看一下。

在说明前可以思考一下Servlet的生命周期：实例化，初始init，接收请求service，销毁destroy；

可以参考博文：Servlet 生命周期、工作原理

Spring上下文中的Bean也类似，如下

1、实例化一个Bean－－也就是我们常说的new；

2、按照Spring上下文对实例化的Bean进行配置－－也就是IOC注入；

3、如果这个Bean已经实现了BeanNameAware接口，会调用它实现的setBeanName(String)方法，此处传递的就是Spring配置文件中Bean的id值

4、如果这个Bean已经实现了BeanFactoryAware接口，会调用它实现的setBeanFactory(setBeanFactory(BeanFactory)传递的是Spring工厂自身（可以用这个方式来获取其它Bean，只需在Spring配置文件中配置一个普通的Bean就可以）；

5、如果这个Bean已经实现了ApplicationContextAware接口，会调用setApplicationContext(ApplicationContext)方法，传入Spring上下文（同样这个方式也可以实现步骤4的内容，但比4更好，因为ApplicationContext是BeanFactory的子接口，有更多的实现方法); 

6、如果这个Bean关联了BeanPostProcessor接口，将会调用postProcessBeforeInitialization(Object obj, String s)方法，BeanPostProcessor经常被用作是Bean内容的更改，并且由于这个是在Bean初始化结束时调用那个的方法，也可以被应用于内存或缓存技术；(阿里面试官问BeanPostProcessor是做什么用的)

7、如果Bean在Spring配置文件中配置了init-method属性会自动调用其配置的初始化方法。

8、如果这个Bean关联了BeanPostProcessor接口，将会调用postProcessAfterInitialization(Object obj, String s)方法、；

注：以上工作完成以后就可以应用这个Bean了，那这个Bean是一个Singleton的，所以一般情况下我们调用同一个id的Bean会是在内容地址相同的实例，当然在Spring配置文件中也可以配置非Singleton，这里我们不做赘述。

9、当Bean不再需要时，会经过清理阶段，如果Bean实现了DisposableBean这个接口，会调用那个其实现的destroy()方法；

10、最后，如果这个Bean的Spring配置中配置了destroy-method属性，会自动调用其配置的销毁方法。 

以上10步骤可以作为面试或者笔试的模板，另外我们这里描述的是应用Spring上下文Bean的生命周期，如果应用Spring的工厂也就是BeanFactory的话去掉第5步就Ok了。

Spring 中bean 的生命周期短暂吗?

在spring中，从BeanFactory或ApplicationContext取得的实例为Singleton，也就是预设为每一个Bean的别名只能维持一个实例，而不是每次都产生一个新的对象使用Singleton模式产生单一实例，对单线程的程序说并不会有什么问题，但对于多线程的程序，就必须注意安全(Thread-safe)的议题，防止多个线程同时存取共享资源所引发的数据不同步问题。

然而在spring中 可以设定每次从BeanFactory或ApplicationContext指定别名并取得Bean时都产生一个新的实例：例如：

在spring中，singleton属性默认是true，只有设定为false，则每次指定别名取得的Bean时都会产生一个新的实例

一个Bean从创建到销毁，如果是用BeanFactory来生成,管理Bean的话，会经历几个执行阶段(如图1.1)：

1：Bean的建立：

容器寻找Bean的定义信息并将其实例化。

2：属性注入：

使用依赖注入，Spring按照Bean定义信息配置Bean所有属性

3：BeanNameAware的setBeanName()：

如果Bean类有实现org.springframework.beans.BeanNameAware接口，工厂调用Bean的setBeanName()方法传递Bean的ID。

4：BeanFactoryAware的setBeanFactory()：

如果Bean类有实现org.springframework.beans.factory.BeanFactoryAware接口，工厂调用setBeanFactory()方法传入工厂自身。

5：BeanPostProcessors的ProcessBeforeInitialization()

如果有org.springframework.beans.factory.config.BeanPostProcessors和Bean关联，那么其postProcessBeforeInitialization()方法将被将被调用。

6：initializingBean的afterPropertiesSet()：

如果Bean类已实现org.springframework.beans.factory.InitializingBean接口，则执行他的afterProPertiesSet()方法

7：Bean定义文件中定义init-method：

可以在Bean定义文件中使用"init-method"属性设定方法名称例如：

如果有以上设置的话，则执行到这个阶段，就会执行initBean()方法

8：BeanPostProcessors的ProcessaAfterInitialization()

如果有任何的BeanPostProcessors实例与Bean实例关联，则执行BeanPostProcessors实例的ProcessaAfterInitialization()方法

此时，Bean已经可以被应用系统使用，并且将保留在BeanFactory中直到它不在被使用。有两种方法可以将其从BeanFactory中删除掉(如图1.2):

1：DisposableBean的destroy()

在容器关闭时，如果Bean类有实现org.springframework.beans.factory.DisposableBean接口，则执行他的destroy()方法

2：Bean定义文件中定义destroy-method

在容器关闭时，可以在Bean定义文件中使用"destroy-method"属性设定方法名称，例如：

如果有以上设定的话，则进行至这个阶段时，就会执行destroy()方法，如果是使用ApplicationContext来生成并管理Bean的话则稍有不同，使用ApplicationContext来生成及管理Bean实例的话，在执行BeanFactoryAware的setBeanFactory()阶段后，若Bean类上有实现org.springframework.context.ApplicationContextAware接口，则执行其setApplicationContext()方法，接着才执行BeanPostProcessors的ProcessBeforeInitialization()及之后的流程。

Spring事务的传播行为

事务知识点总结参考：https://blog.csdn.net/longzhutengyue/article/details/95754184

Spring事务默认抛出什么异常斜体样式

Mybatis

Mybatis源码解析

深入浅出Mybatis系列（十）---SQL执行流程分析（源码篇）

1. SqlSessionFactory 与 SqlSession

通过前面的章节对于mybatis 的介绍及使用，大家都能体会到SqlSession的重要性了吧， 没错，从表面上来看，咱们都是通过SqlSession去执行sql语句（注意：是从表面看，实际的待会儿就会讲）。那么咱们就先看看是怎么获取SqlSession的吧：

(1) 构建SqlSessionFactory

首先，SqlSessionFactoryBuilder去读取mybatis的配置文件，然后build一个DefaultSqlSessionFactory。源码如下：

/**
 * 一系列的构造方法最终都会调用本方法（配置文件为Reader时会调用本方法，还有一个InputStream方法与此对应）
 * @param reader
 * @param environment
 * @param properties
 * @return
 */
public SqlSessionFactory build(Reader reader, String environment, Properties properties) {
  try {
    //通过XMLConfigBuilder解析配置文件，解析的配置相关信息都会封装为一个Configuration对象
    XMLConfigBuilder parser = new XMLConfigBuilder(reader, environment, properties);
    //这儿创建DefaultSessionFactory对象
    return build(parser.parse());
  } catch (Exception e) {
    throw ExceptionFactory.wrapException("Error building SqlSession.", e);
  } finally {
    ErrorContext.instance().reset();
    try {
      reader.close();
    } catch (IOException e) {
      // Intentionally ignore. Prefer previous error.
    }
  }
}

public SqlSessionFactory build(Configuration config) {
  return new DefaultSqlSessionFactory(config);
}

(2) 获取SqlSession对象

当我们获取到SqlSessionFactory之后，就可以通过SqlSessionFactory去获取SqlSession对象。源码如下：

/**
 * 通常一系列openSession方法最终都会调用本方法
 * @param execType 
 * @param level
 * @param autoCommit
 * @return
 */
private SqlSession openSessionFromDataSource(ExecutorType execType, TransactionIsolationLevel level, boolean autoCommit) {
  Transaction tx = null;
  try {
    //通过Confuguration对象去获取Mybatis相关配置信息, Environment对象包含了数据源和事务的配置
    final Environment environment = configuration.getEnvironment();
    final TransactionFactory transactionFactory = getTransactionFactoryFromEnvironment(environment);
    tx = transactionFactory.newTransaction(environment.getDataSource(), level, autoCommit);
    //之前说了，从表面上来看，咱们是用sqlSession在执行sql语句， 实际呢，其实是通过excutor执行， excutor是对于Statement的封装
    final Executor executor = configuration.newExecutor(tx, execType);
    //关键看这儿，创建了一个DefaultSqlSession对象
    return new DefaultSqlSession(configuration, executor, autoCommit);
  } catch (Exception e) {
    closeTransaction(tx); // may have fetched a connection so lets call close()
    throw ExceptionFactory.wrapException("Error opening session.  Cause: " + e, e);
  } finally {
    ErrorContext.instance().reset();
  }
}

通过以上步骤，咱们已经得到SqlSession对象了。接下来就是该干嘛干嘛去了（话说还能干嘛，当然是执行sql语句咯）。看了上面，咱们也回想一下之前写的Demo:

SqlSessionFactory sessionFactory = null;  
String resource = "mybatis-conf.xml";  
try {
     //SqlSessionFactoryBuilder读取配置文件
    sessionFactory = new SqlSessionFactoryBuilder().build(Resources  
              .getResourceAsReader(resource));
} catch (IOException e) {  
    e.printStackTrace();  
}    
//通过SqlSessionFactory获取SqlSession
SqlSession sqlSession = sessionFactory.openSession();

还真这么一回事儿，对吧！

SqlSession咱们也拿到了，咱们可以调用SqlSession中一系列的select..., insert..., update..., delete...方法轻松自如的进行CRUD操作了。 就这样？ 那咱配置的映射文件去哪儿了？ 别急， 咱们接着往下看：

2. 利器之MapperProxy

在mybatis中，通过MapperProxy动态代理咱们的dao， 也就是说， 当咱们执行自己写的dao里面的方法的时候，其实是对应的mapperProxy在代理。那么，咱们就看看怎么获取MapperProxy对象吧：

(1) 通过SqlSession从Configuration中获取

/**
 * 什么都不做，直接去configuration中找， 哥就是这么任性
 */
@Override
public <T> T getMapper(Class<T> type) {
  return configuration.<T>getMapper(type, this);
}

(2) SqlSession把包袱甩给了Configuration

/**
 * 烫手的山芋，俺不要，你找mapperRegistry去要
 * @param type
 * @param sqlSession
 * @return
 */
public <T> T getMapper(Class<T> type, SqlSession sqlSession) {
  return mapperRegistry.getMapper(type, sqlSession);
}

(3) Configuration也不要，甩给了MapperRegistry

/**
 * 你还是找我吧，别再甩皮球了
 * @param type
 * @param sqlSession
 * @return
 */
@SuppressWarnings("unchecked")
public <T> T getMapper(Class<T> type, SqlSession sqlSession) {
  final MapperProxyFactory<T> mapperProxyFactory = (MapperProxyFactory<T>) knownMappers.get(type);
  if (mapperProxyFactory == null) {
    throw new BindingException("Type " + type + " is not known to the MapperRegistry.");
  }
  try {
    return mapperProxyFactory.newInstance(sqlSession);
  } catch (Exception e) {
    throw new BindingException("Error getting mapper instance. Cause: " + e, e);
  }
}

(4) MapperRegistry最终创建了MapperProxyFactory

/**
 * 看我的，我自己创建一个MapperProxyFactory
 * @param type
 */
public <T> void addMapper(Class<T> type) {
  if (type.isInterface()) {
    if (hasMapper(type)) {
      throw new BindingException("Type " + type + " is already known to the MapperRegistry.");
    }
    boolean loadCompleted = false;
    try {
      knownMappers.put(type, new MapperProxyFactory<T>(type));
      // It's important that the type is added before the parser is run
      // otherwise the binding may automatically be attempted by the
      // mapper parser. If the type is already known, it won't try.
      MapperAnnotationBuilder parser = new MapperAnnotationBuilder(config, type);
      parser.parse();
      loadCompleted = true;
    } finally {
      if (!loadCompleted) {
        knownMappers.remove(type);
      }
    }
  }
}

通过以上步骤，咱们最终得到了MapperProxy对象，当咱们调用dao里面的方法的时候，其实就是MapperProxy在代理。这样，咱们就可以通过MapperProxy来执行sql语句了。

3. SQL执行流程总结

4. 配置解析: SqlSessionFactoryBuilder解析mybatis配置文件，创建Configuration对象。

5. 创建会话工厂: 通过Configuration对象创建SqlSessionFactory。

6. 获取会话: 通过SqlSessionFactory创建SqlSession。

7. 获取Mapper代理: 通过SqlSession获取Mapper接口的代理对象。

8. 方法调用: 调用Mapper接口方法，实际由MapperProxy代理执行。

9. SQL执行: MapperProxy通过Executor执行SQL语句。

10. 结果处理: Executor处理SQL执行结果，返回给调用方。

Mybatis缓存

https://blog.csdn.net/weixin_37139197/article/details/82908377

Mybatis中运用了那些设计模式

https://blog.csdn.net/qq_42922846/article/details/91879958

静态代理、JDK动态代理与cglib动态代理区别