DependsOn注解失效问题排查

已于 2023-10-09 08:19:13 修改
阅读量1k 收藏 1
点赞数
分类专栏： 工作中遇到的问题 spring 源码分析 文章标签： spring 源码分析
于 2023-10-08 20:14:33 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/liangsheng_g/article/details/133686498
版权

文章目录

前言

最近几天遇到一个比较有意思的问题，发现Spring的DependsOn注解失效，令我大为费解。经过一段排查，还是有收获的，记录下来，自己警醒，也给大家避雷。
为了去掉敏感信息，本文所有代码均为示例，并不是实际线上代码！！！

一、现象描述

现象复现版本

Java：Java8；Spring：Spring5.3.7

1.1.背景描述

我们实例化某个对象时，需要从配置中心热加载里获取某个属性，使得对象初始化时获取配置中心的数据，形如：

public class MyProxy implements FactoryBean {

    private Class<?> proxyClass;

    public void setProxyClass(Class<?> proxyClass) {
        this.proxyClass = proxyClass;
    }

    @Override
    public Object getObject() throws Exception {
        return proxyClass.newInstance();
    }

    @Override
    public Class<?> getObjectType() {
        return proxyClass;
    }
}



@Configuration
public class ProxyConfig {

    @Bean
    public MyProxy proxyService1() {
        System.out.println("init proxyService1");
        MyProxy proxy = new MyProxy();
        proxy.setProxyClass(ProxyService1.class);
        proxy.setInfo(MyConfig.info);
        return proxy;
    }

    @Bean(name = "myConfig", initMethod = "init", destroyMethod = "destroy")
    public MyConfig myConfig() {
        return new MyConfig();
    }
}

myConfig实例化之后会调用init方法，从远程的配置中心拉取配置信息，将MyConfig类里的变量值进行设置；理想情况，在proxyService1()方法执行，并执行实例化的时候读取到的MyConfig.info应该是配置中心里配置的值，而不是MyConfig类里定义的info初始化值。
Test环境验证了一下，可以读取到配置中心的值，就美滋滋的上线了。
结果，线上验收时，没有生效！！！！

1.2.第一次修改，使用DependsOn注解

猜测了下原因，因为Spring实例化对象的顺序并不能保证每次运行都一致，也不能保证不同环境实例化对象顺序一致，所以线上应该是先执行了proxyService1()，后执行了myConfig();这样的话proxyService1()执行的时候读取不到配置中心配置的info的值。
猜测到原因之后，进行了以下的改动，加了DependsOn注解，强制这俩方法的运行顺序

@Configuration
public class ProxyConfig {

    @Bean
    @DependsOn("myConfig")
    public MyProxy proxyService1() {
        System.out.println("init proxyService1");
        MyProxy proxy = new MyProxy();
        proxy.setProxyClass(ProxyService1.class);
        proxy.setInfo(MyConfig.info);
        return proxy;
    }

    @Bean(name = "myConfig", initMethod = "init", destroyMethod = "destroy")
    public MyConfig myConfig() {
        return new MyConfig();
    }
}

Test环境验证了一下，可以读取到配置中心的值，就美滋滋的上线了。
结果，不出意外的情况下又出意外，线上验收时，没有生效！！！！

1.3.第二次修改，设置方法入参

这次我修改了proxyService1方法的入参，强制执行时使用myConfig对象

@Configuration
public class ProxyConfig {

    @Bean
    public MyProxy proxyService1(MyConfig myConfig) {
        System.out.println("init proxyService1");
        MyProxy proxy = new MyProxy();
        proxy.setProxyClass(ProxyService1.class);
        proxy.setInfo(MyConfig.info);
        return proxy;
    }

    @Bean(name = "myConfig", initMethod = "init", destroyMethod = "destroy")
    public MyConfig myConfig() {
        return new MyConfig();
    }
}

所幸这次成功了
但是，这是为啥呢？

二、看看源码

2.1.Spring实例化的源码

众所周知，按照咱们的理解，Spring不管怎样，要基于某个definition实例化某个对象的时候，都需要调用AbstractBeanFactory下的getBean方法，最终会调用doGetBean方法，此处为了显眼，我们就直接放截图，不相干的逻辑暂时折叠：
DependsOn注解生效逻辑
实在找不到原因，只好调试源码了。

2.2.调试

我们给proxyService1方法增加断点，发现比较奇怪的是，其他实例进行属性注入的时候，会调用该方法。进一步查看，发现它是通过SimpleInstantiationStrategy类里的instantiate方法进行实例化的，没有调用getBean方法，也就没有解析DependsOn注解
FactoryMethod实例化
FactoryMethod是指加了@Bean注解的方法

那么问题来了，其他service相互注入，并不是注入proxyService1，为什么会调用该factoryMethod呢？？？
看看调用栈来剖析下吧~
让我们回顾这两篇文章：

  1. @Resource注解的逻辑
  2. @Autowired注解的逻辑
    不管是使用@Resource注解还是@Autowired注解，多数情况都会进入到根据类型进行注入，可以看上面两篇博客。
    不过在上面两篇博客，我们没有详细分析，根据类型查找可用对象的逻辑，也就是findAutowireCandidates方法中的
String[] candidateNames = BeanFactoryUtils.beanNamesForTypeIncludingAncestors(
				this, requiredType, true, descriptor.isEager());

不过，我们先stop一下，如果我们是Spring的开发者，我们该如何来写这个根据类型查找可用实例的逻辑？？？

3. 普通加了@Service或者@Component注解的类型，直接用它的类型
4. 加了@Bean的FactoryMethod的方法，根据方法返回值的类型

但是如果是FactoryBean呢？？？
我们的MyProxy类就是一个FactoryBean！！！！

  1. 加了@Service、@Component注解，那我们应该会是根据FactoryBean里的泛型或者接口方法getObjectType来判断类型
  2. @Bean的返回值是FactoryBean，那我们根据方法返回值的泛型来判断。
    感性认知的话，我们都会这么干，那我们看看Spring是怎么干的，而且像我们MyProxy这种没有指定FactoryBean的泛型的实现，Spring又是如何处理的呢？
在DefaultListableBeanFactory#doGetBeanNamesForType方法里，遍历所有的beanDefinition，查找beanDefinition的类型
在AbstractBeanFactory的isTypeMatch方法，调用了getTypeForFactoryBean

我们具体来读一下getTypeForFactoryBean方法的逻辑

protected ResolvableType getTypeForFactoryBean(String beanName, RootBeanDefinition mbd, boolean allowInit) {
		
		// ....不重要的逻辑先忽略

		// Consider factory methods
		String factoryBeanName = mbd.getFactoryBeanName();
		String factoryMethodName = mbd.getFactoryMethodName();

		// Scan the factory bean methods
		if (factoryBeanName != null) {
			if (factoryMethodName != null) {
				// Try to obtain the FactoryBean's object type from its factory method
				// declaration without instantiating the containing bean at all.
				BeanDefinition factoryBeanDefinition = getBeanDefinition(factoryBeanName);
				Class<?> factoryBeanClass;
				if (factoryBeanDefinition instanceof AbstractBeanDefinition &&
						((AbstractBeanDefinition) factoryBeanDefinition).hasBeanClass()) {
					factoryBeanClass = ((AbstractBeanDefinition) factoryBeanDefinition).getBeanClass();
				}
				else {
					RootBeanDefinition fbmbd = getMergedBeanDefinition(factoryBeanName, factoryBeanDefinition);
					factoryBeanClass = determineTargetType(factoryBeanName, fbmbd);
				}
				if (factoryBeanClass != null) {
				// 这个方法很重要，就是解析返回值是FactoryBean的方法，实际交给Spring容器的对象类型
				// 而我们的MyProxy在实现FactoryBean时没有指定泛型，导致此处返回的result是个？
				// 所以result.resolve()是个null
					result = getTypeForFactoryBeanFromMethod(factoryBeanClass, factoryMethodName);
					if (result.resolve() != null) {
						return result;
					}
				}
			}
			// If not resolvable above and the referenced factory bean doesn't exist yet,
			// exit here - we don't want to force the creation of another bean just to
			// obtain a FactoryBean's object type...
			if (!isBeanEligibleForMetadataCaching(factoryBeanName)) {
				return ResolvableType.NONE;
			}
		}

		// If we're allowed, we can create the factory bean and call getObjectType() early
		if (allowInit) {
			FactoryBean<?> factoryBean = (mbd.isSingleton() ?
					getSingletonFactoryBeanForTypeCheck(beanName, mbd) :
					getNonSingletonFactoryBeanForTypeCheck(beanName, mbd));
			if (factoryBean != null) {
				// Try to obtain the FactoryBean's object type from this early stage of the instance.
				// 执行了FactoryBean的方法，获取到FactoryBean的实例后，再调用其getObjectType获取真正的返回类型
				Class<?> type = getTypeForFactoryBean(factoryBean);
				if (type != null) {
					return ResolvableType.forClass(type);
				}
				// No type found for shortcut FactoryBean instance:
				// fall back to full creation of the FactoryBean instance.
				return super.getTypeForFactoryBean(beanName, mbd, true);
			}
		}
//不重要的逻辑先忽略
	}

可以看到上面的注释写的是先根据getTypeForFactoryBeanFromMethod查找返回值是FactoryBean时方法的实际要交给Spring容器管理对象的类型，如果查找不到，会调用getSingletonFactoryBeanForTypeCheck方法进行FactoryMethod的实例化。也就是会最终调用SimpleInstantiationStrategy类里的instantiate方法，而不是getBean方法进行实例化，也就忽略了DependsOn注解的处理逻辑。

2.3.验证

为了验证上述逻辑，我们新增了指定了FactoryBean泛型的类ProxyFactoryBean和可以在方法调用时指定FactoryBean泛型的MyFactoryBean

public class ProxyFactoryBean implements FactoryBean<ProxyService3> {
    @Override
    public ProxyService3 getObject() throws Exception {
        return ProxyService3.class.newInstance();
    }

    @Override
    public Class<?> getObjectType() {
        return ProxyService3.class;
    }
}

public class MyFactoryBean<T> implements FactoryBean<T> {

    private Class<T> proxyClass;

    public void setProxyClass(Class<T> proxyClass) {
        this.proxyClass = proxyClass;
    }

    @Override
    public T getObject() throws Exception {
        return proxyClass.newInstance();
    }

    @Override
    public Class<T> getObjectType() {
        return proxyClass;
    }
}

然后我们重写ProxyConfig类

@Configuration
public class ProxyConfig {

    @Bean
    @Lazy
    public MyProxy proxyService1() {
        System.out.println("init proxyService1");
        MyProxy proxy = new MyProxy();
        proxy.setProxyClass(ProxyService1.class);
        return proxy;
    }

    @Bean
    @Lazy
    // 注意看此处，指定了方法返回值的泛型
    public MyFactoryBean<ProxyService2> proxyService2() {
        System.out.println("init proxyService2");
        MyFactoryBean<ProxyService2> proxy = new MyFactoryBean<>();
        proxy.setProxyClass(ProxyService2.class);
        return proxy;
    }

    @Bean
    @Lazy
    public ProxyFactoryBean proxyService3() {
        System.out.println("init proxyService3");
        return new ProxyFactoryBean();
    }

    @Bean
    @Lazy
    public MyRealService myRealService() {
        System.out.println("init myRealService");
        return new MyRealService();
    }

}

我们的四个对象都没有作为其他对象的属性注入，且都加了@Lazy。理论上应该所有FactoryMethod都不会被调用实例化。我们运行一下看看：
实验结果
同样是FactoryBean，不管是类型定义时指定了泛型的ProxyFactoryBean还是在方法实现时指定了方法返回值的MyFactoryBean，都没有被启动。只有MyProxy，在其他属性注入时会被强制启动。

如果我们把MyFactoryBean的方法返回值的泛型去掉呢？？？

	@Bean
    @Lazy
    // 参见此处，我们虽然在方法实现里面指定了MyFactoryBean的proxyClass，但是方法返回值没有明确泛型
    public MyFactoryBean proxyService2() {
        System.out.println("init proxyService2");
        MyFactoryBean<ProxyService2> proxy = new MyFactoryBean<>();
        proxy.setProxyClass(ProxyService2.class);
        return proxy;
    }

实验结果2
可以看到，当FactoryMethod如果通过编译的class信息没有办法分析出FactoryBean返回的实际类型时，该FactoryMethod就会被执行，然后调用FactoryBean实例的getObjectType，以便让Spring确认其真实的返回值类型。

结果实验结果我们可以发现，也就是当放入到spring容器中的对象类型不明确时，就会被调用，不管它是不是Lazy的，而且调用的时候也是直接通过反射调用该方法，不处理其DependsOn注解

总结

尽量不要使得放入到spring容器中的对象类型不明确！！！
但是有时候也不可避免，譬如本人发现该类型的案例是由于公司的rpc组件导致的，利用不明确的FactoryBean实现类，设置不同的对象，来进行rpc的proxy对象生成。

liangsheng_g
关注
  • 0
    点赞
  • 踩
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
spring depends-on 不起作用
weixin_30794499的博客
08-18 1911
beans-realation.xml <?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" x...
SpringBoot教程(9) @DependsOn 设置Bean依赖 结合@Lazy 修改Bean加载顺序
Java Spring Elasticsearch
03-18 7831
@DependsOn 设置Bean依赖 结合@Lazy 修改Bean加载顺序一、需要@DependsOn的场景二、实验示例1. Teacher类2. LateStudent类3. 配置类4. 测试类5. 添加@DependsOn，设置依赖关系三、用@Lazy懒加载1. 用@Lazy方式让学生在后面加载四、@DependsOn和@Lazy都存在的情况1. 假设被依赖的Teacher用了@Lazy 一、需要@DependsOn的场景 在开发中，如果有2个类A和B，且B要监听A，则希望B在A之前加载到容器中。 但
docker-compose配置depends_on无法解决启动顺序问题解决方案
Happywzy~的博客
11-10 5374
问题 docker-compose配置容器启动顺序,有时依靠depends_on并不能完全解决,主要原因是: depends_on只能保证容器进入了running状态,而不保证进入ready状态. Control startup and shutdown order in Compose 解决方案 启动命令前增加判断依赖服务状态的工具 wait-for-it dockerize wait-for 示例: version: "2" services: web: build: . p
docker-compose中解决depends_on无效问题
llf_cloud的博客
05-14 1万+
熊丸子 发布于 2020-01-06 背景 最近在写一个即时聊天程序的DEMO，技术栈差不多是vue+nodejs+redis+rabbitmq,里面有用到rabbitmq来处理消息列队，程序写好后，我用docker-compose做了个镜像，日后好给别人做DEMO。 docker-compose.yml大致如下 version: "3" services: redis: image: redis:latest ports: - "6379:6
ARM架构Linux内核Kconfig文件无效果的处理
03-27 2136
毫无疑问，这是Linux内核的一个BUG。内核版本是2.6.27.8，将会影响到所有ARM架构。本文所述及的思路、解决方法也都是基于ARM架构的，对其他架构不一定适用！ 具体表现为，如果在driver目录下创建了一个新目录，然后在该目录下编写好Kconfig，并在drivers/Kconfig文件中添加了source选项。按道理，内核配置中就应该添加上了这个目录。make menuconfi
Spring的注解@DependsOn
awhip9的博客
02-20 2986
用途 注解@DependsOn位于如下包 org.springframework.context.annotation 1 该注解用于声明当前bean依赖于另外一个bean。所依赖的bean会被容器确保在当前bean实例化之前被实例化。 举例来讲，如果容器通过@DependsOn注解方式定义了bean plant依赖于bean water,那么容器在会确保bean water的实例在实例化be...
2019_It depends on when you search（使用“搜索量”来量化“用户注意力”）
07-10
在互联网时代，用户的搜索行为已经成为衡量用户注意力的重要指标。这篇2019年的研究主要探讨了如何通过搜索量来量化用户注意力，并将其应用于金融市场，特别是股票市场的预测。研究使用了Google Trends的每日搜索量...
The translocation of CIDEC in hepatocytes depends on nutritional status
02-29
营养状态调控CIDEc在肝细胞中的转位，周磊，李红强，研究表明CIDEC蛋白定位于脂滴和内质网，其表达受到脂肪肝的诱导。然而，目前对于其定位结构域、功能域以及CIDEC调节脂肪沉积的具体�
依赖项查看工具depends.zip
12-05
在处理DLL和OCX依赖问题时，除了Depends，开发者还可以结合其他工具，如Microsoft的Dependency Walker（现已被Depends替代）、Visual Studio自带的调试器，以及系统管理工具来进一步排查和解决问题。总的来说，...
depends查看工具
01-08
这在排查程序问题、理解和调试复杂软件系统时非常有用。通过命令行界面，开发者可以自定义分析选项，实现自动化脚本，进一步提高工作效率。 总之，"depends查看工具"是开发者进行系统级调试和分析的重要辅助工具，...
USB4 1.0 ECN - Wake on USB4 Depends on Enable Wake on USB4 Wake
11-17
ECN中指出，新的变更要求在“Wake on USB4”事件发生时，必须同时满足“Enable Wake on USB4 Wake”位被设置为1b，即唤醒功能已被启用。这一改变确保了只有当用户或系统允许USB4唤醒时，路由器才会响应并唤醒系统，...
Spring Boot常用注解（绝对经典）
m0_69526086的博客
04-29 463
将资源导入容器 5、@PropertySource 导入properties文件 6、PropertySources @PropertySource 的集合 7、@Role bean角色定义为ROLE_APPLICATION(默认值)、ROLE_SUPPORT(辅助角色)、ROLE_INFRASTRUCTURE(后台角色，用户无感) 8、@Scope 指定bean的作用域，默认singleton，其它包括prototype、request、session、globalSession 9、@Lazy 使bea
NvidiaAGXXavier刷机Jetpack5.0.2报错记录（已解决，非搬运）
Olddriver6668的博客
11-10 2748
NvidiaAGXXavier刷机Jetpack5.0.2报错记录（已解决，非搬运）网上有很多教程，很详细的讲了这个板子刷机应该怎么去做，正常的话就按照那个步骤走就可以了，这里就不再赘述了，但是我在给自己的NvidiaAgxXavier刷Jetpack5.0.2的时候，用了两天，遇到了一两个坑，下面我来分享一下。(###因为这个东西我做了两天，有不少细节可能遗漏，想讨论的话可以留言评论，我会第一时间回复。祝大家刷机顺利###)
Spring高级之注解@DependsOn详解（超详细）
ywb201314的专栏
10-09 930
需要用到观察者模式的情况下通常都需要用到该注解，观察者模式（详细可查看相关文章）有三要输，观察者、事件源、事件，机制是观察者会监听数据源的某些时间，当事件源触发该事件后，观察者就会知道进行相应措施。这类场景一般需要观察者要比事件源先创建，才能不遗漏事件源触发的每一个事件，要是事件源先创建，可能会在观察者创建前就触发了事件而观察者无法知道。比如老师是观察者，学生是事件源，学生迟到是事件，老师观察学生是否迟到，每当学生迟到，老师就会发现，并处罚该学生。//当作用在方法上时，通常会与@Bean注解配合使用。
spring的@DependsOn注解
最新发布
听海边涛声
01-24 437
spring的@DependsOn注解
@DependsOn或depends-on配置的使用
lantao
03-08 2万+
解释： 首先要了解depends-on或@DependsOn作用，是用来表示一个bean A的实例化依赖另一个bean B的实例化， 但是A并不需要持有一个B的对象，如果需要的话就不用depends-on，直接用依赖注入就可以了或者ref标签。 @DependsOn用法 1：直接或者间接标注在带有@Component注解的类上面; 2：直接或者间接标注在带有@Bean 注解的方法上面; ...
maven项目中报错 could not find class that it depends on找不到所依赖的类
yjxlgqq的博客
07-11 1万+
maven工程在程序编译时报错，could not find class that it depends on找不到所依赖的类。能够引起这种错误的原因：jar包缺失、jar包冲突、jar包不完整、IDE工具问题。本次解决方案：删除本地仓库中的maven项目，重新install项目，恢复正常。...
SpringBoot - @DependsOn注解详解
记录并分享
09-26 3153
@DependsOn注解主要用于指定当前BEAN所依赖的BEANS。任何被指定的依赖的BEAN都由Spring容器保证在当前BEAN之前创建和加载。在某些场景下，BEAN不是通过属性或构造函数参数显式依赖于另一个BEAN，但却需要要求另一个BEAN优先完成初始化，则可以使用@DependsOn这个注解。
使用Spring @DependsOn控制bean加载顺序
热门推荐
neweastsun的专栏
12-11 11万+
使用Spring @DependsOn控制bean加载顺序 #> spring容器载入bean顺序是不确定的，spring框架没有约定特定顺序逻辑规范。但spring保证如果A依赖B(如beanA中有@Autowired B的变量)，那么B将先于A被加载。但如果beanA不直接依赖B，我们如何让B仍先加载呢？## 控制bean初始化顺序 ##可能有些场景中，bean A 间接依赖 bean B。如B
@EnableAutoConfiguration的使用和原理
liangsheng_g的专栏
11-08 3683
Springboot @EnableAutoConfiguration原理Springboot是如何加载@EnableAutoConfiguration1. 如何把自己的配置类加入到Spring容器中呢？1.1 spring.factories2. 探究Springboot是如何加载我们的配置类的2.1 注解介绍2.1.1 @SpringbootApplication注解是什么2.1.2 @SpringbootConfiguration注解2.1.3 @EnableAutoConfiguration注解2.
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值