应用线程数过高及生产问题的排查：ThreadPoolExecutor

因为最近支付系统总是报错无法创建新的线程导致交易失败，领导很重视。查看linux对用户的限制（ulimit -a），发现文件句柄和线程数的大小限制在1024，而通过查看应用实时线程发现数量超过了1100+（pstree -p `ps -e | grep pay | awk '{print $1}'` | wc -l）。通过jstack检查dump文件发现有大量由线程池创建的线程，并且状态为WAITING。则表明有很多空闲的线程在等待task分配。在仔细检查dump文件中，还发现有大量同名的线程，而且数量为10或者20。因为每个线程池的作用是不同的，且类似于thread-1的同名线程有多个，但是一个线程池中的线程ID是肯定不同的，所以大致猜测是不是线程池也创建了多个。经过分析代码确实找出了问题所在。因为线程池也创建了多个，而且设置了corePoolSize的大小，这个数量内的线程是不会被回收的。所以称此机会复习下线程池的。

Executors类提供了4种常用的线程池。他门都是通过调用ThreadPoolExecutor一个默认的构造方法来实现不同的功能。

int corePoolSize：核心线程数，当前线程数小于等于该值时，直接创建新的线程。

int maximumPoolSize：极限线程数，当workQueue满之后，也会创建新的线程。也就是线程数其实是可以突破corePoolSize。

long keepAliveTime：空闲线程的最大存活时间，但是这个是有条件的，必须为大于corePoolSize的线程才能被到期回收。

TimeUnit unit：keepAliveTime的时间种类，可以选择秒或者毫秒等类型。

BlockingQueue<Runnable> workQueue：当线程数大于corePoolSize时，会将任务放入workQueue，等候被线程执行。

ThreadFactory threadFactory：创建线程的工厂，可以修改线程名。

RejectedExecutionHandler handler：拒绝时任务处理器，当达到maximumPoolSize时，怎么办呢？你可以选择自己定制策略，也可以使用默认的：直接报错拒绝任务，这是一种比较安全的做法，毕竟以及达到最大线程数限制了。

所以有两种解决的办法，重写相关线程池创建的逻辑（因为原逻辑这么作肯定有他的道理），或者使用缓存线程池，把corePoolSize设置为0，让全部的线程都受keepAliveTime的控制。