【小家Spring】注意BeanPostProcessor启动时对依赖Bean的“误伤”陷阱(is not eligible for getting processed by all...)(下)

本文涉及的产品
日志服务 SLS,月写入数据量 50GB 1个月
简介: 【小家Spring】注意BeanPostProcessor启动时对依赖Bean的“误伤”陷阱(is not eligible for getting processed by all...)(下)

采用@Autowired注入ApplicationContext和实现接口ApplicationContextAware的区别

在绝大多数情况下,这两种使用方式是等价的,都能够方便的获取到Spring容器上下文:ApplicationContext,但是在某些情况下,是有区别的,比如在如下情况下:


// 和上面唯一区别是 此处实现的是`PriorityOrdered`接口,上面就是普通的Ordered接口
@Slf4j
@Component
public class MyBeanPostProcessor implements BeanPostProcessor, PriorityOrdered{
  @Autowired
    private ApplicationContext applicationContext;
    ...
}


这样子注入,最终applicationContext的值为null。为何呢?其实这就和BeanPostProcessor的加载时机以及@Autowired的执行时机有关,下面通过两张截图可以清晰的看到顺序:

此图表示执行到此处,容器内已经存在的BeanPostProcessor实例(注意已经是实例):

image.png


此图表示BeanPostProcessor的定义信息们,他们等待被实例化:


image.png


下面对此几个BeanPostProcessor的Bean定义信息做分析如下:


  • AutowiredAnnotationBeanPostProcessor它实现了PriorityOrdered接口
  • CommonAnnotationBeanPostProcessor它也实现了PriorityOrdered接口
  • AsyncAnnotationBeanPostProcessor没有实现任何Orderd排序接口
  • MyBeanPostProcessor此处我们让它实现了PriorityOrdered接口===========


从上面可以看到,因为实现了PriorityOrdered接口的BeanPostProcessor属于于同一级别,都是先统一调用getBean()实例化后再被统一addBeanPostProcessor。


因此AutowiredAnnotationBeanPostProcessor这个后置处理器并不能作用在我们的MyBeanPostProcessor上面给我们的属性赋值(因为他俩是同一级别的),因为根本就木有生效嘛~~~~但是像我们第一个例子,MyBeanPostProcessor只是实现了普通的Ordered接口,优先级比PriorityOrdered低,所以就实现了正常的注入(因为高优先级的处理器先辈实例化了,所以可以作用于低优先级的bean了)~


由上可知,我们在注册BeanPostProcessor的时候,他们的优先级的层级原则是需要注意的:高优先级的Bean能够作用于低有衔接的,反之不成立。但是同优先级的Bean不能相互作用~


若是实现ApplicationContextAware接口的话,ApplicationContext不管咋样都可以被正常获取到。道理也是一样的,是因为这个接口是被ApplicationContextAwareProcessor来解析的,而它已经早早被放进了Spring容器里面,所以通过实现接口的方式任何时候都是阔仪的


那平时到底使用@Autowired注入还是实现接口ApplicationContextAware呢?

建议平时能够使用@Autowired注入时(我更建议使用构造器注入,这样完全不与Spring容器耦合),就尽量使用注入的方式。而不是去实现实现ApplicationContextAware接口的方式,因为这种方式属于与Spring容器强耦合的方式。(当然非常特殊情况下,只能使用ApplicationContextAware,比如上面那个情况)


@Async异步注解失效得原因


相信到了此处,@Async失效的原因已经不用再详细阐述一遍了。简单的说就是因为HelloService该Bean被提前初始化了,而这个时候AsyncAnnotationBeanPostProcessor根本就还没起作用(因为它仅仅是一个普通的BeanPostProcessor,加载是靠后的),所以肯定也就不能扫描到@Async这种`注解方法,从而就不能生成代理对象,那就自然而然就失效了~


想说明的是,本文说明的是一类问题,而不是@Async这一个问题,请大家能够举一反三


关于BeanPostProcessorChecker

首先它是一个BeanPostProcessor,是PostProcessorRegistrationDelegate的一个private static内部类,它的作用就是在postProcessAfterInitialization里检查作用在此Bean上的BeanPostProcessor够不够数,如果不够数(一般是提前加载了,或者被auto-proxying了这种情况就输出一条info日志~~~)

  private static final class BeanPostProcessorChecker implements BeanPostProcessor {
    private static final Log logger = LogFactory.getLog(BeanPostProcessorChecker.class);
    // 从if条件可以看出哪些是不需要检测的Bean
    // 1、BeanPostProcessor类型不检测
    // 2、ROLE_INFRASTRUCTURE这种类型的Bean不检测 (Spring自己的Bean)
    @Override
    public Object postProcessAfterInitialization(Object bean, String beanName) {
      if (!(bean instanceof BeanPostProcessor) && !isInfrastructureBean(beanName) &&
          this.beanFactory.getBeanPostProcessorCount() < this.beanPostProcessorTargetCount) {
        if (logger.isInfoEnabled()) {
          logger.info("Bean '" + beanName + "' of type [" + bean.getClass().getName() +
              "] is not eligible for getting processed by all BeanPostProcessors " +
              "(for example: not eligible for auto-proxying)");
        }
      }
      return bean;
    }
    private boolean isInfrastructureBean(@Nullable String beanName) {
      if (beanName != null && this.beanFactory.containsBeanDefinition(beanName)) {
        BeanDefinition bd = this.beanFactory.getBeanDefinition(beanName);
        return (bd.getRole() == RootBeanDefinition.ROLE_INFRASTRUCTURE);
      }
      return false;
    }
  }


如果你的bean被提前加载了,那就会看到这么一条日志:


Bean 'XXX' of type [XXXX] is not eligible for getting processed by all BeanPostProcessors (for example: not eligible for auto-proxying)


比如我们项目中使用到了Feign面向接口进行远程调用,每次项目启动的时候,就会输出大量的类似日志,如下图:


image.png

Tips:

一般的如果你的Config类是一个XXXConfigurer的扩展配置类,也会打印类似的消息:

o.s.c.s.PostProcessorRegistrationDelegate$Be



根本原因也是上面说的。具体到代码这里简单分析一下(此处以AsyncConfigurer为例):

// 在对它(AsyncAnnotationBeanPostProcessor)进行实例化的时候(它是个BeanPostProcessor,所以会根据bean定义进行getBean())
// 所以就必须先实例化它@Bean所在的类:
@Configuration
@Role(BeanDefinition.ROLE_INFRASTRUCTURE)
public class ProxyAsyncConfiguration extends AbstractAsyncConfiguration {
  @Bean(name = TaskManagementConfigUtils.ASYNC_ANNOTATION_PROCESSOR_BEAN_NAME)
  @Role(BeanDefinition.ROLE_INFRASTRUCTURE)
  public AsyncAnnotationBeanPostProcessor asyncAdvisor() { ... }
}
// 然后它的父类`AbstractAsyncConfiguration`里有个@Autowired方法:
@Configuration
public abstract class AbstractAsyncConfiguration implements ImportAware {
  @Autowired(required = false)
  void setConfigurers(Collection<AsyncConfigurer> configurers) { ... }
}
// 这个依赖注入就会去容器内找所有的`AsyncConfigurer`的实现,所以就把`AsyncConfig`给提前实例化了
// 所以打印了那么一句日志,不要感觉到惊奇。这也是为何spring这个checker里使用的日志级别是Info,而不是debug,更不是worn。
// 因为它Spring认为这个debug太轻了,但是warn又太重了,因为绝大部分情况下它都不影响程序的正常work~


注意避免BeanPostProcessor启动时对依赖的Bean造成误伤


BeanPostProcessor实例化时,自动依赖注入根据类型获得需要注入的Bean时,会将某些符合条件的Bean先实例化,如果此FacotryBean又依赖其他普通Bean,会导致该Bean提前启动,造成"误伤"(无法享受部分BeanPostProcessor的后置处理,例如典型的auto-proxy)。

相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
相关文章
|
10天前
|
缓存 Java Spring
实战指南:四种调整 Spring Bean 初始化顺序的方案
本文探讨了如何调整 Spring Boot 中 Bean 的初始化顺序,以满足业务需求。文章通过四种方案进行了详细分析: 1. **方案一 (@Order)**:通过 `@Order` 注解设置 Bean 的初始化顺序,但发现 `@PostConstruct` 会影响顺序。 2. **方案二 (SmartInitializingSingleton)**:在所有单例 Bean 初始化后执行额外的初始化工作,但无法精确控制特定 Bean 的顺序。 3. **方案三 (@DependsOn)**:通过 `@DependsOn` 注解指定 Bean 之间的依赖关系,成功实现顺序控制,但耦合性较高。
实战指南:四种调整 Spring Bean 初始化顺序的方案
|
1月前
|
XML Java 数据格式
Spring从入门到入土(bean的一些子标签及注解的使用)
本文详细介绍了Spring框架中Bean的创建和使用,包括使用XML配置文件中的标签和注解来创建和管理Bean,以及如何通过构造器、Setter方法和属性注入来配置Bean。
66 9
Spring从入门到入土(bean的一些子标签及注解的使用)
|
28天前
|
Java 测试技术 Windows
咦!Spring容器里为什么没有我需要的Bean?
【10月更文挑战第11天】项目经理给小菜分配了一个紧急需求,小菜迅速搭建了一个SpringBoot项目并完成了开发。然而,启动测试时发现接口404,原因是控制器包不在默认扫描路径下。通过配置`@ComponentScan`的`basePackages`字段,解决了问题。总结:`@SpringBootApplication`默认只扫描当前包下的组件,需要扫描其他包时需配置`@ComponentScan`。
|
2月前
|
XML Java 数据格式
Spring IOC—基于XML配置Bean的更多内容和细节(通俗易懂)
Spring 第二节内容补充 关于Bean配置的更多内容和细节 万字详解!
210 18
Spring IOC—基于XML配置Bean的更多内容和细节(通俗易懂)
|
2月前
|
XML Java 数据格式
spring复习02,xml配置管理bean
详细讲解了Spring框架中基于XML配置文件管理bean的各种方式,包括获取bean、依赖注入、特殊值处理、属性赋值、集合类型处理、p命名空间、bean作用域及生命周期和自动装配。
spring复习02,xml配置管理bean
|
1月前
|
监控 Java 开发者
BeanPostProcessor:Spring框架的灵活扩展机制
【10月更文挑战第4天】在Spring框架中,BeanPostProcessor接口是一个非常重要的扩展点,它允许开发者在Spring容器实例化、依赖注入以及初始化Bean的过程中插入自定义逻辑。
60 0
|
1月前
|
Java 开发者 Spring
Spring bean的生命周期详解!
本文详细解析Spring Bean的生命周期及其核心概念,并深入源码分析。Spring Bean是Spring框架的核心,由容器管理其生命周期。从实例化到销毁,共经历十个阶段,包括属性赋值、接口回调、初始化及销毁等。通过剖析`BeanFactory`、`ApplicationContext`等关键接口与类,帮助你深入了解Spring Bean的管理机制。希望本文能助你更好地掌握Spring Bean生命周期。
72 1
|
1月前
|
Java Spring
获取spring工厂中bean对象的两种方式
获取spring工厂中bean对象的两种方式
37 1
|
1月前
|
Java 开发者 Spring
Spring bean的生命周期详解!
本文详细介绍了Spring框架中的核心概念——Spring Bean的生命周期,包括实例化、属性赋值、接口回调、初始化、使用及销毁等10个阶段,并深入剖析了相关源码,如`BeanFactory`、`DefaultListableBeanFactory`和`BeanPostProcessor`等关键类与接口。通过理解这些核心组件,读者可以更好地掌握Spring Bean的管理和控制机制。
84 1
|
2月前
|
缓存 Java Spring
手写Spring Ioc 循环依赖底层源码剖析
在Spring框架中,IoC(控制反转)是一个核心特性,它通过依赖注入(DI)实现了对象间的解耦。然而,在实际开发中,循环依赖是一个常见的问题。
40 4