Bean工厂（com.springframework.beans.factory.BeanFactory）是Spring框架最核心的接口，它提供了高级IoC的配置机制。BeanFactory使管理不同类型的Java对象成为可能，应用上下文（com.springframework.context.ApplicationContext）建立在BeanFactory基础之上，提供了更多面向应用的功能，它提供了国际化支持和框架事件体系，更易于创建实际应用。我们一般称BeanFactory为IoC容器，而称ApplicationContext为应用上下文。但有时为了行文方便，我们也将ApplicationContext称为Spring容器。 对于两者的用途，我们可以进行简单划分：BeanFactory是Spring框架的基础设施，面向Spring本身；ApplicationContext面向使用Spring框架的开发者，几乎所有的应用场合我们都直接使用ApplicationContext而非底层的BeanFactory。 ApplicationContext的初始化和BeanFactory有一个重大的区别：BeanFactory在初始化容器时，并未实例化Bean，直到第一次访问某个Bean时才实例目标Bean；而ApplicationContext则在初始化应用上下文时就实例化所有单实例的Bean。因此ApplicationContext的初始化时间会比BeanFactory稍长一些 要获取XML中配置的Bean，最关键的是获取.springframework.context.ApplicationContext，以下是总结的几种方法 方法一：在初始化时保存ApplicationContext对象方法二：通过Spring提供的utils类获取ApplicationContext对象方法三：继承自抽象类ApplicationObjectSupport方法四：继承自抽象类WebApplicationObjectSupport方法五：实现接口ApplicationContextAware方法六：通过Spring提供的ContextLoader 方法一：在初始化时保存ApplicationContext对象 说明：这种方式适用于采用Spring框架的独立应用程序，需要程序通过配置文件手工初始化Spring的情况。说明：这种方式适用于采用Spring框架的独立应用程序，需要程序通过配置文件手工初始化Spring的情况。 方法二：通过Spring提供的工具类获取ApplicationContext对象 说明：这种方式适合于采用Spring框架的B/S系统，通过ServletContext对象获取ApplicationContext对象，然后在通过它获取需要的类实例。上面两个工具方式的区别是，前者在获取失败时抛出异常，后者返回null。 方法三：继承自抽象类ApplicationObjectSupport 说明：抽象类ApplicationObjectSupport提供getApplicationContext()方法，可以方便的获取ApplicationContext。 Spring初始化时，会通过该抽象类的setApplicationContext(ApplicationContext context)方法将ApplicationContext 对象注入。 方法四：继承自抽象类WebApplicationObjectSupport 说明：类似上面方法，调用getWebApplicationContext()获取WebApplicationContext 方法五：实现接口ApplicationContextAware（推荐） 说明：实现该接口的setApplicationContext(ApplicationContext context)方法，并保存ApplicationContext 对象。Spring初始化时，会通过该方法将ApplicationContext对象注入。 以下是实现ApplicationContextAware接口方式的代码，前面两种方法类似： 虽然，spring提供的后三种方法可以实现在普通的类中继承或实现相应的类或接口来获取spring 的ApplicationContext对象，但是在使用是一定要注意实现了这些类或接口的普通java类一定要在Spring 的配置文件applicationContext.xml文件中进行配置。否则获取的ApplicationContext对象将为null。 方法六：通过Spring提供的ContextLoader（有使用条件） 最后提供一种不依赖于servlet,不需要注入的方式。但是需要注意一点，在服务器启动时，Spring容器初始化时，不能通过以下方法获取Spring 容器，细节可以查看spring源码org.springframework.web.context.ContextLoader。 方法七：实现接口BeanFactoryAware（与ApplicationContextAware类似） 自定义一个工具类，实现自BeanFactoryAware接口，接口的方法是setBeanFactory，我们实现它，并让其为我们服务，因为Spring在load自己的时候会将上下文环境填充进来。 题外：

转：https://mp.weixin.qq.com/s/n4BKECgc5lFPM8LX6OTOqQ # 概要 **** Spring实现了一套重试机制，功能简单实用。Spring Retry是从Spring Batch独立出来的一个功能，已经广泛应用于Spring Batch,Spring Integration, Spring for Apache Hadoop等Spring项目。本文将讲述如何使用Spring Retry及其实现原理。 # 背景 **** 重试，其实我们其实很多时候都需要的，为了保证容错性，可用性，一致性等。一般用来应对外部系统的一些不可预料的返回、异常等，特别是网络延迟，中断等情况。还有在现在流行的微服务治理框架中，通常都有自己的重试与超时配置，比如dubbo可以设置retries=1，timeout=500调用失败只重试1次，超过500ms调用仍未返回则调用失败。 如果我们要做重试，要为特定的某个操作做重试功能，则要硬编码，大概逻辑基本都是写个循环，根据返回或异常，计数失败次数，然后设定退出条件。这样做，且不说每个操作都要写这种类似的代码，而且重试逻辑和业务逻辑混在一起，给维护和扩展带来了麻烦。从面向对象的角度来看，我们应该把重试的代码独立出来。 # 使用介绍 **** 基本使用 先举个例子： @EnableRetry – 表示开启重试机制 @Retryable – 表示这个方法需要重试，它有很丰富的参数，可以满足你对重试的需求 @Backoff – 表示重试中的退避策略 @Recover – 兜底方法，即多次重试后还是失败就会执行这个方法 Spring-Retry 的功能丰富在于其重试策略和退避策略，还有兜底，监听器等操作。 然后每个注解里面的参数，都是很简单的，大家看一下就知道是什么意思，怎么用了，我就不多讲了。 重试策略 看一下Spring Retry自带的一些重试策略，主要是用来判断当方法调用异常时是否需要重试。（下文原理部分会深入分析实现） SimpleRetryPolicy 默认最多重试3次 TimeoutRetryPolicy 默认在1秒内失败都会重试 ExpressionRetryPolicy 符合表达式就会重试 CircuitBreakerRetryPolicy 增加了熔断的机制，如果不在熔断状态，则允许重试 CompositeRetryPolicy 可以组合多个重试策略 NeverRetryPolicy 从不重试（也是一种重试策略哈） AlwaysRetryPolicy […]

# 注解(annotations)列表 **** @SpringBootApplication： 包含了@ComponentScan、@Configuration和@EnableAutoConfiguration注解。其中@ComponentScan让spring Boot扫描到Configuration类并把它加入到程序上下文。 @Configuration 等同于spring的XML配置文件；使用Java代码可以检查类型安全。 @EnableAutoConfiguration 自动配置。 @ComponentScan 组件扫描，可自动发现和装配一些Bean。 @Component 可配合CommandLineRunner使用，在程序启动后执行一些基础任务。 @RestController 注解是@Controller和@ResponseBody的合集,表示这是个控制器bean,并且是将函数的返回值直 接填入HTTP响应体中,是REST风格的控制器。 @Autowired 自动导入。 @PathVariable 获取参数。 @JsonBackReference 解决嵌套外链问题。 @RepositoryRestResourcepublic 配合spring-boot-starter-data-rest使用。 # 注解(annotations)详解 **** @SpringBootApplication： 申明让spring boot自动给程序进行必要的配置，这个配置等同于：@Configuration ，@EnableAutoConfiguration 和 @ComponentScan 三个配置。 @ResponseBody： 表示该方法的返回结果直接写入HTTP response body中，一般在异步获取数据时使用，用于构建RESTful的api。在使用@RequestMapping后，返回值通常解析为跳转路径，加上@responsebody后返回结果不会被解析为跳转路径，而是直接写入HTTP response body中。 比如异步获取json数据，加上@responsebody后，会直接返回json数据。该注解一般会配合@RequestMapping一起使用。 示例代码： @Controller： 用于定义控制器类，在spring 项目中由控制器负责将用户发来的URL请求转发到对应的服务接口（service层），一般这个注解在类中，通常方法需要配合注解@RequestMapping。 示例代码： @RestController： 用于标注控制层组件(如struts中的action)，@ResponseBody和@Controller的合集。 示例代码： @RequestMapping： 提供路由信息，负责URL到Controller中的具体函数的映射。 @EnableAutoConfiguration：Spring Boot自动配置（auto-configuration）：尝试根据你添加的jar依赖自动配置你的Spring应用。例如，如果你的classpath下存在HSQLDB，并且你没有手动配置任何数据库连接beans，那么我们将自动配置一个内存型（in-memory）数据库”。 你可以将@EnableAutoConfiguration或者@SpringBootApplication注解添加到一个@Configuration类上来选择自动配置。如果发现应用了你不想要的特定自动配置类，你可以使用@EnableAutoConfiguration注解的排除属性来禁用它们。 […]

我们经常需要在容器启动的时候做一些钩子动作，比如注册消息消费者，监听配置等，今天就总结下 SpringBoot 留给开发者的 7 个启动扩展点。 容器刷新完成扩展点 **** 1.1 监听容器刷新完成扩展点 ApplicationListener 基本用法 熟悉 Spring 的同学一定知道，容器刷新成功意味着所有的 Bean 初始化已经完成，当容器刷新之后Spring将会调用容器内所有实现了ApplicationListener的Bean的 onApplicationEvent 方法，应用程序可以以此达到监听容器初始化完成事件的目的。 易错的点 这个扩展点用在 web 容器中的时候需要额外注意，在 web 项目中（例如 spring mvc），系统会存在两个容器，一个是 root application context,另一个就是我们自己的 context（作为 root application context 的子容器）。如果按照上面这种写法，就会造成 onApplicationEvent 方法被执行两次。解决此问题的方法如下： 高阶玩法 当然这个扩展还可以有更高阶的玩法：自定义事件，可以借助 Spring 以最小成本实现一个观察者模式： 先自定义一个事件： 注册一个事件监听器 发布事件 执行单元测试可以看到邮件的地址和内容都被打印出来了 1.2 SpringBoot 的 CommandLineRunner 接口 当容器上下文初始化完成之后，SpringBoot 也会调用所有实现了 CommandLineRunner 接口的 run 方法，下面这段代码可起到和上文同样的作用： […]