线程数突增！领导：谁再这么写就滚蛋！

前言

今天给大家分享一个线上问题引出的一次思考，过程比较长，但是挺有意思。

今天上班把需求写完，出于学习（摸鱼）的心理上skywalking看看，突然发现我们的一个应用，应用内线程数超过900条，接近1000条，但是cpu并没有高涨，内存也不算高峰。

但是敏锐的我还是立刻意识到这个应用有不妥，因为线程数太多了，不符合我们一个正常健康的应用数量。熟练的打出cpu dump观察，首先看线程组名的概览。

从线程分组看，pool名开头线程占616条，而且waiting状态也是616条，这个点就非常可疑了，我断定就是这个pool开头线程池导致的问题。我们先排查为何这个线程池中会有600+的线程处于waiting状态并且无法释放，记接下来我们找几条线程的堆栈观察具体堆栈：

这个堆栈看上去很合理，线程在线程池中不断的循环获取任务，因为获取不到任务所以进入了waiting状态，等待着有任务后被唤醒。

看上去不只一个线程池，并且这些线程池的名字居然是一样的，我大胆的猜测一下，是不断的创建同样的线程池，但是线程池无法被回收导致的线程数，所以接下来我们要分析两个问题，首先这个线程池在代码里是哪个线程池，第二这个线程池是怎么被创建的？为啥释放不了？

我在idea搜索new ThreadPoolExecutor()得到的结果是这样的：

于是我陷入懵逼的状态，难道还有其他骚操作？

正在这时，一位不知名的郑网友发来一张截图：

好家伙！竟然是用new FixedTreadPool()整出来的。难怪我完全搜不到，因为用的new FixedTreadPool()，所以线程池中的线程名是默认的pool（又多了一个不使用Executors来创建线程池的理由）。

然后我迫不及die的打开代码，试图找到罪魁祸首，结果发现作者居然是我自己。这是另一个惊喜，惊吓的惊。

冷静下来后我梳理一遍代码，这个接口是我两年前写的，主要是功能是统计用户的钱包每个月的流水，因为担心统计比较慢，所以使用了线程池，做了批量的处理，没想到居然导致了线程数过高，虽然没有导致事故，但是确实是潜在的隐患，现在没出事不代表以后不会出事。

去掉多余业务逻辑，我简单的还原一个代码给大家看，还原现场：

private static void threadDontGcDemo(){
        ExecutorService executorService = Executors.newFixedThreadPool(10);
        executorService.submit(() -> {
            System.out.println("111");
        });
    }

那么为啥线程池里面的线程和线程池都没释放呢。

难道是因为没有调用shutdown？我大概能理解我两年前当时为啥不调用shutdown，是因为当初我觉得接口跑完，方法走到结束，理论上栈帧出栈，局部变量应该