一次BUG追踪

        过年刚来第一天上班，没有开工红包，迎面而来一个大BUG.运维的同事反映：一个模块服务节点，大概跑几天就会宕机，后来查了这台服务器的资源使用情况，CPU不高，内存也不高，线程数奇高。这种现象一看就是代码问题，二话不说门头干起来。顺着代码逻辑过代码，左看右看都觉得自己代码挺好，但是问题是存在的，就像一个巴掌，已经拍到脸上了，你不能当做它不存在啊。

        搞起来！首先，觉得可能是其他模块的任务连累了这个模块，于是做了个对比测试，和其他模块比较，线程数差了一个数量级。问题锁定，这个锅不是别人的。
然后，重启了测试环境该模块的服务，然后用shell脚本定时查看该进程线程数（while true do pstree -p pid|wc -l;date;sleep 20;done）,线程数没有出现明显的增长。纳闷了。。。（后来回头想想，没复现问题只是，程序没有走到新增线程池的地方，并不是没有问题）
        测试不顺，该看代码，不能再一棵树上吊死。可能导致线程新增的地方不多，最终锁定目标代码。这块用了线程池（ExecutorService pool = Executors.newFixedThreadPool(5)）,子线程中没有阻塞，正常来说线程类执行完毕会自动销毁，不需要人工干预，
这也是java一大特色。突然！一道光打到天灵盖，突然，好像明白了什么。找到了一个怀疑的目标，线程执行完毕会被垃圾回收，线程池呢？于是做了个实验，死循环中定时创建线程池。然后往线程池里加入一定数量的线程。与此同时在命令行使用命令检测该进程的线程数，线程数在稳步增长，问题找到了！然后又看了ExecutorService的源码，接口定义中有shutdown方法以及shutdownNow方法，这也就印证了，凡是实现了该接口的类，都要自行关闭。
一句话总结，源码看的不够，在使用一个新的东西的时候记得先看一下源码哦。