记一次ThreadPoolExecutor使用不当导致JVM死掉的问题

业务场景：

http接口中为了加快大量数据的处理速度，使用了ThreadPoolExecutor线程池进行并发处理。

性能测试时，对比使用线程池与不使用线程池接口响应速度确实有很大提升，但是后续的接口压力测试，却暴露出了ThreadPool使用不当造成的灾难。

测试场景：

接口压力测试时，有一步骤叫做数据库的启停测试。就是在压力测试脚本稳定运行过程中，要把系统正在使用的数据库服务关闭一段时间后重新启动，要求脚本运行除在数据库关闭阶段有报错外，当数据库重新启动后，脚本要恢复稳定运行至少90%以上。

问题现象：

接口压力测试稳定运行后，将数据库服务关闭大概10秒钟，jvm进程所在服务器失去了控制，具体现场如下图：

执行任何命令系统都会响应：-bash: fork: retry: Resource temporarily unavaliable 和 -bash: fork: retry: No child processes

cciqa用户开启的线程数10秒内从300飙升到了12286

问题分析：

-bash: fork: retry: No child processes 问题表明当前登录用户创建的线程数（或进程数）超过了操作系统允许其创建的线程数（或进程数），就像是妈妈给的钱被花光了一样，于是查询了操作系统对当前用户创建线程数（或者进程数）的限制：

发现以下问题：

1. 当前登录用户数max user processes限制 819200，这个限制已经非常高了，所以到这一步，基本可以确定是应用程序的问题

2. /proc/sys/kernel/threads-max 参数，这是操作系统内核从物理内存方面给出的默认最大进程（线程）数限制，一般普通用户的max user processes 是此限制的1/2，所以相当于是819200没有作用。

问题排查：

jstack 命令 dump了jvm进程的线程状态：

发现 ThreadPoolExecutor巨多，基本先用了线程dump信息的90%，到这里基本可以锁定就是这个问题导致了。

回去翻阅代码，找ThreadPoolExecutor使用的地方哪里会导致此问题，最终在一个接口中发现：

每次调用接口时，都会在接口内部创建ThreadPoolExecutor新对象，而且ThreadPoolExecutor中的阻塞大小没有限制。所以会在接口压力并发数比较高的情况下，创建非常多的ThreadPoolExecutor，开启大量线程，导致jvm线程数飙升。