直接注入
@Resource
private ApplicationContext ctx;实现ApplicationContextAware接口
创建一个实体类并实现ApplicationContextAware接口，重写接口内的setApplicationContext方法来完成获取ApplicationContext实例的方法，代码如下所示：
import org.springframework.beans.BeansException;
import org.springframework.context.ApplicationContext;
import org.springframework.context.ApplicationContextAware;
import org.springframework.stereotype.Component;
@Component
public class ApplicationContextProvider
implements ApplicationContextAware
{
/**
* 上下文对象实例
*/
private ApplicationContext applicationContext;
/**
* 实现ApplicationContextAware接口的回调方法，设置上下文环境
*
* @param applicationContext spring上下文对象
* @throws BeansException 抛出spring异常
*/
@Override
public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {
this.applicationContext = applicationContext;
}
/**
* @return ApplicationContext
*/
public ApplicationContext getApplicationContext() {
return applicationContext;
}
/**
* 通过name获取 Bean.
* @param name
* @return
*/
public Object getBean(String name){
return getApplicationContext().getBean(name);
}
/**
* 通过class获取Bean.
* @param clazz
* @param <T>
* @return
*/
public <T> T getBean(Class<T> clazz){
return getApplicationContext().getBean(clazz);
}
/**
* 通过name,以及Clazz返回指定的Bean
* @param name
* @param clazz
* @param <T>
* @return
*/
public <T> T getBean(String name,Class<T> clazz){
return getApplicationContext().getBean(name, clazz);
}
/**
* 如果ioc容器中包含一个与所给名称匹配的bean定义，则返回true否则返回false
*
* @param name ioc容器中注册的bean名称
* @return 存在返回true否则返回false
*/
public boolean containsBean(String name) {
return applicationContext.containsBean(name);
}
}我们拿到ApplicationContext对象实例后就可以手动获取Bean的注入实例对象，在ApplicationContextProvider类内我简单的实现了几个方法来获取指定的Bean实例，当然你可以添加更多的方法来完成更多的业务逻辑。
如果你是想在非Spring管理的实体内使用ApplicationContext还不想采用注入ApplicationContextProvider来完成实例化，这时我们可以修改ApplicationContext实例对象为静态实例，方法改为静态方法，这样在外部同样是可以获取到指定Bean的实例。
这里要注意ApplicationContextProvider类上的@Component注解是不可以去掉的，去掉后Spring就不会自动调用setApplicationContext方法来为我们设置上下文实例。
在自定义AutoConfiguration中获取
有时候我们需要实现自定义的Spring starter，并在自定义的AutoConfiguration中使用ApplicationContext，Spring在初始化AutoConfiguration时会自动传入ApplicationContext，这时我们就可以使用下面的方式来获取ApplicationContext：
@Configuration
@EnableFeignClients("com.yidian.data.interfaces.client")
public class FeignAutoConfiguration {
FeignAutoConfiguration(ApplicationContext context) {
// 在初始化AutoConfiguration时会自动传入ApplicationContext
doSomething(context);
}
}启动时获取ApplicationContext
在启动Spring Boot项目时，需要调用SpringApplication.run方法，而run方法的返回值就是ApplicationContext，我们可以把run方法返回的ApplicationContext对象保存下来，方便随时使用：
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.context.ApplicationContext;
import org.springframework.context.ConfigurableApplicationContext;
@SpringBootApplication
public class WebApplication {
private static ApplicationContext applicationContext;
public static void main(String[] args) {
applicationContext = SpringApplication.run(WebApplication.class, args);
SpringBeanUtil.setApplicationContext(applicationContext);
}
}通过WebApplicationContextUtils获取
Spring提供了一个工具类用于获取ApplicationContext对象：
WebApplicationContextUtils.getRequiredWebApplicationContext(ServletContext sc);
WebApplicationContextUtils.getWebApplicationContext(ServletContext sc);BeanPostProcessor启动时对依赖Bean的“误伤”陷阱
什么是BeanPostProcessor
BeanPostProcessor是Spring的Bean工厂中一个非常重要的钩子，允许Spring框架在新创建Bean实例时对其进行定制化修改。比如我们对Bean内容进行修改、创建代理对象等等~
BeanPostProcessor本身也是一个Bean，一般而言其实例化时机要早过普通的Bean，但是BeanPostProcessor有时也会依赖一些Bean，这就导致了一些普通Bean的实例化早于BeanPostProcessor的可能情况，由此如果使用不当，就会造成一些问题
关于BeanPostProcessor的加载顺序
public static void registerBeanPostProcessors(ConfigurableListableBeanFactory beanFactory, AbstractApplicationContext applicationContext) {
// 注意：此处只会拿到Bean的定义信息~~~~
// 已经被实例化的Bean最终都会调用`beanFactory.addBeanPostProcessor`而缓存在AbstractBeanFactory的字段：beanPostProcessors里，它是个CopyOnWriteArrayList
// 更重要的是：最终最终所有的BeanPostProcessor的执行都会从这个List里面拿出来执行
// 所以这一步很关键：那就是按照顺序，把`BeanPostProcessor`们都实例化好，然后添加进List里
// 因此顺序是关键~~~~~如果某些Bean提前被实例化，它就很有可能不能被所有的`BeanPostProcessor`处理到了
// 这也是我们BeanPostProcessorChecker的作用，它就是检查这个然后输出日志的~
String[] postProcessorNames = beanFactory.getBeanNamesForType(BeanPostProcessor.class, true, false);
// 这个beanProcessorTargetCount此处赋值了，后续就都不会变了，BeanPostProcessorChecker就是和这个进行比较的~
// beanFactory里面的Bean实例总个数+1（自己）+bean定义信息~
int beanProcessorTargetCount = beanFactory.getBeanPostProcessorCount() + 1 + postProcessorNames.length;
// 把BeanPostProcessorChecker加进去，它其实就是做了一个检查而已~~~~~~~输出一个info日志~
beanFactory.addBeanPostProcessor(new BeanPostProcessorChecker(beanFactory, beanProcessorTargetCount));
// 1、找到所有实现PriorityOrdered的`BeanPostProcessor`，然后getBean，然后统一排序，然后beanFactory.addBeanPostProcessor()
// 2、处理实现Ordered的，步骤同上
// 3、处理没实现排序接口的普通的处理器，不需要sort了，直接add进去~
// 最后注册一个特殊的处理器
beanFactory.addBeanPostProcessor(new ApplicationListenerDetector(applicationContext));
}采用@Autowired注入ApplicationContext和实现接口ApplicationContextAware的区别
在绝大多数情况下，这两种使用方式是等价的，都能够方便的获取到Spring容器上下文：ApplicationContext，但是在某些情况下，是有区别的
// 此处实现的是`PriorityOrdered`接口
@Slf4j
@Component
public class MyBeanPostProcessor implements BeanPostProcessor, PriorityOrdered{
@Autowired
private ApplicationContext applicationContext;
...
}这样子注入，最终applicationContext的值为null。为何呢？其实这就和BeanPostProcessor的加载时机以及@Autowired的执行时机有关
ApplicationContextAwareProcessor先实例化，然后执行到registerBeanPostProcessors方法，AutowiredAnnotationBeanPostProcessor、CommonAnnotationBeanPostProcessor、AsyncAnnotationBeanPostProcessor和MyBeanPostProcessor这个我们定义的等待实例化。
AutowiredAnnotationBeanPostProcessor它实现了PriorityOrdered接口CommonAnnotationBeanPostProcessor它也实现了PriorityOrdered接口AsyncAnnotationBeanPostProcessor没有实现任何Orderd排序接口MyBeanPostProcessor此处我们让它实现了PriorityOrdered接口
从上面可以看到，因为实现了PriorityOrdered接口的BeanPostProcessor属于于同一级别，都是先统一调用getBean（）实例化后再被统一addBeanPostProcessor。
因此AutowiredAnnotationBeanPostProcessor这个后置处理器并不能作用在我们的MyBeanPostProcessor上面给我们的属性赋值（因为他俩是同一级别的），因为根本就木有生效
由上可知，我们在注册BeanPostProcessor的时候，他们的优先级的层级原则是需要注意的：高优先级的Bean能够作用于低有衔接的，反之不成立。但是同优先级的Bean不能相互作用~
若是实现ApplicationContextAware接口的话，ApplicationContext不管咋样都可以被正常获取到。道理也是一样的，是因为这个接口是被ApplicationContextAwareProcessor来解析的，而它已经早早被放进了Spring容器里面，所以通过实现接口的方式任何时候都是可以的
注意避免BeanPostProcessor启动时对依赖的Bean造成误伤
BeanPostProcessor实例化时，自动依赖注入根据类型获得需要注入的Bean时，会将某些符合条件的Bean先实例化，如果此FacotryBean又依赖其他普通Bean，会导致该Bean提前启动，造成"误伤"（无法享受部分BeanPostProcessor的后置处理，例如典型的auto-proxy）。
