起因
利润校验地方,我封装了底层的利润校验,查询京东价格用了自定义线程池A批量去查询,然后别的同事也需要用到我的利润校验,他也使用了线程池A去处理逻辑(去进行利润校验,但是我的利润校验也是用的线程池A),这就导致,上层的线程池A去添加任务,上层的线程池由于任务比较多,或者多次执行,导致线程池的核心线程一直在执行,然后下层任务放到了队列中,一直等待核心线程执行完毕,但是核心线程又在等待下层利润校验的返回值。然而上层的线程池A做的任务是调用下层的线程池A,即上层使用了线程池A调用下层的利润校验,利润校验也是用的线程池A。结果就导致,上层的逻辑需要等待下层逻辑的返回,但是下层的逻辑一直得到不到执行(需要等待上层释放资源,让出空间,下层才有机会执行),就造成了彼此相互等待。
查因
流量峰值时发现大量调用超时,通过链路追踪锁定超时发生的节点,隔离节点后,在Pod中使用jstack命令追踪进程
jstack -l 1 |grep "java.lang.Thread.State"|sort -nr|uniq -c
发现有大量线程阻塞在WAITING状态
11 java.lang.Thread.State: WAITING (parking) 2 java.lang.Thread.State: WAITING (on object monitor) 8 java.lang.Thread.State: RUNNABLE
Dump线程信息:jstack -l 1 > stack.log,分析WAITING状态的线程 ,发现 线程池出现了嵌套提交 造成死锁
分析 举例
核心代码如下,外层任务
public void test() throws ExecutionException, InterruptedException { List<Future<String>> outerFutureList = new ArrayList<>(10); for (int i = 0; i < 11; i++) { outerFutureList.add( executorService.submit( new BadTask(executorService) ) ); } // 阻塞等待完成 for (Future<String> outerFuture : outerFutureList) { System.out.println(outerFuture.get()); } executorService.shutdownNow(); }
BadTask类中造成问题的 主要代码
private static class BadTask implements Callable<String>{ private BadTask(ExecutorService executorService) { this.executorService = executorService; } @Override public String call() throws InterruptedException { // rpc等耗时操作 TimeUnit.MILLISECONDS.sleep(10L); List<Future<String>> innerFutureList = new ArrayList<>(5); // 因为有些SDK的接口有参数数量限制,所以多次调用,为提高RT,复用线程池并发调用 for (int i = 0; i < 5; i++) { innerFutureList.add( // ↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓这里又提交了一些Callable到同一个线程池 this.executorService.submit( ()->{ // rpc等耗时操作 TimeUnit.MILLISECONDS.sleep(20L); return "OK"; } ) ); } // 阻塞等待全部完成 for (Future<String> innerFuture : innerFutureList) { innerFuture.get(); } return "OK"; } }
结论
完全死锁的必要条件
破坏以上任何条件,都不会造成完全死锁,但是只要符合条件1,2,在某些情况下仍旧会造成线程执行慢
解决方法
java.util.concurrent.SynchronousQueue