增加一个bean改变spring初始化顺序问题

本文探讨了Spring框架中Bean的初始化顺序问题,特别是在引入新Bean后导致原有Bean初始化顺序变化的原因。通过分析JDK 1.6和1.8中ConcurrentHashMap的不同实现,揭示了这一现象背后的原理。

    工程中有2个bean,A和B,其中必须先初始化A再初始化B,但是没有depend-on或者Order等方式去保证,只不过恰好刚好这么运行着没出事,但是突然增加了一个C之后,就先初始化B再初始化A导致问题,但是在主干版本上却没问题。

    解决这个问题其实很简单,depend-on即可,但是为什么会分支版本上会增加C后就改变AB的初始化顺序?为什么主干版本上同样添加没问题呢?可以看spring的源码 DefaultListableBeanFactory 类中有

private final Map<String, BeanDefinition> beanDefinitionMap = new ConcurrentHashMap<String, BeanDefinition>(256);

这个map保存的就是xml中定义的bean结构,spring解析定义的bean之后,保存到这里,其中key为beanid,value为bean的详细信息,根据beanid算出hashCode分别为1505068002,1682286698,从定义可以看到这是一个ConcurrentHashMap,在获取到定义后,spring在初始化的时候是怎么初始化的呢?显然也是从这个定义里取值,为了简化问题,我们理解为是类似如下方式

for(Entry<String,BeanDefinition> entry : beanDefinitionMap)

去遍历bean然后根据BeanDefinition来初始化,考虑分支版本的是用JDK1.6,主干是用JDK1.8,不同ConcurrentHashMap的实现是否会导致取出来的顺序不一样呢?

    JDK1.8中,ConcurrentHashMap 的实现是这样的,数组Node<K,V>[]table,每个元素为一个Node,每个元素直接落到Node上,去追加链表或者在红黑树上,总之是一次hash

    JDK1.6中,ConcurrentHashMap 的实现是这样的,先Segment<K,V>[]segments来进行一个分段,然后每个Segment里再包含元素 HashEntry<K,V>[] table,即,会对每个元素会有2次hash,第一次定位到Segment,第二次在Segment内部定位到自己的位置userService

 可以知道,在JDK1.8中2个bean的位置是固定的(所以主干版本同样添加但是AB初始化顺序不变),但是在JDK1.6中可能会发生这种情况:B在第一个Segment中,A在第二个Segment中,导致取出来的时候先获取到B,后取出来A,所以出现了空指针,同样,也可以解释,为什么新增了1个id为C的bean就导致了问题,但是之前没问题,因为新增bean导致ConcurrentHashMap中部分bean所在的Segment发生变化。

    当然,对有依赖关系显然是显式指定出来的好,不然像这样坑后来人就不好了。

### Spring Bean初始化顺序及加载过程 Spring 中的 Bean 生命周期是一个复杂的过程,涉及多个阶段和多种机制。以下是关于 Spring Bean 初始化顺序及其加载过程的具体说明。 #### 1. 加载配置文件并解析 Bean 定义 在 Spring 应用启动时,容器会先读取配置文件(XML 文件、Java 配置类或注解),并将其中定义的 Bean 转换为内部表示形式——`BeanDefinition` 对象[^4]。这些对象包含了 Bean 的元数据信息,例如依赖关系、作用域、生命周期回调等。 #### 2. 实例化 Bean 当需要某个 Bean 时,Spring 容器会根据 `BeanDefinition` 创建其实例。这一步可以通过构造函数注入完成,也可以通过工厂方法或其他方式实现[^5]。 #### 3. 属性填充 (Populate Properties) 实例化完成后,Spring 将按照配置中的依赖项设置相应的属性值。如果存在循环依赖,则可能触发特殊处理逻辑。 #### 4. 执行 Aware 接口的方法 对于实现了某些特定接口(如 `ApplicationContextAware`, `BeanFactoryAware` 等)的 Bean,在此阶段会被赋予对应的上下文环境引用。 #### 5. Bean 后处理器预初始化 在此阶段,所有的 BeanPostProcessor 类型组件都会收到通知,并有机会对新创建的对象进行修改或者增强。这是 AOP 动态代理发生的时机之一。 #### 6. 自定义初始化逻辑 接下来按优先级依次调用以下几种类型的初始化方法: - **@PostConstruct 注解标记的方法** 这些方法会在其他一切准备工作就绪后立即被执行,且其执行顺序Spring 容器自行决定,不受 `@Order` 影响[^1]。 - **InitializingBean 接口的 afterPropertiesSet() 方法** - **<bean> 元素上的 init-method 属性所指定的方法** 以上三个选项可以混合使用,但需要注意它们之间的相对次序遵循固定规则:首先是 `@PostConstruct`,其次是 `afterPropertiesSet()`,最后才是自定义的 `init-method` 函数。 #### 7. Bean 后处理器最终初始化 再次遍历所有注册过的 BeanPostProcessors 并让它们参与后续加工工作。此时目标 Bean 已经完全准备好可供业务层访问了。 #### 总结 整个流程大致如下所示: ```plaintext 加载配置 -> 解析 BeanDefintion -> 实例化 -> 属性赋值 -> Aware 处理 -> 前期 PostProcessor -> 用户定义 Init Method -> 后期 PostProcessor ``` 下面给出一段简单的代码演示如何利用上述知识点控制两个 Beans 的启动先后关系: ```java import javax.annotation.PostConstruct; import org.springframework.beans.factory.InitializingBean; public class MyService implements InitializingBean { private final AnotherDependency dependency; public MyService(AnotherDependency dependency){ this.dependency = dependency; } @Override public void afterPropertiesSet(){ System.out.println("Executing afterPropertiesSet..."); } @PostConstruct public void postConstructInit(){ System.out.println("Executing @PostConstruct method..."); } } ``` --- ###
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值