记一次NPE问题排查

线上业务突然报错，查看前端网页请求记录后，定位到后端服务的具体某一接口抛了业务异常，根据业务异常的关键字定位到具体的代码行
原始业务异常代码：
picture 1

明显：执行completionService.take().get(TIME_OUT, TimeUnit.SECONDS) 处抛出异常
picture 2
进入方法体内部查看，如下图
picture 3

picture 4
根据picture 1 可定位至picture 4的抛错处。此处的变量"s"表示线程的状态

picture 5
线程的运行状态

从注释里面看出来一共有4种状态的变化

1、NEW（初始化）-> COMPLETING（运行中）-> NORMAL（完成状态）
2、NEW（初始化）-> COMPLETING（运行中）-> EXCEPTIONAL（运行发生错误）
3、NEW（初始化）-> CANCELLED（还未运行已经被取消）
4、NEW（初始化）-> INTERRUPTING（运行中被取消）-> INTERRUPTED（被取消状态）

按照picture 4 的代码逻辑可判定当前线程处于EXCEPTIONAL（运行发生错误）状态，也就是执行task任务出错了，抛出了picture 1的异常堆栈信息；但是此堆栈信息并不是原始的异常堆栈信息。
So ,如何找出原始异常堆栈信息呢？
可能原因：1、本服务的代码报NPE；2、调用外部的dubbo接口服务报NPE

task任务执行的方法入参
picture 6

执行task任务的具体代码逻辑如下
picture 7

查看kibana日志，发现“functionListByProductId被打印了8次，而picture 6中有9次入参，故有一次执行方法异常，从代码的执行顺序看，很有可能是调用外部dubbo接口导致异常，然后到对应的服务查kibana的错误日志

总结：线程池执行任务过程中异常，获取执行后的任务结果会返回return值或异常信息，但不打印原始的异常堆栈，导致排查问题较困难。建议：在submit()方法主动捕获try catch一下原始异常堆栈并打印出来，保留现场痕迹