标签：封装 schema published 流程 text 机制 正则 ted 静态代理
Spring
Spring中的基本概念
1.IOC/DI
对象的属性由自己创建,为正向流程,而由Spring创建,为控制反转.
DI(依赖注入)为实现IOC的一种方式,通过配置文件或注解包含的依赖关系创建与注入对象.
正向流程导致了对象与对象之间的高耦合,IOC可以解决对象耦合的问题,有利于功能的复用
例如,招聘中,公司按岗位要求安排人选为正向流程,反之,由第三方猎头匹配岗位和候选人,并向公司推荐,
一、Ioc是什么？
控制反转（Inversion of Control，缩写为IoC），是面向对象编程中的一种设计原则，可以用来减低计算机代码之间的耦合度。其中最常见的方式叫做依赖注入（Dependency Injection，简称DI），还有一种方式叫“依赖查找”（Dependency Lookup）。通过控制反转，对象在被创建的时候，由一个调控系统内所有对象的外界实体，将其所依赖的对象的引用传递给它。也可以说，依赖被注入到对象中。当然，这是百度说的，看了还是不懂，so，复杂的东西简单说
控制反转三个问题：1、谁控制谁；
2、控制了什么；
3、怎么就反转了；
第一个问题：谁控制谁，Ioc其实可以把它当做一个容器，一个存储对象的容器，我们开发中的对象都可以交给spring Ioc容器做一个统一的规范管理，就好像是我们每个人都有自己的简历，全部交给人力资源局来管理，Ioc容器就充当一个人力资源局的角色；
第二个问题：控制了什么，既然我们的开发之中的对象已经全部交由Ioc容器来管理了，那我们在获取对象的时候就得由Ioc容器来给我们提供，那么然Ioc容器也就控制了我们实例对象的获取权，就好像我们要去取得一个人的档案，就得由人力资源局提供，人力资源局控制了我们档案的提取;
第三个问题：怎么就反转了，其实说白了就是一个控制权的反转，好比我们需要一个其他人的档案，我们直接去找这个人家要过来，这个事情是我们来做，控制权就在我们手里（程序过程就是classA需要一个classB的实例，就在A类中直接new 一个B的实例来使用），但是现在我们不直接向这个人所要档案了，我们去向资源局去索要这个人的档案，由人力局把档案给我们（程序过程就是classA需要classB的一个实例，然后告诉Ioc容器，我需要B的实例，你给我一个，然后容器把B的实例给classA），现在，弄档案这个事情是资源局在做而不是我们了，这个弄档案的事情的控制权到了资源局手里而非我们自己去弄，Ioc的职责就像是资源局，我们在使用spring框架开发时，就把我们的对象交由spring Ioc容器来管理，我们对实例对象的控制权利发生了一个反转；
二、Ioc容器能干什么，为什么要把对象的控制权交给容器来管理？
Ioc是一种设计思想，帮助我们实现程序之间的解耦，设计出耦合性更低更优良的的程序，传统的开发模式在程序类的内部主动的依赖对象（new Object）来实现注入，从而使的类之间高度耦合，有了Ioc容器之后，我们可以把对象的控制权交给容器，让容器为我们创建管理对象，这样，对象之间耦合度变低，程序的架构体系也会更加的灵活；
三、Ioc与DI
看过很多的博客都把Ioc跟DI分开来说，我个人感觉他们的紧密程度非常之大，像是一条工作链必不可少的部分，工作模式又是相辅相成；
什么是DI：依赖注入，在容器运行的时候，扫描所有的依赖关系，并为之动态的注入对应的依赖关系，比如，我们需要某人的档案了，就给人力资源局发一个通知，告诉他我需要领取xxx的档案，然后资源局就把档案给你送过来，我们领取档案的过程就是DI（依赖注入）
DI的几个问题：1、谁依赖谁
2、谁注入了谁
3、注入了什么
第一个问题：1、谁依赖谁，从我们领取档案的流程来看就知道我们依赖于人力资源局，也就是说程序依赖于Ioc容器
第二个问题：2、谁注入了谁，人力资源局把档案给我们，也就是说Ioc容器把对象注入了程序之中（这个过程就是依赖注入）
第三个问题：3、注入了什么，我们向人力资源局要档案然后给了我们，就是容器把我们依赖的对象注入了程序
Ioc与DI的关系：他两的关系就像是同一个问题的不同角度的描述，总是那么的紧密相连，理解过上边的自然心里就清晰了
四、总结
看到这里，其实Ioc容器就是为我们提供一个公共的管理平台，管理我们对象之间的依赖关系，我们需要什么就向容器要，容器之中如果要就会给我们，我们拿过来直接用，而不用去考虑对象什么时候创建，什么时候销毁，只管用就行了，是不是方便了很多
2.Context&Bean
所有由Spring创建,管理,用于依赖注入的对象,称为Bean
所有Bean创建并完成依赖注入后,都会放入Context上下文中进行管理
3.AOP(Aspect Oriented Programming 面向切面编程)
以功能进行划分,对服务顺序执行流程中的位置进行横切,完成各服务共同需要实现的功能
什么是AOP
AOP（Aspect-OrientedProgramming，面向方面编程），可以说是OOP（Object-Oriented Programing，面向对象编程）的补充和完善。OOP引入封装、继承和多态性等概念来建立一种对象层次结构，用以模拟公共行为的一个集合。当我们需要为分散的对象引入公共行为的时候，OOP则显得无能为力。也就是说，OOP允许你定义从上到下的关系，但并不适合定义从左到右的关系。例如日志功能。日志代码往往水平地散布在所有对象层次中，而与它所散布到的对象的核心功能毫无关系。对于其他类型的代码，如安全性、异常处理和透明的持续性也是如此。这种散布在各处的无关的代码被称为横切（cross-cutting）代码，在OOP设计中，它导致了大量代码的重复，而不利于各个模块的重用。
而AOP技术则恰恰相反，它利用一种称为“横切”的技术，剖解开封装的对象内部，并将那些影响了多个类的公共行为封装到一个可重用模块，并将其名为“Aspect”，即方面。所谓“方面”，简单地说，就是将那些与业务无关，却为业务模块所共同调用的逻辑或责任封装起来，便于减少系统的重复代码，降低模块间的耦合度，并有利于未来的可操作性和可维护性。AOP代表的是一个横向的关系，如果说“对象”是一个空心的圆柱体，其中封装的是对象的属性和行为；那么面向方面编程的方法，就仿佛一把利刃，将这些空心圆柱体剖开，以获得其内部的消息。而剖开的切面，也就是所谓的“方面”了。然后它又以巧夺天功的妙手将这些剖开的切面复原，不留痕迹。
使用“横切”技术，AOP把软件系统分为两个部分：核心关注点和横切关注点。业务处理的主要流程是核心关注点，与之关系不大的部分是横切关注点。横切关注点的一个特点是，他们经常发生在核心关注点的多处，而各处都基本相似。比如权限认证、日志、事务处理。Aop 的作用在于分离系统中的各种关注点，将核心关注点和横切关注点分离开来。正如Avanade公司的高级方案构架师Adam Magee所说，AOP的核心思想就是“将应用程序中的商业逻辑同对其提供支持的通用服务进行分离。”
实现AOP的技术，主要分为两大类：一是采用动态代理技术，利用截取消息的方式，对该消息进行装饰，以取代原有对象行为的执行；二是采用静态织入的方式，引入特定的语法创建“方面”，从而使得编译器可以在编译期间织入有关“方面”的代码。
AOP使用场景
AOP用来封装横切关注点，具体可以在下面的场景中使用:
Authentication 权限
Caching 缓存
Context passing 内容传递
Error handling 错误处理
Lazy loading 懒加载
Debugging 调试
logging, tracing, profiling and monitoring 记录跟踪 优化 校准
Performance optimization 性能优化
Persistence 持久化
Resource pooling 资源池
Synchronization 同步
Transactions 事务
AOP相关概念
方面（Aspect）：一个关注点的模块化，这个关注点实现可能另外横切多个对象。事务管理是J2EE应用中一个很好的横切关注点例子。方面用Spring的 Advisor或拦截器实现。
连接点（Joinpoint）: 程序执行过程中明确的点，如方法的调用或特定的异常被抛出。
通知（Advice）: 在特定的连接点，AOP框架执行的动作。各种类型的通知包括“around”、“before”和“throws”通知。通知类型将在下面讨论。许多AOP框架包括Spring都是以拦截器做通知模型，维护一个“围绕”连接点的拦截器链。Spring中定义了四个advice: BeforeAdvice, AfterAdvice, ThrowAdvice和DynamicIntroductionAdvice
切入点（Pointcut）: 指定一个通知将被引发的一系列连接点的集合。AOP框架必须允许开发者指定切入点：例如，使用正则表达式。 Spring定义了Pointcut接口，用来组合MethodMatcher和ClassFilter，可以通过名字很清楚的理解， MethodMatcher是用来检查目标类的方法是否可以被应用此通知，而ClassFilter是用来检查Pointcut是否应该应用到目标类上
引入（Introduction）: 添加方法或字段到被通知的类。 Spring允许引入新的接口到任何被通知的对象。例如，你可以使用一个引入使任何对象实现 IsModified接口，来简化缓存。Spring中要使用Introduction, 可有通过DelegatingIntroductionInterceptor来实现通知，通过DefaultIntroductionAdvisor来配置Advice和代理类要实现的接口
目标对象（Target Object）: 包含连接点的对象。也被称作被通知或被代理对象。POJO
AOP代理（AOP Proxy）: AOP框架创建的对象，包含通知。 在Spring中，AOP代理可以是JDK动态代理或者CGLIB代理。
织入（Weaving）: 组装方面来创建一个被通知对象。这可以在编译时完成（例如使用AspectJ编译器），也可以在运行时完成。Spring和其他纯Java AOP框架一样，在运行时完成织入。
如何使用Spring AOP
可以通过配置文件或者编程的方式来使用Spring AOP。
配置可以通过xml文件来进行，大概有四种方式：
1. 配置ProxyFactoryBean，显式地设置advisors, advice, target等
2. 配置AutoProxyCreator，这种方式下，还是如以前一样使用定义的bean，但是从容器中获得的其实已经是代理对象
3. 通过<aop:config>来配置
4. 通过<aop: aspectj-autoproxy>来配置，使用AspectJ的注解来标识通知及切入点
也可以直接使用ProxyFactory来以编程的方式使用Spring AOP，通过ProxyFactory提供的方法可以设置target对象, advisor等相关配置，最终通过 getProxy()方法来获取代理对象
Spring AOP代理对象的生成
Spring提供了两种方式来生成代理对象: JDKProxy和Cglib，具体使用哪种方式生成由AopProxyFactory根据AdvisedSupport对象的配置来决定。默认的策略是如果目标类是接口，则使用JDK动态代理技术，否则使用Cglib来生成代理。下面我们来研究一下Spring如何使用JDK来生成代理对象，具体的生成代码放在JdkDynamicAopProxy这个类中，
什么是Spring AOP：
Spring AOP面向切面编程，将日志、事务等相对独立且重复的功能抽取出来，利用Spring的配置文件或者注解的形式将这些功能织入进去，提高了复用性。
采用技术：
AOP 实现的关键就在于 AOP 框架自动创建的 AOP 代理，AOP 代理则可分为静态代理和动态代理两大类，其中静态代理是指使用 AOP 框架提供的命令进行编译，从而在编译阶段就可生成 AOP 代理类，因此也称为编译时增强；而动态代理则在运行时借助于 JDK 动态代理、CGLIB 等在内存中“临时”生成 AOP 动态代理类，因此也被称为运行时增强。
Spring AOP采用的是动态代理，在运行期间对业务方法进行增强，所以不会生成新类，对于动态代理技术，Spring AOP提供了对JDK动态代理的支持以及CGLib的支持。前者是基于反射技术的实现，后者是基于继承的机制实现。如果目标对象有实现接口，使用jdk代理。如果目标对象没有实现接口，则使用Cglib代理。
Spring框架
1.Core
Spring组件的核心
2.Beans和Context
实现IOC/DI的基础
3.Web
包括SpringMVC是Web服务的控制层实现
4.AOP
面向切面编程
Spring机制与实现
Spring应用
Spring Context初始化流程
1.prepareRefresh();对刷新进行准备,包括设置开始时间,设置激活状态,初始化Context中的占位符,子类根据其需求执行具体准备工作,而后再由父类验证必要参数
2.obtianFreshBeanFactory();,刷新并获取内部的BeanFactory对象
3.prepareBeanFactory(beanFactory);,对BeanFactory进行准备工作,包括设置类加载器和后置处理器,配置不能自动装配的类型,注册默认的环境Bean
4.postProcessBeanFactory(beanFactory);为Context的子类提供后置处理BeanFactory的扩展能力,如想在bean定义加载完成后,开始初始化上下文之前进行逻辑操作,可重写这个方法
5.invokeBeanFactoryPostProcessors(beanFactory);,执行Context中注册的BeanFactory后置处理器,有两张处理器,一种是可以注册Bean的后置处理器,一种的针对BeanFactory的后置处理器,执行顺序是先按优先级执行注册Bean的后置处理器,而后再按优先级执行针对BeanFactory的后置处理器
SpringBoot中会进行注解Bean的解析,由ConfigurationClassPostProcessor触发,由ClassPathDefinitionScanner解析,并注册到BeanFactory
6.registerBeanFactoryProcessor(beanFactory();,按优先级顺序在BeanFactory中注册Bean的后置处理器,Bean处理器可在Bean的初始化前后处理
7.initMessageSource();初始化消息源,消息源用于支持消息的国际化
8.initApplicationEventMuticaster();初始化应用事件广播器,用于向ApplicationListener通知各种应用产生的事件,标准的观察者模型
9.onRefresh();,用于子类的扩展步骤,用于特定的Context子类初始化其他的Bean
10.registerListeners();,把实现了ApplicationListener的类注册到广播器,并对广播其中早期没有广播的事件进行通知
11.finishBeanFactoryInitialization(beanFactory);,冻结所有Bean描述信息的修改,实例化非延迟加载的单例Bean
12.finishRefresh();,完成上下文的刷新工作,调用LifecycleProcessor.onRefresh(),以及发布
ContextRefreshedEvent事件
13.resetCommonCaches();在finally中执行该步骤,重置公共的缓存,如ReflectionUtils中的缓存,
AnnotationUtils等
Spring中Bean的生命周期
找工作的时候有些人会被问道Spring中Bean的生命周期，其实也就是考察一下对Spring是否熟悉，工作中很少用到其中的内容，那我们简单看一下。
在说明前可以思考一下Servlet的生命周期：实例化，初始init，接收请求service，销毁destroy；
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初始化结束时调用那个的方法，也可以被应用于内存或缓存技术；
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属性，会自动调用其配置的销毁方法。
Spring扩展接口
SpringBoot
面试考察点
1.掌握Spring的IOC,AOP的概念与实现
2.掌握Spring的Context创建流程和Bean的生命周期
3.了解Spring常见注解的作用与使用方法
4.了解SpringBoot的相关知识点
真题汇总
1.SSH与SSM框架组合的区别
SpringMVC与Struct的区别,Mybatis与Hibernate的区别
重点：SSH指的是：spring+Struts+hibernate，而SSM指的是:spring +SpringMVC + MyBatis。
1、Spring是开源框架，是轻量级的IoC和AOP的容器框架，主要是针对javaBean的生命周期进行管理的轻量级容器，可以单独使用，也可以和Struts框架，ibatis框架等组合使用。
1）IoC(Inversion of Control)控制反转，对象创建责任的反转，在spring中BeanFacotory是IoC容器的核心接口，负责实例化，定位，配置应用程序中的对象及建立这些对象间的依赖。XmlBeanFacotory实现BeanFactory接口，通过获取xml配置文件数据，组成应用对象及对象间的依赖关系。Spring中有三种注入方式，一种是set注入，一种是接口注入，另一种是构造方法注入。
2）AOP面向切面编程
aop就是纵向的编程，如果业务1和业务2都需要一个共同的操作，与其往每个业务中都添加同样的代码，不如写一遍代码，让两个业务共同使用这段代码。
spring中面向切面变成的实现有两种方式，一种是动态代理，一种是CGLIB，动态代理必须要提供接口，而CGLIB实现是有继承。
Spring框架优点
1）轻量级的容器框架没有侵入性
2）使用IoC容器更加容易组合对象直接间关系，面向接口编程，降低耦合
3）Aop可以更加容易的进行功能扩展，遵循ocp开发原则
4）创建对象默认是单例的，不需要再使用单例模式进行处理
2、SpringMVC与Struts :
1）两者有个共同之处，那就是两者都数据javaweb层的开发框架，都是mvc模式的的经典产品，都实现了页面分离控制的功能，但是两者之间是有区别的。
2）在开发中，人们更愿意使用SpringMVC而不是Struts。因为SpringMVC分离了控制器、模型对象、分派器以及处理程序对象的角色，这种分离让它们更容易进行定制。在扩展和灵活性上更胜一筹。
3）Struts的优势在于静态注入，插件机制和拦截器链，但是struts存在漏洞，经常会被作为攻击点进行冲击。相比更加安全简单的SpringMVC，开发者渐渐开发放弃了它。
3、Hibernate 与MyBatis:
1）Hibernate与Mybatis都是流行的持久层开发框架，一句话概括：MyBatis 简单易上手；
2）hibernate成熟，市场推广率高。
3）MyBatis可以进行更为细致的SQL优化，可以减少查询字段。
4）MyBatis容易掌握，而Hibernate门槛较高。
5）更重要的是，mybatis提供了对应各种用途、功能的插件，而hibernate在这一方面是远远比不上mybatis的。
6）Hibernate的DAO层开发比MyBatis简单，Mybatis需要维护SQL和结果映射。
7）Hibernate对对象的维护和缓存要比MyBatis好，对增删改查的对象的维护要方便。
8）Hibernate数据库移植性很好，MyBatis的数据库移植性不好，不同的数据库需要写不同SQL。
9）Hibernate有更好的二级缓存机制，可以使用第三方缓存。MyBatis本身提供的缓存机制不佳。
10）但是hibernat缺点很明确，如果涉及到多张关联表的调用时：
1. 多表关联等比较复杂，使用的成本并不低；
2. 效率比较低，在大型项目中很少会使用到它，因为sql都是自动生成的，不太好进行人工的优化。
2.描述一下SpringContext的初始化流程
ContextLoaderListener
在SpringBoot面世之前。在一般的WEB项目中，项目的启动都是从web.xml开始的，如果我们想在项目中使用Spring，只需在web.xml文件中指定以下内容即可：
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>classpath:applicationContext.xml</param-value>
</context-param>
<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>
通过以上代码片段不难看出Spring正是通过ContextLoaderListener监听器来进行容器初始化的，查看ContextLoaderListener源码：
public class ContextLoaderListener extends ContextLoader implements ServletContextListener {
public ContextLoaderListener() {
}
public ContextLoaderListener(WebApplicationContext context) {
super(context);
}
@Override
public void contextInitialized(ServletContextEvent event) {
initWebApplicationContext(event.getServletContext());
}
@Override
public void contextDestroyed(ServletContextEvent event) {
closeWebApplicationContext(event.getServletContext());
ContextCleanupListener.cleanupAttributes(event.getServletContext());
}
}
根据该类中的注释可以看出initWebApplicationContext方法为核心的初始化方法，从initWebApplicationContext方法源代码可以看出Spring初始化容器主要分为以下几个步骤：
创建容器WebApplicationContext
验证当前容器是否为可配置的，是则配置并且刷新当前容器
将当前创建的容器设置到servlet上下文中
SpringBoot中的Spring
上文根据一般WEB项目跟踪了Spring容器初始化过程，但是从上诉过程并不能相对明显地看出Spring容器初始化过程。
在SpringBoot面世后，它简化了许多的配置方式，在SpringBoot中只需引入相应的start即可使用Spring，接下来就去看看SpringBoot中的Spring吧。
通过SpringBoot入口方法SpringApplication.run可以看到以下代码：
ApplicationArguments applicationArguments = new DefaultApplicationArguments(
args);
ConfigurableEnvironment environment = prepareEnvironment(listeners,
applicationArguments);
configureIgnoreBeanInfo(environment);
Banner printedBanner = printBanner(environment);
//创建容器
context = createApplicationContext();
exceptionReporters = getSpringFactoriesInstances(
SpringBootExceptionReporter.class,
new Class[] { ConfigurableApplicationContext.class }, context);
//容器准备工作
prepareContext(context, environment, listeners, applicationArguments,
printedBanner);
//刷新容器
refreshContext(context);
其中，创建容器容器的方法是createApplicationContext，createApplicationContext方法会根据当前启动类型去初始化不同的Spring容器，主要类型为以下三种：
NONE：非WEB，普通应用程序
REACTIVE：反应堆栈Web容器(5.x新加)
SERVLET：Web容器
ps:反应堆栈Web容器，即WebFlux框架，该框架是Spring 5.x新加的框架，详细内容请访问SpringCloud中文网：https://springcloud.cc/web-reactive.html
prepareContext
prepareContext方法是做context的准备工作，该方法主要对容器进行一些预设置，源码中，该方法中的postProcessApplicationContext方法向beanFactory中添加了一个beanNameGenerator：
protected void postProcessApplicationContext(ConfigurableApplicationContext context) {
if (this.beanNameGenerator != null) {
context.getBeanFactory().registerSingleton(
AnnotationConfigUtils.CONFIGURATION_BEAN_NAME_GENERATOR,
this.beanNameGenerator);
}
if (this.resourceLoader != null) {
if (context instanceof GenericApplicationContext) {
((GenericApplicationContext) context)
.setResourceLoader(this.resourceLoader);
}
if (context instanceof DefaultResourceLoader) {
((DefaultResourceLoader) context)
.setClassLoader(this.resourceLoader.getClassLoader());
}
}
}
其中，BeanNameGenerator用来生成扫描到的Bean在容器中的名字。
在prepareContext方法中，applyInitializers也是一个颇为重要的内容，通过查询资料发现该方法主要是对已创建的并且未被刷新的容器进行设置的自定义应用上下文初始化器。
refreshContext
通过跟踪refreshContext方法不难发现，其最终执行的是AbstractRefreshableApplicationContext类中的refresh方法，其源码如下：
public void refresh() throws BeansException, IllegalStateException {
Object var1 = this.startupShutdownMonitor;
synchronized(this.startupShutdownMonitor) {
// 为应用上下文的刷新做准备--设置时间、记录刷新日志、初始化属性源中的占位符(事实上什么都没做)和验证必 要的属性等
this.prepareRefresh();
// 让子类刷新内部的bean factory
ConfigurableListableBeanFactory beanFactory = this.obtainFreshBeanFactory();
//为上下文准备bean factory
this.prepareBeanFactory(beanFactory);
try {
// bean factory 后置处理
this.postProcessBeanFactory(beanFactory);
// 调用应用上下文中作为bean注册的工厂处理器
this.invokeBeanFactoryPostProcessors(beanFactory);
// 注册拦截创建bean的bean处理器
this.registerBeanPostProcessors(beanFactory);
// 初始化消息源
this.initMessageSource();
// 初始化事件广播
this.initApplicationEventMulticaster();
// 初始化特定上下文子类中的其它bean
this.onRefresh();
// 注册监听器bean
this.registerListeners();
// 实例化所有的单例bean
this.finishBeanFactoryInitialization(beanFactory);
// 发布相应的事件
this.finishRefresh();
} catch (BeansException var9) {
if (this.logger.isWarnEnabled()) {
this.logger.warn("Exception encountered during context initialization - cancelling refresh attempt: " + var9);
}
//销毁错误的资源
this.destroyBeans();
//重置刷新标志
this.cancelRefresh(var9);
throw var9;
} finally {
this.resetCommonCaches();
}
}
}
从以上代码的注释，可以看出refresh方法是Spring容器初始化的过程中加载Bean至关重要的一环，其职责主要是获取Bean，并初始化Bean。
3.简单介绍一下Bean的生命周期与作用域
在Spring中，那些组成应用程序的主体及由Spring IoC容器所管理的对象，被称之为bean。简单地讲，bean就是由IoC容器初始化、装配及管理的对象，除此之外，bean就与应用程序中的其他对象没有什么区别了。而bean的定义以及bean相互间的依赖关系将通过配置元数据来描述。
Spring中的bean默认都是单例的，这些单例Bean在多线程程序下如何保证线程安全呢？例如对于Web应用来说，Web容器对于每个用户请求都创建一个单独的Sevlet线程来处理请求，引入Spring框架之后，每个Action都是单例的，那么对于Spring托管的单例Service Bean，如何保证其安全呢？ Spring的单例是基于BeanFactory也就是Spring容器的，单例Bean在此容器内只有一个，Java的单例是基于JVM，每个JVM内只有一个实例。
1、bean的作用域
创建一个bean定义，其实质是用该bean定义对应的类来创建真正实例的“配方”。把bean定义看成一个配方很有意义，它与class很类似，只根据一张“处方”就可以创建多个实例。不仅可以控制注入到对象中的各种依赖和配置值，还可以控制该对象的作用域。这样可以灵活选择所建对象的作用域，而不必在Java Class级定义作用域。Spring Framework支持五种作用域，分别阐述如下表。
五种作用域中，request、session和global session三种作用域仅在基于web的应用中使用（不必关心你所采用的是什么web应用框架），只能用在基于web的Spring ApplicationContext环境。
(1)当一个bean的作用域为Singleton，那么Spring IoC容器中只会存在一个共享的bean实例，并且所有对bean的请求，只要id与该bean定义相匹配，则只会返回bean的同一实例。Singleton是单例类型，就是在创建起容器时就同时自动创建了一个bean的对象，不管你是否使用，他都存在了，每次获取到的对象都是同一个对象。注意，Singleton作用域是Spring中的缺省作用域。要在XML中将bean定义成singleton，可以这样配置：
<bean id="ServiceImpl" class="cn.csdn.service.ServiceImpl" scope="singleton">
1
(2)当一个bean的作用域为Prototype，表示一个bean定义对应多个对象实例。Prototype作用域的bean会导致在每次对该bean请求（将其注入到另一个bean中，或者以程序的方式调用容器的getBean()方法）时都会创建一个新的bean实例。Prototype是原型类型，它在我们创建容器的时候并没有实例化，而是当我们获取bean的时候才会去创建一个对象，而且我们每次获取到的对象都不是同一个对象。根据经验，对有状态的bean应该使用prototype作用域，而对无状态的bean则应该使用singleton作用域。在XML中将bean定义成prototype，可以这样配置：
<bean id="account" class="com.foo.DefaultAccount" scope="prototype"/>
或者
<bean id="account" class="com.foo.DefaultAccount" singleton="false"/>
(3)当一个bean的作用域为Request，表示在一次HTTP请求中，一个bean定义对应一个实例；即每个HTTP请求都会有各自的bean实例，它们依据某个bean定义创建而成。该作用域仅在基于web的Spring ApplicationContext情形下有效。考虑下面bean定义：
<bean id="loginAction" class="cn".csdn.LoginAction" scope="request"/>
1
针对每次HTTP请求，Spring容器会根据loginAction bean的定义创建一个全新的LoginAction bean实例，且该loginAction bean实例仅在当前HTTP request内有效，因此可以根据需要放心的更改所建实例的内部状态，而其他请求中根据loginAction bean定义创建的实例，将不会看到这些特定于某个请求的状态变化。当处理请求结束，request作用域的bean实例将被销毁。
(4)当一个bean的作用域为Session，表示在一个HTTP Session中，一个bean定义对应一个实例。该作用域仅在基于web的Spring ApplicationContext情形下有效。考虑下面bean定义：
<bean id="userPreferences" class="com.foo.UserPreferences" scope="session"/>
1
针对某个HTTP Session，Spring容器会根据userPreferences bean定义创建一个全新的userPreferences bean实例，且该userPreferences bean仅在当前HTTP Session内有效。与request作用域一样，可以根据需要放心的更改所创建实例的内部状态，而别的HTTP Session中根据userPreferences创建的实例，将不会看到这些特定于某个HTTP Session的状态变化。当HTTP Session最终被废弃的时候，在该HTTP Session作用域内的bean也会被废弃掉。
(5)当一个bean的作用域为Global Session，表示在一个全局的HTTP Session中，一个bean定义对应一个实例。典型情况下，仅在使用portlet context的时候有效。该作用域仅在基于web的Spring ApplicationContext情形下有效。考虑下面bean定义：
<bean id="user" class="com.foo.Preferences "scope="globalSession"/>
1
global session作用域类似于标准的HTTP Session作用域，不过仅仅在基于portlet的web应用中才有意义。Portlet规范定义了全局Session的概念，它被所有构成某个portlet web应用的各种不同的portlet所共享。在global session作用域中定义的bean被限定于全局portlet Session的生命周期范围内。
2、bean的生命周期
Spring中bean的实例化过程(不好意思，我盗图了)：
与上图类似，bean的生命周期流程图：
Bean实例生命周期的执行过程如下：
Spring对bean进行实例化，默认bean是单例；
Spring对bean进行依赖注入；
如果bean实现了BeanNameAware接口，spring将bean的id传给setBeanName()方法；
如果bean实现了BeanFactoryAware接口，spring将调用setBeanFactory方法，将BeanFactory实例传进来；
如果bean实现了ApplicationContextAware接口，它的setApplicationContext()方法将被调用，将应用上下文的引用传入到bean中；
如果bean实现了BeanPostProcessor接口，它的postProcessBeforeInitialization方法将被调用；
如果bean实现了InitializingBean接口，spring将调用它的afterPropertiesSet接口方法，类似的如果bean使用了init-method属性声明了初始化方法，该方法也会被调用；
如果bean实现了BeanPostProcessor接口，它的postProcessAfterInitialization接口方法将被调用；
此时bean已经准备就绪，可以被应用程序使用了，他们将一直驻留在应用上下文中，直到该应用上下文被销毁；
若bean实现了DisposableBean接口，spring将调用它的distroy()接口方法。同样的，如果bean使用了destroy-method属性声明了销毁方法，则该方法被调用；
其实很多时候我们并不会真的去实现上面说描述的那些接口，那么下面我们就除去那些接口，针对bean的单例和非单例来描述下bean的生命周期：
2.1 单例管理的对象
当scope=”singleton”，即默认情况下，会在启动容器时（即实例化容器时）时实例化。但我们可以指定Bean节点的lazy-init=”true”来延迟初始化bean，这时候，只有在第一次获取bean时才会初始化bean，即第一次请求该bean时才初始化。如下配置：
<bean id="ServiceImpl" class="cn.csdn.service.ServiceImpl" lazy-init="true"/>
1
如果想对所有的默认单例bean都应用延迟初始化，可以在根节点beans设置default-lazy-init属性为true，如下所示：
<beans default-lazy-init="true" …>
1
默认情况下，Spring在读取xml文件的时候，就会创建对象。在创建对象的时候先调用构造器，然后调用init-method属性值中所指定的方法。对象在被销毁的时候，会调用destroy-method属性值中所指定的方法（例如调用Container.destroy()方法的时候）。写一个测试类，代码如下：
public class LifeBean {
private String name;
public LifeBean(){
System.out.println("LifeBean()构造函数");
}
public String getName() {
return name;
}
public void setName(String name) {
System.out.println("setName()");
this.name = name;
}
public void init(){
System.out.println("this is init of lifeBean");
}
public void destory(){
System.out.println("this is destory of lifeBean " + this);
}
}
life.xml配置如下：
<bean id="life_singleton" class="com.bean.LifeBean" scope="singleton"
init-method="init" destroy-method="destory" lazy-init="true"/>
1
2
测试代码如下：
public class LifeTest {
@Test
public void test() {
AbstractApplicationContext container =
new ClassPathXmlApplicationContext("life.xml");
LifeBean life1 = (LifeBean)container.getBean("life");
System.out.println(life1);
container.close();
}
}
运行结果如下：
LifeBean()构造函数
this is init of lifeBean
com.bean.LifeBean@573f2bb1
……
this is destory of lifeBean com.bean.LifeBean@573f2bb1
2.2 非单例管理的对象
当scope=”prototype”时，容器也会延迟初始化bean，Spring读取xml文件的时候，并不会立刻创建对象，而是在第一次请求该bean时才初始化（如调用getBean方法时）。在第一次请求每一个prototype的bean时，Spring容器都会调用其构造器创建这个对象，然后调用init-method属性值中所指定的方法。对象销毁的时候，Spring容器不会帮我们调用任何方法，因为是非单例，这个类型的对象有很多个，Spring容器一旦把这个对象交给你之后，就不再管理这个对象了。
为了测试prototype bean的生命周期life.xml配置如下：
<bean id="life_prototype" class="com.bean.LifeBean" scope="prototype" init-method="init" destroy-method="destory"/>
1
测试程序如下：
public class LifeTest {
@Test
public void test() {
AbstractApplicationContext container = new ClassPathXmlApplicationContext("life.xml");
LifeBean life1 = (LifeBean)container.getBean("life_singleton");
System.out.println(life1);
LifeBean life3 = (LifeBean)container.getBean("life_prototype");
System.out.println(life3);
container.close();
}
}
运行结果如下：
LifeBean()构造函数
this is init of lifeBean
com.bean.LifeBean@573f2bb1
LifeBean()构造函数
this is init of lifeBean
com.bean.LifeBean@5ae9a829
……
this is destory of lifeBean com.bean.LifeBean@573f2bb1
可以发现，对于作用域为prototype的bean，其destroy方法并没有被调用。如果bean的scope设为prototype时，当容器关闭时，destroy方法不会被调用。对于prototype作用域的bean，有一点非常重要，那就是Spring不能对一个prototype bean的整个生命周期负责：容器在初始化、配置、装饰或者是装配完一个prototype实例后，将它交给客户端，随后就对该prototype实例不闻不问了。不管何种作用域，容器都会调用所有对象的初始化生命周期回调方法。但对prototype而言，任何配置好的析构生命周期回调方法都将不会被调用。清除prototype作用域的对象并释放任何prototype bean所持有的昂贵资源，都是客户端代码的职责（让Spring容器释放被prototype作用域bean占用资源的一种可行方式是，通过使用bean的后置处理器，该处理器持有要被清除的bean的引用）。谈及prototype作用域的bean时，在某些方面你可以将Spring容器的角色看作是Java new操作的替代者，任何迟于该时间点的生命周期事宜都得交由客户端来处理。
Spring容器可以管理singleton作用域下bean的生命周期，在此作用域下，Spring能够精确地知道bean何时被创建，何时初始化完成，以及何时被销毁。而对于prototype作用域的bean，Spring只负责创建，当容器创建了bean的实例后，bean的实例就交给了客户端的代码管理，Spring容器将不再跟踪其生命周期，并且不会管理那些被配置成prototype作用域的bean的生命周期。
2.3 引申
在学习Spring IoC过程中发现，每次产生ApplicationContext工厂的方式是：
ApplicationContext applicationContext = new ClassPathXmlApplicationContext("applicationContext.xml");
1
这样产生ApplicationContext就有一个弊端，每次访问加载bean的时候都会产生这个工厂，所以这里需要解决这个问题。
ApplicationContext是一个接口，它继承自BeanFactory接口，除了包含BeanFactory的所有功能之外，在国际化支持、资源访问（如URL和文件）、事件传播等方面进行了良好的支持。
解决问题的方法很简单，在web容器启动的时候将ApplicationContext转移到ServletContext中，因为在web应用中所有的Servlet都共享一个ServletContext对象。那么我们就可以利用ServletContextListener去监听ServletContext事件，当web应用启动的是时候，我们就将ApplicationContext装载到ServletContext中。 Spring容器底层已经为我们想到了这一点，在spring-web-xxx-release.jar包中有一个已经实现了ServletContextListener接口的类ContextLoader，其源码如下：
public class ContextLoaderListener extends ContextLoader implements ServletContextListener {
private ContextLoader contextLoader;
public ContextLoaderListener() {
}
public ContextLoaderListener(WebApplicationContext context) {
super(context);
}
public void contextInitialized(ServletContextEvent event) {
this.contextLoader = createContextLoader();
if (this.contextLoader == null) {
this.contextLoader = this;
}
this.contextLoader.initWebApplicationContext(event.getServletContext());
}
@Deprecated
protected ContextLoader createContextLoader() {
return null;
}
@Deprecated
public ContextLoader getContextLoader() {
return this.contextLoader;
}
public void contextDestroyed(ServletContextEvent event) {
if (this.contextLoader != null) {
this.contextLoader.closeWebApplicationContext(event.getServletContext());
}
ContextCleanupListener.cleanupAttributes(event.getServletContext());
}
}
这里就监听到了servletContext的创建过程, 那么 这个类又是如何将applicationContext装入到serveletContext容器中的呢?
this.contextLoader.initWebApplicationContext(event.getServletContext())方法的具体实现中：
public WebApplicationContext initWebApplicationContext(ServletContext servletContext) {
if (servletContext.getAttribute(WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE) != null) {
throw new IllegalStateException(
"Cannot initialize context because there is already a root application context present - " +
"check whether you have multiple ContextLoader* definitions in your web.xml!");
}
Log logger = LogFactory.getLog(ContextLoader.class);
servletContext.log("Initializing Spring root WebApplicationContext");
if (logger.isInfoEnabled()) {
logger.info("Root WebApplicationContext: initialization started");
}
long startTime = System.currentTimeMillis();
try {
// Store context in local instance variable, to guarantee that
// it is available on ServletContext shutdown.
if (this.context == null) {
this.context = createWebApplicationContext(servletContext);
}
if (this.context instanceof ConfigurableWebApplicationContext) {
ConfigurableWebApplicationContext cwac = (ConfigurableWebApplicationContext) this.context;
if (!cwac.isActive()) {
// The context has not yet been refreshed -> provide services such as
// setting the parent context, setting the application context id, etc
if (cwac.getParent() == null) {
// The context instance was injected without an explicit parent ->
// determine parent for root web application context, if any.
ApplicationContext parent = loadParentContext(servletContext);
cwac.setParent(parent);
}
configureAndRefreshWebApplicationContext(cwac, servletContext);
}
}
servletContext.setAttribute(WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE, this.context);
ClassLoader ccl = Thread.currentThread().getContextClassLoader();
if (ccl == ContextLoader.class.getClassLoader()) {
currentContext = this.context;
}
else if (ccl != null) {
currentContextPerThread.put(ccl, this.context);
}
if (logger.isDebugEnabled()) {
logger.debug("Published root WebApplicationContext as ServletContext attribute with name [" +
WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE + "]");
}
if (logger.isInfoEnabled()) {
long elapsedTime = System.currentTimeMillis() - startTime;
logger.info("Root WebApplicationContext: initialization completed in " + elapsedTime + " ms");
}
return this.context;
}
catch (RuntimeException ex) {
logger.error("Context initialization failed", ex);
servletContext.setAttribute(WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE, ex);
throw ex;
}
catch (Error err) {
logger.error("Context initialization failed", err);
servletContext.setAttribute(WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE, err);
throw err;
}
}
这里的重点是servletContext.setAttribute(WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE, this.context)，用key:WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE value: this.context的形式将applicationContext装载到servletContext中了。另外从上面的一些注释我们可以看出： WEB-INF/applicationContext.xml， 如果我们项目中的配置文件不是这么一个路径的话 那么我们使用ContextLoaderListener 就会出问题, 所以我们还需要在web.xml中配置我们的applicationContext.xml配置文件的路径。
<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>classpath:applicationContext.xml</param-value>
</context-param>
剩下的就是在项目中开始使用 servletContext中装载的applicationContext对象了： 那么这里又有一个问题，装载时的key是 WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE，我们在代码中真的要使用这个吗? 其实Spring为我们提供了一个工具类WebApplicationContextUtils，接着我们先看下如何使用，然后再去看下这个工具类的源码：
WebApplicationContext applicationContext = WebApplicationContextUtils.getWebApplicationContext(request.getServletContext());
1
接着来看下这个工具类的源码：
public static WebApplicationContext getWebApplicationContext(ServletContext sc) {
return getWebApplicationContext(sc, WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE);
}
这里就能很直观清晰地看到 通过key值直接获取到装载到servletContext中的 applicationContext对象了。
ContextLoaderListener监听器的作用就是启动Web容器时，自动装配ApplicationContext的配置信息，因为它实现了ServletContextListener这个接口，在web.xml配置这个监听器，启动容器时，就会默认执行它实现的方法。在ContextLoaderListener中关联了ContextLoader这个类，整个加载配置过程由ContextLoader来完成。
4.Spring配置中的placeholder占位符是如何替换的,有什么办法实现自定义的配置替换
通过BeanFactoryPostProcessor处理,PropertyPlaceholderConfigurer或PropertySourcesPlaceholderConfigurer
5.SpringMVC工作流程
从HandlerMapping查找handler,执行handler,执行完成返回ModelAndView,由视图解析返回视图,再有渲染器进行渲染
6.Spring如何解决循环依赖
构造器循环依赖和setter循环依赖两部分解答,构造器通过使用创建Bean中的标识池判断是否产生了循环创建,setter通过引入ObjectFactory解决
7.Bean构造方法
spring框架实例化bean有3中方式，即构造方法实例化、静态工厂实例化、实例工厂实例化（其中，最常用的是构造方法实例化）
构造方法实例化
spring容器可以调用bean对应类中的无参数构造方法来实例化bean，这种方式称为构造方法实例化
1.创建web应用，并导入依赖的jar包
2.创建beanClass类
package instance;
public class BeanClass {
public String message;
public BeanClass(String s) {
this.message = s;
}
public BeanClass() {
this.message="构造方法实例化bean";
}
}
3.创建配置文件
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd">
<bean id="constructorInstance" class="instance.BeanClass">
<!-- collaborators and configuration for this bean go here -->
</bean>
</beans>
4.创建测试类
package test;
import org.springframework.context.ApplicationContext;
import org.springframework.context.support.ClassPathXmlApplicationContext;
import instance.BeanClass;
public class TestInstance {
public static void main(String[] args) {
ApplicationContext appCon = new ClassPathXmlApplicationContext("applicationContext.xml");
BeanClass b1 = (BeanClass)appCon.getBean("constructorInstance");
System.out.println(b1+b1.message);
}
@PostConstuct注解
spring注解@PostConstruct
@PostConstruct是java5的时候引入的注解，指的是在项目启动的时候执行这个方法，也可以理解为在spring容器启动的时候执行，可作为一些数据的常规化加载，比如数据字典之类的。
@PostConstruct
protected void initialize() {
try {
log.debug("AppInition.initialize() Start...");
Map configMap= iSystemConfigService.getConfigMap();
ReflectUtil.reflectProperties(configMap,AppInitConstants.class);
log.debug("AppInition.initialize() End...");
} catch (IllegalAccessException e) {
e.printStackTrace();
}
}
这里 就是在加载一些常量数据
@PostContruct是spring框架的注解，在方法上加该注解会在项目启动的时候执行该方法，也可以理解为在spring容器初始化的时候执行该方法。
业务场景
业务上有需求,需要我通过接口查询数据,将实时的gps数据接入,并保存到一个实时表,一个历史表,在编写代码的时候,我在想数据丢失了怎么办?
情况一:
对方的服务断掉,暂时没有办法
情况二:
我这边的java程序挂掉,我该怎么解决丢失数据这段时间的数据
思考
解决方法一:
启用一个job任务,每天去查询一次一整天的完整数据,在更新到数据库中,利用oracle的merge into 语句进行判断,有就更新,没有就插入,但是老大觉得没有必要
解决思路二:
利用了@PostConstruct注解,我创建了一个init方法,每次java程序重新运行的时候,我先去数据库查找我最后一条插入的数据,然后以数据库最后一条数据为起始时间,以当前时间为结束时间,查询我这程序挂掉的时间段内丢失的数据,尽量保证了我的数据完整性
@PostConstuct注解,InitiatingBean,init-method的执行顺序
package org.test.InitializingBean;
import org.springframework.context.support.ClassPathXmlApplicationContext;
/**
* 测试 spring的 InitializingBean 接口
* @author Administrator
*
*/
public class InitializingBeanTest {
/**
* @param args
*/
public static void main(String[] args) {
ClassPathXmlApplicationContext ctx=new ClassPathXmlApplicationContext("applicationContext.xml",
InitializingBeanTest.class);
ctx.start();
}
}
package org.test.InitializingBean;
import org.springframework.beans.factory.InitializingBean;
/**
* @see {@link org.springframework.beans.factory.InitializingBean#afterPropertiesSet}
* @author Administrator
*
*/
public class User implements InitializingBean {
public User() {
System.out.println(">>>>>>> User 默认的构造函数执行了");
}
@Override
public void afterPropertiesSet() throws Exception {
System.out.println(">>>>>>> 执行了 afterPropertiesSet 方法");
}
}
执行的结果如下图所示。可以看到当执行完User默认的构造函数之后，就会调用该类实现afterPropertiesSet方法
spring bean中构造函数，afterPropertiesSet和init-method的执行顺序
1.xml文件
<bean id="aaa" class="com.dingwang.Test.Aaa" init-method="init">
<constructor-arg name="name" value="ddd"></constructor-arg>
</bean>
2.java文件
public Aaa(String name) {
LOGGER.warn("--------------------Aaa-----------------Aaa");
this.setName(name);
}
public void init() {
LOGGER.warn("--------------------Aaa-----------------init");
}
/*
* (non-Javadoc)
* @see
* org.springframework.beans.factory.InitializingBean#afterPropertiesSet()
*/
@Override
public void afterPropertiesSet() throws Exception {
LOGGER.warn("--------------------Aaa-----------------afterPropertiesSet");
}
3.执行日志
10:44:54.116 [main] DEBUG o.s.b.f.s.DefaultListableBeanFactory - Creating instance of bean ‘aaa‘
10:44:54.157 [main] WARN com.dingwang.Test.Aaa - --------------------Aaa-----------------Aaa
10:44:54.159 [main] DEBUG o.s.b.f.s.DefaultListableBeanFactory - Eagerly caching bean ‘aaa‘ to allow for resolving potential circular references
10:44:54.171 [main] DEBUG o.s.b.f.s.DefaultListableBeanFactory - Invoking afterPropertiesSet() on bean with name ‘aaa‘
10:44:54.172 [main] WARN com.dingwang.Test.Aaa - --------------------Aaa-----------------afterPropertiesSet
10:44:54.172 [main] DEBUG o.s.b.f.s.DefaultListableBeanFactory - Invoking init method ‘init‘ on bean with name ‘aaa‘
10:44:54.172 [main] WARN com.dingwang.Test.Aaa - --------------------Aaa-----------------init
10:44:54.173 [main] DEBUG o.s.b.f.s.DefaultListableBeanFactory - Finished creating instance of bean ‘aaa‘
4.结论
执行顺序：构造函数>afterPropertiesSet>init-method
源码解析：init-method、@PostConstruct、afterPropertiesSet孰先孰后
Spring 容器中的 Bean 是有生命周期的，Spring 允许在 Bean 在初始化完成后以及 Bean 销毁前执行特定的操作，常用的设定方式有以下三种：
通过实现 InitializingBean/DisposableBean 接口来定制初始化之后/销毁之前的操作方法；
通过 <bean> 元素的 init-method/destroy-method属性指定初始化之后 /销毁之前调用的操作方法；
在指定方法上加上@PostConstruct 或@PreDestroy注解来制定该方法是在初始化之后还是销毁之前调用。
这是我们就有个疑问，这三种方式是完全等同的吗，孰先孰后？
Constructor > @PostConstruct > InitializingBean > init-method
先大致分析下为什么会出现这些的结果：构造器（Constructor）被率先调用毋庸置疑，InitializingBean先于init-method我们也可以理解（在也谈Spring容器的生命周期中已经讨论过），但是PostConstruct为何率先于InitializingBean执行呢？
我们发现了这个类org.springframework.context.annotation.CommonAnnotationBeanPostProcessor，从命名上，我们就可以得到某些信息——这是一个BeanPostProcessor。想到了什么？在也谈Spring容器的生命周期中，我们提到过BeanPostProcessor的postProcessBeforeInitialization是在Bean生命周期中afterPropertiesSet和init-method之前执被调用的。
再次观察CommonAnnotationBeanPostProcessor这个类，它继承自InitDestroyAnnotationBeanPostProcessor。InitDestroyAnnotationBeanPostProcessor顾名思义，就是在Bean初始化和销毁的时候所作的一个前置/后置处理器。
一切都清晰了吧。一言以蔽之，@PostConstruct注解后的方法在BeanPostProcessor前置处理器中就被执行了，所以当然要先于InitializingBean和init-method执行了。
最后，给出本文的结论，Bean在实例化的过程中：
Constructor > @PostConstruct > InitializingBean > init-method
标签：封装 schema published 流程 text 机制 正则 ted 静态代理
原文地址：https://www.cnblogs.com/muzinan110/p/11105700.html
