一. Bean的初始化

Bean的初始化阶段是Spring启动过程中最重要的扩展点，在初始化阶段Bean已经经历了实例化和属性注入两个主要流程，这时对Bean进行扩展可以做更多的逻辑。在初始化阶段的扩展点也是整个流程最多的，常用于设置初始化参数或设置默认值等逻辑。在初始化阶段可使用的扩展点主要有以下几种。

• BeanPostProcessor的postProcessBeforeInitialization方法
• @PostConstruct
• InitializingBean 的 afterPropertiesSet 方法
• init-method
• BeanPostProcessor的postProcessAfterInitialization方法

1. 源码分析 

初始化源码位置：org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory#initializeBean。在下面的源码中可以看到初始化阶段几个重要的流程步骤。

• 首先会处理感知类接口的逻辑
• 调用所有BeanPostProcessors的前置初始化方法（作用于所有的Bean）。其中需要特别说明的是 @PostConstruct的逻辑在其中的CommonAnnotationBeanPostProcessor里执行。
• 执行invokeInitMethods方法处理InitializingBean的afterPropertiesSet方法和init-method。
• 调用所有BeanPostProcessors的后置初始化方法（作用于所有的Bean）。Bean生成代理类在此执行。

	protected Object initializeBean(String beanName, Object bean, @Nullable RootBeanDefinition mbd) {
		//感知类接口的逻辑
		if (System.getSecurityManager() != null) {
			AccessController.doPrivileged((PrivilegedAction<Object>) () -> {
				invokeAwareMethods(beanName, bean);
				return null;
			}, getAccessControlContext());
		}
		else {
			invokeAwareMethods(beanName, bean);
		}

		Object wrappedBean = bean;
		if (mbd == null || !mbd.isSynthetic()) {
			//执行所有BeanPostProcessors的前置初始化逻辑
			wrappedBean = applyBeanPostProcessorsBeforeInitialization(wrappedBean, beanName);
			//@PostConstruct在CommonAnnotationBeanPostProcessor里执行
		}

		try {
			//InitializingBean 的 afterPropertiesSet 方法
			//init-method
			//这两个逻辑在这里执行
			invokeInitMethods(beanName, wrappedBean, mbd);
		}
		catch (Throwable ex) {
			throw new BeanCreationException(
					(mbd != null ? mbd.getResourceDescription() : null),
					beanName, "Invocation of init method failed", ex);
		}
		if (mbd == null || !mbd.isSynthetic()) {
			//执行所有BeanPostProcessors的前置初始化逻辑
			wrappedBean = applyBeanPostProcessorsAfterInitialization(wrappedBean, beanName);
		}

		return wrappedBean;
	}

invokeInitMethods对InitializingBean的afterPropertiesSet方法和init-method的调用逻辑。其中afterPropertiesSet在init-method之前调用。

	protected void invokeInitMethods(String beanName, Object bean, @Nullable RootBeanDefinition mbd)
			throws Throwable {

		boolean isInitializingBean = (bean instanceof InitializingBean);
		if (isInitializingBean && (mbd == null || !mbd.isExternallyManagedInitMethod("afterPropertiesSet"))) {
			if (logger.isTraceEnabled()) {
				logger.trace("Invoking afterPropertiesSet() on bean with name '" + beanName + "'");
			}
			if (System.getSecurityManager() != null) {
				try {
					AccessController.doPrivileged((PrivilegedExceptionAction<Object>) () -> {
						((InitializingBean) bean).afterPropertiesSet();
						return null;
					}, getAccessControlContext());
				}
				catch (PrivilegedActionException pae) {
					throw pae.getException();
				}
			}
			else {
				//调用InitializingBean的afterPropertiesSet方法
				((InitializingBean) bean).afterPropertiesSet();
			}
		}

		if (mbd != null && bean.getClass() != NullBean.class) {
			String initMethodName = mbd.getInitMethodName();
			if (StringUtils.hasLength(initMethodName) &&
					!(isInitializingBean && "afterPropertiesSet".equals(initMethodName)) &&
					!mbd.isExternallyManagedInitMethod(initMethodName)) {
				//执行init-method方法
				invokeCustomInitMethod(beanName, bean, mbd);
			}
		}
	}

2. 调用顺序

通过上面源码的分析可以了解到初始化阶段各扩展点间的调用顺序。

 3. XXL-JOB中的实际应用

使用分布式定时任务xxl-job时在项目启动时需要启动xxl-job的线程任务、监控任务、注册任务等操作。这个使用场景就比较符合在初始化逻辑中进行处理，让配置类在读取完配置、构建完配置对象后执行。 xxl-job选择了实现InitializingBean接口的方式。

@Component
public class XxlJobAdminConfig implements InitializingBean, DisposableBean {

    private static XxlJobAdminConfig adminConfig = null;
    public static XxlJobAdminConfig getAdminConfig() {
        return adminConfig;
    }

    // ---------------------- XxlJobScheduler ----------------------

    private XxlJobScheduler xxlJobScheduler;

    /**
     * 实现InitializingBean接口，自定义初始化扩展逻辑
     * @throws Exception
     */
    @Override
    public void afterPropertiesSet() throws Exception {
        adminConfig = this;

        xxlJobScheduler = new XxlJobScheduler();
        // admin trigger pool start
        // admin registry monitor run
        // admin fail-monitor run
        // admin lose-monitor run ( depend on JobTriggerPoolHelper )
        // admin log report start
        xxlJobScheduler.init();
    }
}

二. SmartInitializingSingleton

SmartInitializingSingleton的执行时机在 Spring 容器中所有单例 Bean 初始化完成后。当所有单例 Bean 的实例化与初始化过程完成后，可以用来执行一些自定义的初始化逻辑，例如进行缓存预热、启动一些定时任务等操作。Spring 容器会自动回调SmartInitializingSingleton接口的实现类的afterSingletonsInstantiated()方法来做扩展。

public interface SmartInitializingSingleton {

	/**
	 * Invoked right at the end of the singleton pre-instantiation phase,
	 * with a guarantee that all regular singleton beans have been created
	 * already. {@link ListableBeanFactory#getBeansOfType} calls within
	 * this method won't trigger accidental side effects during bootstrap.
	 * <p><b>NOTE:</b> This callback won't be triggered for singleton beans
	 * lazily initialized on demand after {@link BeanFactory} bootstrap,
	 * and not for any other bean scope either. Carefully use it for beans
	 * with the intended bootstrap semantics only.
	 */
	void afterSingletonsInstantiated();

}

1. 源码分析

在Spring启动阶段 SmartInitializingSingleton执行在所有非延迟单例bean初始化完成之后。对于使用SmartInitializingSingleton扩展逻辑还是比较简单的，只需要实现接口即可，只需要满足两个条件：

• 实现SmartInitializingSingleton的bean 要是单例。
• 在所有非延迟的单例的bean初始化完成后调用。

源码位置：org.springframework.beans.factory.support.DefaultListableBeanFactory#preInstantiateSingletons 

        //所有单例bean加载完成后
        for (String beanName : beanNames) {
            //获取单例beanName对应的实例singletonInstance
            Object singletonInstance = getSingleton(beanName);
            //如果singletonInstance属于SmartInitializingSingleton类型
            if (singletonInstance instanceof SmartInitializingSingleton) {
                //强制转型
                SmartInitializingSingleton smartSingleton = (SmartInitializingSingleton) singletonInstance;
                if (System.getSecurityManager() != null) {
                    AccessController.doPrivileged((PrivilegedAction<Object>) () -> {
                        smartSingleton.afterSingletonsInstantiated();
                        return null;
                    }, getAccessControlContext());
                } else {
                    //调用afterSingletonsInstantiated方法，实现自定义逻辑
                    smartSingleton.afterSingletonsInstantiated();
                }
            }
        }

2. RocketMQ中的实际应用

SmartInitializingSingleton的扩展点在实际使用中场景还是很多的。因为执行时机在Spring的整个启动过程中靠后，也代表着可以获得更多的信息的数据。比如RocketMQ在项目启动阶段会给相关Listener监听的Bean或方法做数据的定义和加载。下面我们以RocketMQTransactionListener这个事务消息监听来举例SmartInitializingSingleton的实际应用。

源码位置：org.apache.rocketmq.spring.autoconfigure.RocketMQTransactionConfiguration

@Configuration
public class RocketMQTransactionConfiguration implements ApplicationContextAware, SmartInitializingSingleton {

    @Override
    public void afterSingletonsInstantiated() {
        //获取所有的RocketMQTransactionListener标识的Bean
        Map<String, Object> beans = this.applicationContext.getBeansWithAnnotation(RocketMQTransactionListener.class)
            .entrySet().stream().filter(entry -> !ScopedProxyUtils.isScopedTarget(entry.getKey()))
            .collect(Collectors.toMap(Map.Entry::getKey, Map.Entry::getValue));
        //执行注册方法
        beans.forEach(this::registerTransactionListener);
    }

    private void registerTransactionListener(String beanName, Object bean) {
        Class<?> clazz = AopProxyUtils.ultimateTargetClass(bean);

        if (!RocketMQLocalTransactionListener.class.isAssignableFrom(bean.getClass())) {
            throw new IllegalStateException(clazz + " is not instance of " + RocketMQLocalTransactionListener.class.getName());
        }
        RocketMQTransactionListener annotation = clazz.getAnnotation(RocketMQTransactionListener.class);
        //获取rocketMQTemplate
        RocketMQTemplate rocketMQTemplate = (RocketMQTemplate) applicationContext.getBean(annotation.rocketMQTemplateBeanName());
        if (((TransactionMQProducer) rocketMQTemplate.getProducer()).getTransactionListener() != null) {
            throw new IllegalStateException(annotation.rocketMQTemplateBeanName() + " already exists RocketMQLocalTransactionListener");
        }
        //为rocketMQTemplate设置初始化线程参数
        ((TransactionMQProducer) rocketMQTemplate.getProducer()).setExecutorService(new ThreadPoolExecutor(annotation.corePoolSize(), annotation.maximumPoolSize(),
            annotation.keepAliveTime(), annotation.keepAliveTimeUnit(), new LinkedBlockingDeque<>(annotation.blockingQueueSize())));
        //为rocketMQTemplate设置事务监听器    
        ((TransactionMQProducer) rocketMQTemplate.getProducer()).setTransactionListener(RocketMQUtil.convert((RocketMQLocalTransactionListener) bean));
        log.debug("RocketMQLocalTransactionListener {} register to {} success", clazz.getName(), annotation.rocketMQTemplateBeanName());
    }
}        

三. ApplicationRunner和CommandLineRunner

ApplicationRunner和CommandLineRunner是SpringBoot的扩展点，执行时机在Spring流程执行结束之后，是SpringBoot项目启动过程中最后一个扩展点。在这两个扩展点中可以获取Spring相关的所有信息和数据，可以更完整的加载想要实现的自定义逻辑。可以注入Spring容器中的Bean也可以通过启动命令来传递参数。常用作启动定时任务，启动监听端口，缓存预热加载等逻辑。

@FunctionalInterface
public interface ApplicationRunner {

	/**
	 * Callback used to run the bean.
	 * @param args incoming application arguments
	 * @throws Exception on error
	 */
	void run(ApplicationArguments args) throws Exception;

}

@FunctionalInterface
public interface CommandLineRunner {

	/**
	 * Callback used to run the bean.
	 * @param args incoming main method arguments
	 * @throws Exception on error
	 */
	void run(String... args) throws Exception;

}

1. 源码分析

在callRunners的执行源码可知 ApplicationRunner执行在CommandLineRunner之前。可支持多个Runner执行，会按照@Order注解来定义执行顺序。

源码位置： org.springframework.boot.SpringApplication#callRunners

    private void callRunners(ApplicationContext context, ApplicationArguments args) {
        List<Object> runners = new ArrayList<>();
        //获取所有的ApplicationRunner
        runners.addAll(context.getBeansOfType(ApplicationRunner.class).values());
        //获取所有的CommandLineRunner
        runners.addAll(context.getBeansOfType(CommandLineRunner.class).values());
        //根据order注解排序
        AnnotationAwareOrderComparator.sort(runners);
        for (Object runner : new LinkedHashSet<>(runners)) {
            if (runner instanceof ApplicationRunner) {
                callRunner((ApplicationRunner) runner, args);
            }
            if (runner instanceof CommandLineRunner) {
                callRunner((CommandLineRunner) runner, args);
            }
        }
    }

2. 使用示例

ApplicationRunner和CommandLineRunner都可以通过Jar包的启动命令来传递参数。在获取参数上两者有一些差别。CommandLineRunner 中的 run 方法的数组参数，ApplicationRunner里run方法的参数是一个ApplicationArguments对象。

ApplicationArguments 区分选项参数和非选项参数：

• 非选项参数：通过 ApplicationArguments 的 getNonOptionArgs() 方法获取，获取到的是一个数组。
• 选项参数：通过 ApplicationArguments 的 getOptionNames() 方法获取所有选项名称。通过 getOptionValues() 方法获取实际值（它会返回一个列表字符串）。

自定义ApplicationRunner和CommandLineRunner类 

@Component
@Slf4j
public class VersionApplicationRunner implements ApplicationRunner {

    @Override
    public void run(ApplicationArguments args) throws Exception {
        List<String> nonOptionArgs = args.getNonOptionArgs();
        log.info("VersionApplicationRunner GetNonOptionArgs Param:{}",nonOptionArgs);

        Set<String> optionNames = args.getOptionNames();
        for(String optionName: optionNames) {
            log.info("VersionApplicationRunner GetOptionNames name: {} value:{}",optionName,args.getOptionValues(optionName));
        }
        //启动定时任务或端口
    }
}

    @Component
    @Slf4j
    public class VersionCommandLineRunner implements CommandLineRunner {

        @Override
        public void run(String... args) throws Exception {
            log.info("VersionCommandLineRunner Params : {}", Arrays.toString(args));
            //启动定时任务或端口
        }
    }

设置启动参数： --user.name=rose --user.id=9527 VersionDemo

通过运行打印的日志可以看到执行的先后顺序和传递参数逻辑的不同： 

四. 总结

本文介绍了SpringBoot启动阶段后半段的主要扩展点，本文介绍的Bean的初始化、SmartInitializingSingleton、CommandlineRunner和ApplicationRunner在实际项目中有很多使用场景。因为在Spring容器整体流程的后期，可以获取更多的信息和数据来扩展。详解Spring相关的文章有很多，在这个扩展点系列更注重讲清楚怎么应用和背后的原理是更加注重实践的，希望对大家会有帮助。

最后感谢大家观看！如有帮助 感谢支持！

后续争取每周更新一篇