【0x00000006】案例研究：由于线程池使用不当而导致系统崩溃

通过阿里云-云监控-主机监控查看内存使用率指标，这段时间内，内存使用率一直在40%以下，基本可排除内存溢出的可能。

通过搜索查阅到进程数超过操作系统限制可能导致bash: fork: Cannot allocate memory的报错(参考： ）。通过ps -eLf|wc -l查看当前进程线程数(ps -ef只打印进程，ps -eLf会打印所有的线程), 只有1000多个，故障时刻系统到底运行了多少线程已无从得知，只能持续跟进监测。

问题定位

几天后，再次通过ps -eLf|wc -l查看，发现线程数已达16000多个。直接执行ps -eLf可看到大量tomcat进程所产生的线程，猜测是不是线程死锁导致大量线程未完成一直hung在那里。

执行 jstack 进程号 > ~ 命令将进程所运行线程情况打印出来分析，发现大量的WAITING状态的线程，如下

根据上述内容可看出线程在等一个条件，并且是在执行LinkedBlockingQueue.take方法的时候，查看该方法的java doc，当队列为空时，该方法将会一直等待直到有元素可用。

询问同事在哪里用到了LinkedBlockingQueue，同事回忆起不久前用线程池实现往阿里云OSS服务通过追加的方式上传文件功能，查看代码后发现问题——线程池没有关闭。为了使文件片段保存不存在错乱，每次保存文件时，都new了一个线程池对象，

但处理完后， 没有关闭这个线程池对象，这样线程池仍会通过take方法去取等待队列中是否还有未完成的线程任务，等待队列为空时将会一直等待，这样就导致大量的线程hung在这里了（基本是只要方法被调一次，就会产生一个hung住的线程），时间一长就达到系统所允许的最大限制（默认32768个），不能处理新任务，从而导致系统服务不可用。

延伸

1. 线程状态为“waiting for monitor entry”：
2. 意味着它 在等待进入一个临界区 ，所以它在”Entry Set“队列中等待。此时线程状态一般都是 Blocked：
3. java.lang.T: BLOCKED (on object monitor)
4. 线程状态为“waiting on condition”：
5. 说明它在等待另一个条件的发生，来把自己唤醒，或者干脆它是调用了 sleep(N)。此时线程状态大致为以下几种：
6. java.lang.T: WAITING (parking)：一直等那个条件发生（本文案例即为此种场景）；java.lang.T: TIMED_WAITING (parking或sleeping)：定时的，那个条件不到来，也将定时唤醒自己。
7. 如果大量线程在“waiting for monitor entry”：可能是一个全局锁阻塞住了大量线程。如果短时间内打印的thread dump 文件反映，随着时间流逝，waiting for monitor entry 的线程越来越多，没有减少的趋势，可能意味着某些线程在临界区里呆的时间太长了，以至于越来越多新线程迟迟无法进入临界区。
8. 如果大量线程在“waiting on condition”：可能是它们又跑去获取第三方资源，尤其是第三方网络资源，迟迟获取不到Response，导致大量线程进入等待状态。所以如果你发现有大量的线程都处在 Wait on condition，从线程堆栈看，正等待网络读写，这可能是一个网络瓶颈的征兆，因为网络阻塞导致线程无法执行。也可能是如本文所提到的，由于程序编写不当所致。

参考：

我的个人博客地址：

我的头条空间：

我的github地址：

我的微信公众号：jboost-ksxy

——————————————————————