Java|SocketInputStream.socketRead0引起线程池提交任务后，futureTask.get超时 Java|bug排查

文章目录

1. 现象
2. 结论
3. 相关代码
4. 查看堆栈：
5. 查看submitCall

5.1 ThreadPoolExecutor#execute最终调用了 RunnableFuture#run方法
5.2 从代码层面判断 futureTask.get超时只影响了业务线程（调用futureTask.get的线程），不影响工作线程。
5.3 future.get

5.3.1 测试future.get并不能打断线程池的线程。

6. 查看工作线程为何阻塞

6.1 修复

7. 相关资料

1. 现象线上发短信、邮箱验证码的时候超时

Java|SocketInputStream.socketRead0引起线程池提交任务后，futureTask.get超时

文章图片

2. 结论

SocketInputStream.socketRead0导致线程阻塞，阻塞后占用了线程池的线程。多次阻塞后最终占用了全部的core线程。新提交的任务只能入队，没有线程来处理。
由于 socket.read占用了corePoolSize 个线程池的工作线程worker.thread , 这里一共有10个，全都阻塞了。
而execute提交一个runnable的时候，在达到corePoolSize后，会将其放入workQueue中。直到workQueue满。
新的任务只能入队（enQueue），不能被消费。
所以 futureTask.get 一直超时。
futureTask.get(timeout,timeunit)不会导致线程池的工作线程异常。工作线程会继续执行。

3. 相关代码 sendVcWorkerThreadPool是ThreadPoolExecutor的子类WorkerThreadPool

文章图片

文章图片

WorkerThreadPool
这里workQueue本身是一个优先队列，这里会无限扩容
ps:由于无限扩容，这里maxinumPoolSize是无效的

文章图片

文章图片

先查找相关调用链的底层日志，发现根本没有调用底层方法。
而其他应用能调用到该底层，一直在输出日志，说明是execute本身有问题。
4. 查看堆栈：搜索AsyncWorker(ps:自定义的线程池一定要重命名，找问题的时候方便)，发现该线程池的10个core线程都处于runnable，且所有线程都在
sendEmail

文章图片

5. 查看submitCall 虽然future.get有超时，但是这只能保证业务线程不阻塞。
future.get并不能打断线程池的线程。

文章图片

这里的sendVcWorkerThreadPool#submitCall与ThreadPoolExecutor
ThreadPoolExecutor#submit类似

文章图片

由于继承ThreadPoolExecutor,所以调用了ThreadPoolExecutor的execute

文章图片

5.1 ThreadPoolExecutor#execute最终调用了 RunnableFuture#run方法

调用链
addWorker()->w.start()->treahd.run()->Worker.runWorker(Worker w)->task.run();
task即RunnableFuture ，newTaskFor创建了子类FutureTask

因此查看FutureTask的run方法

FutureTask是对Callable的一层封装。
超时只影响了业务线程（调用futureTask.get的线程），不影响工作线程。

5.2 从代码层面判断 futureTask.get超时只影响了业务线程（调用futureTask.get的线程），不影响工作线程。
FutureTask.run

文章图片

运行完毕，设置结果
此时可以使用future.get出结果

文章图片

这里让【因为future.get，调用park方法使得等待】的线程恢复。

文章图片

5.3 future.get

文章图片

死循环检测是否完成，超时后，直接return 当前state
Unsafe.park()本地方法休眠当前线程， HotSpot在Linux中中通过调用pthread_mutex_lock函数把线程交给系统内核进行阻塞。

文章图片

休眠

文章图片

检测的时候，先将当前线程添加到waitNode

文章图片

5.3.1 测试future.get并不能打断线程池的线程。
6. 查看工作线程为何阻塞虽然已经证明了futureTask.get超时后不会打断线程池的worker.thread，还是需要查看工作线程为何阻塞。
再回顾一下堆栈

文章图片

execute的调用链是addWorker()->w.start()->treahd.run()->Worker.runWorker(Worker w)->task.run();
而FutureTask是对Callable的一层封装。
本身是SendEmailCall本身是一个Callable
我们只需要查看SendEmailCall的call方法为何一直在运行。