YON CISE

BeanCreationException Related cause

昨天帮同事查一个诡异的 Spring 启动问题,应用里只要引用一个公司中间件的 Spring 配置就启动不起来,但是这个引用的配置里就配置了两个 bean,bean 的功能也非常简单,完全不像是会影响启动的样子。排查大半天后发现,原来是应用里写了一个拦截器,只要 bean 名字以 Processor 结尾就会被拦截,引用的 Spring 配置里有一个 BeanPostProcessor,所以很自然就被拦截到了。

其实报错日志里是有相关的报错的,报错的点就在拦截器里。之所以我们都没有注意是因为看报错日志习惯性的看最后的报错,而这次最后的报错其实并不是导致失败的报错日志,这些报错日志是 Spring 的 related cause。啥是 related cause 呢?Spring 在 Bean 初始化过程中是允许一些报错的,例如一些 Bean 有循环依赖问题,这时候抛出的异常就会被记录下来(参考 org.springframework.beans.factory.support.DefaultSingletonBeanRegistry#suppressedExceptions),然后最终 BeanCreationException 抛出时就会打印真正的异常堆栈同时把 suppressedExceptions 作为 related cause 打印出来。这次就是被这个 related cause 给误导了排查方向。

如果我们对 Spring 非常了解,那么这个问题应该是可以很快定位的,但是我们很多时候排查问题都是对底层没那么了解的,那是不是就没有什么办法了呢?不是的,查问题也是有方法论的。第一步肯定是找到问题的一些特征,去网上搜,看看是不是别人已经遇到了类似的问题。如果第一步失败了,那么我们首先要做的就是要能复现问题,而且是要能快速的复现,像这次排查问题一开始是在远端机器复现,一次修改代码部署就要十来分钟也不方便 debug,所以我就花了不少时间(这个是值得的)把应用在本地启动并复现。第二步完成后就是控制变量进行实验,把导致问题的点圈到最小,这次就是先定位到是配置文件里一个 Bean 的定义,然后再定位到是 Bean 的名字会导致问题,最后才怀疑到了 AOP 上。大胆猜想,小心求证。