美文网首页Spring 技术
Spring扩展点(BeanPostProssor)之深度诊断历

Spring扩展点(BeanPostProssor)之深度诊断历

作者: 一帅 | 来源:发表于2019-09-26 07:06 被阅读0次

    阅读本篇文章之前,请先阅读分布式链路追踪系列四(Opentracing实战)以及Spring扩展点总结,然后我们开始我们的历险

    这到底是个什么问题

    我们开发了一个全套的接入全链路的starter框架,供SpringBoot项目使用,上线初期都没什么问题,但是最近有一个项目在使用我们的框架后说Redis没有产生链路数据。


    再具体一点,就是使用Spring Redis组件的链路数据都没有上报成功。那下面我们就来看一下我们是怎么做Spring Redis埋点链路数据的。

    Spring Redis埋点浅析

    直接上代码

    public class RedisTracingBeanPostProcessor implements BeanPostProcessor {
        private Tracer tracer;
    
        private boolean withActiveSpanOnly;
    
        public RedisTracingBeanPostProcessor(Tracer tracer,boolean withActiveSpanOnly) {
            super();
            this.tracer = tracer;
            this.withActiveSpanOnly = withActiveSpanOnly;
        }
    
        @Override
        public Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException {
            if (this.canBeReplaced(bean)) {
                RedisConnectionFactory origin = (RedisConnectionFactory) bean;
               // 替换原生的Spring RedisConnectionFactory 为带有Tracing功能的ConnectionFactory
                return new TracingRedisConnectionFactory(origin, withActiveSpanOnly, this.tracer);
            }
            return bean;
        }
    
        @Override
        public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException {
            return bean;
        }
    
        private boolean canBeReplaced(Object bean) {
            return this.tracer != null && bean instanceof RedisConnectionFactory && !(bean instanceof TracingRedisConnectionFactory);
        }
    }
    

    我们看到最为核心的逻辑就是自定义了Spring的后置处理器BeanPostProcessor来偷偷地替换Spring Redis产生的RedisConnectionFactory 为带有Tracing功能的RedisConnectionFactory 。


    那么很自然地就想到,这个项目之所以没有上报Spring Redis的链路数据,就是因为这个BeanPostProcessor根本没有生效。

    那么问题来了,为什么这个BeanPostProcessor根本没生效呢?


    Spring加载流程浅析

    要弄清楚为什么BeanPostProcessor没有生效,那么我们就必须对Spring整个的加载流程特别清楚才行。那么下面我们就要给Spring趴衣服了,嘿嘿!!!

    由于整个Spring的框架的加载流程及其复杂,我只拿出我们这个问题有关的流程来说一说(只趴外衣,内裤不趴),其他的流程我们这里暂时先忽略。大家有兴趣了解Spring的可以直接去看一下源代码或者学习一下其他大神的源代码解析


    下面,我们就来简单说一下Spring的大体流程,直接上图


    Spring整体流程

    从大体上看Spring容器的加载就分为两个阶段

    1. 通过从XML或者源代码的注解中扫描出所有的BeanDefinition(描述Bean的元数据)
    2. 根据扫描出的所有的BeanDefinition创建Bean

    第一步的实现主要依赖BeanFactoryPostProcessor以及其子接口BeanDefinitionRegistryPostProcessor(Spring自己实现的或者用户自定义的)来实现的

    第二部的实现主要依赖BeanPostProcessor以及其各种子接口,如InstantiationAwareBeanPostProcessor(Spring自己实现的或者用户自定义的)来实现的

    正常情况下,都是按照这个节奏来走的,但是总是有不走寻常路的bean根本不按照套路出牌。如某些BeanPostProcessor。

    由于我们自定义的BeanPostProcessor其实也是归Spring管理的,所以Spring在实例化我们的BeanPostProcessor之前,也会有一个BeanPostProcessor对应的BeanDefinition来描述我们自定义的BeanPostProcessor。而实例化普通Bean的时候需要BeanPostProcessor,所以正常情况下BeanPostProcessor实例化要早于普通的Bean,但是也有特殊情况,当我们自定义的BeanPostProcessor依赖普通Bean的时候,普通bean就会提前实例化。一旦Bean提前实例化,后面Spring就不对对Bean再次实例化,也就享受不到BeanPostProcessor的特殊处理。

    下面我们来简单梳理一下这个过程:

    1.首先我们得知道Spring中创建Bean需要两种原材料,一种就是BeanDefinition,一种就是BeanPostProcessor(当然也包含其子接口及其实现)


    2.BeanPostProcessor及其子接口实现不是一开始就都是Spring中的Bean,它也一样需要经过Spring加载的两个阶段,先要转换为BeanDefinition,然后才能转变为Spring中的对象,然后才能服务于其他Bean的创建过程。


    3.BeanPostProcessor转换为Spring中的Bean的时候有一个固定的顺序,具体如下:


    具体的源代码这里我就不贴了,可以参考PostProcessorRegistrationDelegate类的registerBeanPostProcessors方法,顺便提一句BeanFactoryPostProcessor的处理也很类似。

    4.所以如果有一个BeanPostProcessor中依赖普通的Bean,那么在调用BeanFactory的getBean的时候来生成BeanPostProcessor的时候,BeanPostProcessor依赖的普通的Bean也会在BeanPostProcessor生成之前被调用getBean方法生成Bean。那么Spring容器之后生产BeanPostProcessor的时候,就无法对已经生成的Bean产生任何作用了。

    因此,得出结论

    被PriorityOrderedBeanPostProcessor所依赖的Bean其初始化时无法享受到PriorityOrdered、Ordered、和nonOrdered的BeanPostProcessor的服务。而被OrderedBeanPostProcessor所依赖的Bean无法享受Ordered、和nonOrdered的BeanPostProcessor的服务。最后被nonOrderedBeanPostProcessor所依赖的Bean无法享受到nonOrderedBeanPostProcessor的服务。

    失效原因分析

    我们后来发现,Spring Redis失效的项目中都依赖了Shiro,然后Shiro中定义了一些BeanPostProcessor,并且该BeanPostProcessor简洁依赖了RedisConnectionFactory,那么就导致我们自己的BeanPostProcessor无法替换RedisConnectionFactory。

    问题复现

    由于shiro的环境稍微有点复杂,我们这里就模拟一下这种情况。
    定义接口,模拟RedisConnectionFactory接口

    public interface MyRedisConnectionFactory {
        String getRedisConnection();
    }
    

    给一个默认实现,并且加上注解@Component,加入Spring容器

    @Component
    public class MyRedisConnectionFactoryImpl implements MyRedisConnectionFactory {
        @Override
        public String getRedisConnection() {
            return "MyRedisConnection";
        }
    }
    

    再 模拟一个带Tracing功能的RedisConnectionFactory,注意没有@Component注解

    public class MyTracingRedisConnectionFactoryImpl implements MyRedisConnectionFactory {
        private MyRedisConnectionFactory delegate;
    
        public MyTracingRedisConnectionFactoryImpl(MyRedisConnectionFactory delegate){
            this.delegate = delegate;
        }
    
        @Override
        public String getRedisConnection() {
           // 模拟tracing功能
            return "tracing----------" + delegate.getRedisConnection();
        }
    }
    

    然后定义一个替换RedisConnectionFactory的BeanPostProcessor,注意加上@Component注解

    @Component
    public class MyTracingBeanPostProcessor implements BeanPostProcessor {
        @Override
        public Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException {
            if (bean instanceof MyRedisConnectionFactory && !(bean instanceof MyTracingRedisConnectionFactoryImpl)){
                return new MyTracingRedisConnectionFactoryImpl((MyRedisConnectionFactory)bean);
            }
            return bean;
        }
    
        @Override
        public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException {
            return bean;
        }
    }
    

    然后我们写一个测试类

    @Configuration
    // 注意这里修改为你们自己的包路径
    @ComponentScan("com.example.demo")
    public class DemoApplication {
    
        public static void main(String[] args) {
            AnnotationConfigApplicationContext context = new AnnotationConfigApplicationContext(DemoApplication.class);
            MyRedisConnectionFactory bean = context.getBean(MyRedisConnectionFactory.class);
            System.out.println(bean.getRedisConnection());
        }
    }
    

    下面我我们测试一下,对象却是替换成了MyTracingRedisConnectionFactoryImpl对象



    然后结果也变成了

    tracing----------MyRedisConnection
    

    这个时候一切都正常,下面我们来模拟shiro的情况,加上@Component注解

    @Component
    public class ShiroMockBeanPostProcessor implements BeanPostProcessor {
        
        // 注意这里依赖了MyRedisConnectionFactory 
        @Autowired
        private MyRedisConnectionFactory myRedisConnectionFactory;
    
        @Override
        public Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException {
            return bean;
        }
    
        @Override
        public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException {
            return bean;
        }
    }
    

    这个时候我们再运行一下,发现还是原来的MyRedisConnectionFactoryImpl,并没有替换为MyTracingRedisConnectionFactoryImpl对象。



    运行结果

    MyRedisConnection
    

    至此,我们已经复现了shiro的场景,并且也已经复现了问题,也证实了我们上面的分析过程。

    怎么解决呢

    • 修改BeanPostProcessor的order顺序
    • 不共享对象。即两个BeanPostProcessor依赖不同的对象。
    • 懒加载。+@Lazy注解

    相关阅读

    BeanPostProcessor加载次序及其对Bean造成的影响分析
    【小家Spring】注意BeanPostProcessor启动时对依赖Bean的“误伤”陷阱(is not eligible for getting processed by all...)

    相关文章

      网友评论

        本文标题:Spring扩展点(BeanPostProssor)之深度诊断历

        本文链接:https://www.haomeiwen.com/subject/gihdyctx.html