spring初始化顺序

首先，Spring bean的默认加载顺序是怎么控制的

工程中有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 @DependsOn控制bean加载顺序

spring容器载入bean顺序是不确定的，spring框架没有约定特定顺序逻辑规范。但spring保证如果A依赖B(如beanA中有@Autowired B的变量)，那么B将先于A被加载。但如果beanA不直接依赖B，我们如何让B仍先加载呢？

控制bean初始化顺序
可能有些场景中，bean A 间接依赖 bean B。如Bean B应该需要更新一些全局缓存，可能通过单例模式实现且没有在spring容器注册，bean A需要使用该缓存；因此，如果bean B没有准备好，bean A无法访问。

另一个场景中，bean A是事件发布者（或JMS发布者），bean B (或一些) 负责监听这些事件，典型的如观察者模式。我们不想B 错过任何事件，那么B需要首先被初始化。

简言之，有很多场景需要bean B应该被先于bean A被初始化，从而避免各种负面影响。我们可以在bean A上使用@DependsOn注解，告诉容器bean B应该先被初始化。下面通过示例来说明。

示例说明
示例通过事件机制说明，发布者和监听者，然后通过spring配置运行。为了方便说明，示例进行了简化。

EventManager.java
事件管理类，维护监听器列表，通过单例方法获取事件管理器，可以增加监听器或发布事件。

import java.util.ArrayList;
import java.util.List;
import java.util.function.Consumer;

public class EventManager {
    private final List<Consumer<String>> listeners = new ArrayList<>();

    private EventManager() {
    }

    private static class SingletonHolder {
        private static final EventManager INSTANCE = new EventManager();
    }

    public static EventManager getInstance() {
        return SingletonHolder.INSTANCE;
    }

    public void publish(final String message) {
        listeners.forEach(l -> l.accept(message));
    }

    public void addListener(Consumer<String> eventConsumer) {
        listeners.add(eventConsumer);
    }
}

EventPublisherBean.java
事件发布类，通过EventManager类发布事件。

import com.logicbig.example.EventManager;

public class EventPublisherBean {

    public void initialize() {
        System.out.println("EventPublisherBean initializing");
        EventManager.getInstance().publish("event published from EventPublisherBean");
    }
}

EventListenerBean.java
事件监听者，可以增加监听器。

import com.logicbig.example.EventManager;

public class EventListenerBean {

    private void initialize() {
        EventManager.getInstance().
                addListener(s ->
                        System.out.println("event received in EventListenerBean : " + s));
    }
}

AppConfig.java
配置运行类。

@Configuration
@ComponentScan("com.logicbig.example")
public class AppConfig {

    @Bean(initMethod = "initialize")
    @DependsOn("eventListener")
    public EventPublisherBean eventPublisherBean () {
        return new EventPublisherBean();
    }

    @Bean(name = "eventListener", initMethod = "initialize")
    // @Lazy
    public EventListenerBean eventListenerBean () {
        return new EventListenerBean();
    }

    public static void main (String... strings) {
        new AnnotationConfigApplicationContext(AppConfig.class);
    }
}

运行AppConfig的main方法，输出结果为：

EventListenerBean initializing
EventPublisherBean initializing
event received in EventListenerBean : event published from EventPublisherBean

总结
如果我们注释掉@DependsOn("eventListener")，我们可能不确定获得相同结果。尝试多次运行main方法，偶尔我们将看到EventListenerBean 没有收到事件。为什么是偶尔呢？因为容器启动过程中，spring按任意顺序加载bean。

那么当不使用@DependsOn可以让其100%确定吗？可以使用@Lazy注解放在eventListenerBean ()上。因为EventListenerBean在启动阶段不加载，当其他bean需要其时才加载。这次我们仅EventListenerBean被初始化。

EventPublisherBean initializing
现在从新增加@DependsOn，也不删除@Lazy注解，输出结果和第一次一致，虽然我们使用了@Lazy注解，eventListenerBean在启动时仍然被加载，因为@DependsOn表明需要EventListenerBean。

@Lazy

@Lazy用于指定该Bean是否取消预初始化。主要用于修饰Spring Bean类，用于指定该Bean的预初始化行为，

使用该Annotation时可以指定一个boolean型的value属性，该属性决定是否要预初始化该Bean

• lazy代表延时加载，lazy=false，代表不延时，如果对象A中还有对象B的引用，会在A的xml映射文件中配置b的对象引用，多对一或一对多，不延时代表查询出对象A的时候，会把B对象也查询出来放到A对象的引用中，A对象中的B对象是有值的。
• lazy=true代表延时，查询A对象时，不会把B对象也查询出来，只会在用到A对象中B对象时才会去查询，默认好像是false，你可以看看后台的sql语句的变化就明白了，一般需要优化效率的时候会用到

@Lazy(true)
@Component
public class Chinese implements Person{
   //codes here
}

@DependsOn用于强制初始化其他Bean。可以修饰Bean类或方法，使用该Annotation时可以指定一个字符串数组作为参数，每个数组元素对应于一个强制初始化的Bean

@DependsOn({"steelAxe","abc"})
@Component
public class Chinese implements Person{
   //codes here
}

@Order

@Order注解的源码如下，value用例赋值，默认赋值Ordered.LOWEST_PRECEDENCE，即默认优先级最低：

@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.TYPE, ElementType.METHOD, ElementType.FIELD})
public @interface Order {

    /**
     * The order value. Default is {@link Ordered#LOWEST_PRECEDENCE}.
     * @see Ordered#getOrder()
     */
    int value() default Ordered.LOWEST_PRECEDENCE;

}

再来看下Order接口的源码如下，一目了然，值越小优先级越高，即被优先加载（precedence即优先级）：

public interface Ordered {

/**
* Useful constant for the highest precedence value.
* @see java.lang.Integer#MIN_VALUE
*/
int HIGHEST_PRECEDENCE = Integer.MIN_VALUE;//值越小，优先级越高

/**
* Useful constant for the lowest precedence value.
* @see java.lang.Integer#MAX_VALUE
*/
int LOWEST_PRECEDENCE = Integer.MAX_VALUE;//值越大，优先级越低

/**
     * Return the order value of this object, with a
     * higher value meaning greater in terms of sorting.
     * <p>Normally starting with 0, with {@code Integer.MAX_VALUE}
     * indicating the greatest value. Same order values will result
     * in arbitrary positions for the affected objects.
     * <p>Higher values can be interpreted as lower priority. As a
     * consequence, the object with the lowest value has highest priority
     * (somewhat analogous to Servlet "load-on-startup" values).
     * @return the order value
     */
    int getOrder();

拓展①：为何在类上加@Order就可以对类（映射到容器中就是bean）有效排序了？

先了解下Java强大的注解功能，可以参考Java注解教程及自定义注解

拓展②：给类@Order注解后spring容器具体怎么给bean排序的呢？

在@Order注解的源码上，作者写了相关信息，感兴趣可以查看下

拓展③：@Order的作用域可以是类、方法、类成员，方法和类成员暂时没有测试，保留。

Springboot的@AutoConfigureAfter注解，手动的指定Bean的实例化顺序

Springboot的@AutoConfigureAfter注解，手动的指定Bean的实例化顺序。了解Spring内Bean的解析，加载和实例化顺序机制有助于我们更好的使用Spring/Springboot，避免手动的去干预Bean的加载过程，搭建更优雅的框架。

Spring容器在实例化时会加载容器内所有非延迟加载的单例类型Bean，看如下源码：

public abstract class AbstractApplicationContext extends DefaultResourceLoader
        implements ConfigurableApplicationContext, DisposableBean {

    //刷新Spring容器，相当于初始化
    public void refresh() throws BeansException, IllegalStateException {
        ......
        // Instantiate all remaining (non-lazy-init) singletons.
        finishBeanFactoryInitialization(beanFactory);
    }
}

public class DefaultListableBeanFactory extends AbstractAutowireCapableBeanFactory
        implements ConfigurableListableBeanFactory, BeanDefinitionRegistry, Serializable {

    /** List of bean definition names, in registration order */
    private volatile List<String> beanDefinitionNames = new ArrayList<String>(256);

    public void preInstantiateSingletons() throws BeansException {
        List<String> beanNames = new ArrayList<String>(this.beanDefinitionNames);
        for (String beanName : beanNames) {
            ......
            getBean(beanName);  //实例化Bean
        }
    }

}

ApplicationContext内置一个BeanFactory对象，作为实际的Bean工厂，和Bean相关业务都交给BeanFactory去处理。
在BeanFactory实例化所有非延迟加载的单例Bean时，遍历beanDefinitionNames 集合，按顺序实例化指定名称的Bean。beanDefinitionNames 属性是Spring在加载Bean Class生成的BeanDefinition时，为这些Bean预先定义好的名称，看如下代码：

public class DefaultListableBeanFactory extends AbstractAutowireCapableBeanFactory
        implements ConfigurableListableBeanFactory, BeanDefinitionRegistry, Serializable {

    public void registerBeanDefinition(String beanName, BeanDefinition beanDefinition)
            throws BeanDefinitionStoreException {
        ......
        this.beanDefinitionNames.add(beanName);
    }
}

BeanFactory在加载一个BeanDefinition（也就是加载Bean Class）时，将相应的beanName存入beanDefinitionNames属性中，在加载完所有的BeanDefinition后，执行Bean实例化工作，此时会依据beanDefinitionNames的顺序来有序实例化Bean，也就是说Spring容器内Bean的加载和实例化是有顺序的，而且近似一致，当然仅是近似。

Spring在初始化容器时，会先解析和加载所有的Bean Class，如果符合要求则通过Class生成BeanDefinition，存入BeanFactory中，在加载完所有Bean Class后，开始有序的通过BeanDefinition实例化Bean。

我们先看加载Bean Class过程，零配置下Spring Bean的加载起始于ConfigurationClassPostProcessor的postProcessBeanDefinitionRegistry（BeanDefinitionRegistry）方法，我总结了下其加载解析Bean Class的流程：

配置类可以是Spring容器的起始配置类，也可以是通过@ComponentScan扫描得到的类，也可以是通过@Import引入的类。如果这个类上含有@Configuration，@Component，@ComponentScan，@Import，@ImportResource注解中的一个，或者内部含有@Bean标识的方法，那么这个类就是一个配置类，Spring就会按照一定流程去解析这个类上的信息。

在解析的第一步会校验当前类是否已经被解析过了，如果是，那么需要按照一定的规则处理（@ComponentScan得到的Bean能覆盖@Import得到的Bean，@Bean定义的优先级最高）。

如果未解析过，那么开始解析：

解析内部类，查看内部类是否应该被定义成一个Bean，如果是，递归解析。
解析@PropertySource，也就是解析被引入的Properties文件。
解析配置类上是否有@ComponentScan注解，如果有则执行扫描动作，通过扫描得到的Bean Class会被立即解析成BeanDefinition，添加进beanDefinitionNames属性中。之后查看扫描到的Bean Class是否是一个配置类（大部分情况是，因为标识@Component注解），如果是则递归解析这个Bean Class。
解析@Import引入的类，如果这个类是一个配置类，则递归解析。
解析@Bean标识的方法，此种形式定义的Bean Class不会被递归解析
解析父类上的@ComponentScan，@Import，@Bean，父类不会被再次实例化，因为其子类能够做父类的工作，不需要额外的Bean了。
在1，3，4，6中都有递归操作，也就是在解析一个Bean Class A时，发现其上能够获取到其他Bean Class B信息，此时会递归的解析Bean Class B，在解析完Bean Class B后再接着解析Bean Class A，可能在解析B时能够获取到C，那么也会先解析C再解析B，就这样不断的递归解析。

在第3步中，通过@ComponentScan扫描直接得到的Bean Class会被立即加载入beanDefinitionNames中，但@Import和@Bean形式定义的Bean Class则不会，也就是说正常情况下面@ComponentScan直接得到的Bean其实例化时机比其他两种形式的要早。

通过@Bean和@Import形式定义的Bean Class不会立即加载，他们会被放入一个ConfigurationClass类中，然后按照解析的顺序有序排列，就是图片上的 “将配置类有序排列“。一个ConfigurationClass代表一个配置类，这个类可能是被@ComponentScan扫描到的，则此类已经被加载过了；也可能是被@Import引入的，则此类还未被加载；此类中可能含有@Bean标识的方法。

Spring在解析完了所有Bean Class后，开始加载ConfigurationClass。如果这个ConfigurationClass是被Import的，也就是说在加载@ComponentScan时其未被加载，那么此时加载ConfigurationClass代表的Bean Class。然后加载ConfigurationClass内的@Bean方法。

顺序总结：@ComponentScan > @Import > @Bean

下面看实际的启动流程：

此图顺序验证小框架：Spring Bean解析，加载及实例化顺序验证小框架

Bean Class的结构图如上所示，A是配置类的入口，通过A能直接或间接的引入一个模块。

此时启动Spring容器，将A引入容器内。

如果A是通过@ComponentScan扫描到的，那么此时的加载顺序是：
A > D > F > B > E > G > C

如果A是通过@Import形式引入的，那么此时的加载顺讯是：
D > F > B > E > G > A > C

当然以上仅仅代表着加载Bean Class的顺序，实际实例化Bean的顺序和加载顺序大体相同，但还是会有一些差别。
Spring在通过getBean(beanName)形式实例化Bean时，会通过BeanDefinition去生成Bean对象。在这个过程中，如果BeanDefinition的DependsOn不为空，从字面理解就是依赖某个什么，其值一般是某个或多个beanName，也就是说依赖于其他Bean，此时Spring会将DependsOn指定的这些名称的Bean先实例化，也就是先调用getBean(dependsOn)方法。我们可以通过在Bean Class或者@Bean的方法上标识@DependsOn注解，来指定当前Bean实例化时需要触发哪些Bean的提前实例化。

当一个Bean A内部通过@Autowired或者@Resource注入Bean B，那么在实例化A时会触发B的提前实例化，此时会注册A>B的dependsOn依赖关系，实质和@DependsOn一样，这个是Spring自动为我们处理好的。

了解Spring Bean的解析，加载及实例化的顺序机制能够加深对Spring的理解，搭建更优雅简介的Spring框架。