1. 问题背景
某应用在启动完提供JSF服务后,短时间内出现了大量的空指针异常。
分析日志,发现是服务依赖的藏经阁配置数据未加载完成导致。即所谓的有损上线或者是直接发布,当应用启动时,service还没加载完,就开始对外提供服务,导致失败调用。
关键代码如下
数据的初始化加载是通过实现CommandLineRunner接口完成的
cjgConfigCacheLoader.refresh()方法内部会将数据加载到内存中
如果此时还未加载完数据,调用cjgRuleConfigMap.get("301").getXX(),则会报空指针异常
总结根因:JSF Provider发布早于服务依赖的初始化数据加载,导致失败调用
2. 问题解决
在解决此问题前,我们需要先回忆并熟悉下Spring Boot的启动过程、JSF服务的发布过程
1)Spring Boot的启动过程(版本2.0.7.RELEASE)
run方法,主要关注refreshContext(context)刷新上下文
refreshContext(context)内部调用refresh()方法,此方法主要关注finishBeanFactoryInitialization(beanFactory) 实例化Bean 早于 finishRefresh() 发生
实例化Bean中,需熟悉Bean的生命周期(重要)
2)JSF Provider的发布过程(版本1.7.5-HOTFIX-T6)
类
com.jd.jsf.gd.config.spring.ProviderBean调用方法com.jd.jsf.gd.config.ProviderConfig#export进行发布
JSF源码地址: http://xingyun.jd.com/codingRoot/jsf/jsf-sdk
可以看出Provider发布有两个地方
Ⅰ、Bean的初始化过程(delay>=0)
实现InitializingBean接口,重写afterPropertiesSet方法。这里会判断是否延迟发布,如果大于等于0,则会此处进行发布。具体在export方法中,当delay>0,则会延迟发布,如配置5000,表示延迟5秒发布;当delay=0,则立即发布。
Ⅱ、监听ContextRefreshedEvent事件触发(delay<0)
实现ApplicationListener接口,重写onApplicationEvent方法。属于事件ContextRefreshedEvent,当delay<-1,则会延迟发布,如配置-5000,表示延迟5秒发布;反之,则立即发布。
3)解决方案
场景1:XML方式自动发布Provider(常用)
由上面的介绍,了解到执行顺序:1.Bean初始化 > 2.ContextRefreshedEvent事件触发 > 3.调用ApplicationRunner或CommandLineRunner;
上面已经知道Provider发布处于1、2过程,需避免使用方式3进行数据的初始化。
前提建议:delay默认配置为-1,可以不配置,或者配置负数。则JSF Provider发布则处于过程2,即监听ContextRefreshedEvent事件触发
方式1:Bean的初始化过程中
解决方法:使用@PostConstruct注解、实现InitializingBean接口、配置init-method方法均可
注意:该Bean如果依赖了其他Bean,需确保依赖Bean已实例化,否则会报空指针异常。
方式2:ContextRefreshedEvent事件触发
ContextRefreshedEvent事件是如何发布的
调用过程
AbstractApplicationContext#finishRefresh -> AbstractApplicationContext#publishEvent-> SimpleApplicationEventMulticaster#multicastEvent
在SimpleApplicationEventMulticaster的multicastEvent方法中调用invokeListener()进行事件发布,getTaskExecutor()默认值是null(除自定义设置Executor对象),所有ApplicationListener实现类串行执行onApplicationEvent方法。
getApplicationListeners(event, type)获取所有的实现类,继续向下看内部会调用
AnnotationAwareOrderComparator.sort(allListeners)对所有ApplicationListener进行排序,allListeners 是待排序的对象列表。该方法将根据对象上的排序注解或接口来确定排序顺序,并返回一个按照指定顺序排序的对象列表。具体来说,排序的规则如下:
1.首先,根据对象上的 @Order 注解的值进行排序。@Order 注解的值越小,排序优先级越高。
2.如果对象上没有 @Order 注解,或者多个对象的 @Order 注解值相同,则根据对象是否实现了 Ordered 接口进行排序。实现了 Ordered 接口的对象,可以通过 getOrder() 方法返回一个排序值。
3.如果对象既没有 @Order 注解,也没有实现 Ordered 接口,则使用默认的排序值 LOWEST_PRECEDENCE(Integer.MAX_VALUE)。特别的:如果BeanA和BeanB排序值都是默认值,则保持原顺序,即Bean的加载顺序
总结:默认情况所有ApplicationListener实现类串行执行onApplicationEvent方法,而顺序取决于
AnnotationAwareOrderComparator.sort(allListeners),@Order 注解的值越小,排序优先级越高
解决方法:使用@Order注解保证执行顺序早于ProviderBean
此外带有@SpringBootApplication的启动类中实现也是可以的(在Spring Boot中默认使用基于注解的方式进行配置和管理Bean,所以注解定义的Bean会在XML定义的Bean之前被加载)
场景2:API方式发布Provider(较少使用)
应用启动完成后,先做初始化动作,完成后再手动发布Provider。这种就可以通过实现接口ApplicationRunner或接口CommandLineRunner去执行初始化。
场景3:XML方式手动发布(不常用)
provider的dynamic属性设置为false
标签 | 属性 | 类型 | 是否必填 | 默认值 | 描述 |
provider | dynamic | boolean | 否 | true | 是否动态注册Provider,默认为true,配置为false代表不主动发布,需要到管理端进行上线操作 |
3. 总结
RPC服务(如JSF、Dubbo)进行优雅上线,常用的两种方式:1、延迟发布 2、手动发动
如果你的服务需要一些初始化操作后才能对外提供服务,如初始化缓存(不限与藏经阁、ducc、mysql、甚至调用其他jsf服务)、redis连接池等相关资源就位,可以参考本文中介绍的几种方式。
此文是笔者通过读取源码+本地验证得出的结论,如有错误遗漏或者更好的方案还烦请各位指出共同进步!