问题现象：
富仁小站线上API服务在2021年3月21号下午出现问题，不能提供对外服务，导致线上设备和相关业务流程中断
临时解决方案：
为了防止服务中断时间过久，重启服务
问题定位：
在3月21号之后的几天连续观察服务的线程和内存变化
1、观察服务线程数的变化：
pstree -p > threadNum.txt
PS: 因为线上服务过多，直接在控制台执行命令，容易出现刷屏，直接将线程树打印到文本中进行调查
2、拿到线程树之后，查找线程树中线程数最多的进程ID，然后通过：
ps -ef | grep java
的方式进行了解具体的线程数过多的服务。
3、在定位到具体出问题的服务之后，通过下面的命令进入到容器
docker exec -it container_name /bin/bash
4、进入到服务的容器之后，通过jstat命令来查看当前服务的内存GC情况，以便了解是否是因为服务的GC过高导致出现了OOM的问题
jstat -gcutil pid 10000 30
等待上面的命令执行完毕后，观察当前的gc情况，其中：
s0、s1、E 三个表示的是内存中年轻代的占比
O 表示的是内存中的老年代占比
YGC 表示的是年轻代GC发生的次数
YGCT表示的是年轻代GC发生的总耗时
FGC表示的全GC发生的次数
FGCT表示的是全GC发生总耗时
当FGC次数过高，耗时过长，服务中断的可能性越高，但是通过线程查看，服务并没有发生过高的FGC的情况
5、通过jstat并没有发现什么大的问题，那么就需要获取服务的内存堆栈进行分析了。内存堆栈的分析可以使用jmap的方式进行分析，也可以通过MemoryAnalysis工具进行分析。首先我们将内存堆栈导出：
jmap -dump:live,format=b,file=heap.bin pid
或者
jmap -dump:live,format=b,file=heap.hprof pid
我们此处使用第二种方式，通过内存分析工具来分析，能更加的清楚
6、通过内存堆栈的分析我们只能看见问题发生在了和线程池有关的地方，然后其中对象数top3中主要是Thread、String和LinkedBlokingQueue，那么我们可以初步定位问题应该我们的线程池使用的时候出现了问题，我们再继续查看Thread 的具体对象信息，发现有很多事在延时任务上，这部分代码是我们自己写的代码，其他的都是第三方框架，咱们暂时先不要关注第三方框架是否出现了问题，先在我们自己的代码中找到下面我们标注出来的对象代码
我们查阅代码发现代码中就只有一个创建线程池的地方
而且该线程池的创建还是在单例方法内部，所以这个不应该是导致线程过高的罪魁祸首。
7、到此为止我们好像唯一的线索又断了，那此时我们再通过jstack的命令获取JAVA的线程堆栈
jstack -l pid
我们发现有很多的线程是WAITING状态，我们再结合上面的内存堆栈的分析，怀疑是线程池创建使用不当导致的问题，所以我们按照线程池不正确使用的方向猜想，并验证。我写了下面的代码：
public class Test {
public static void main(String[] args) {
for (int i = 0; i < 10000; i++) {
ExecutorService service = new ThreadPoolExecutor(10, 10, 60, TimeUnit.SECONDS, new LinkedBlockingQueue<>(10), new RejectedExecutionHandler() {
@Override
public void rejectedExecution(Runnable r, ThreadPoolExecutor executor) {
System.out.println("拒绝新任务");
}
});
Thread thread = new Thread(new Runnable() {
@Override
public void run() {
System.out.println("test");
}
});
service.submit(thread);
}
}
}
然后执行该代码，通过jps命令查询该进程的pid
然后通过jstack命令获取当前的线程堆栈信息
我们发现此刻出现了大量的WAITING线程和生产环境出现的现象一致。到此我们确认是我们的线程池使用不当导致线程数过高。
确认了是因为使用线程池不当导致的，我们还需要从代码层面去证实是否是我们的线程池使用不当，通过查找**new ThreadPoolExecutor(**该特征字发现，我们的代码中确实有很多地方都在进行显示new ThreadPoolExecutor对象，并且每个请求都会重新new一个对象，那么随着时间的推移，这个对象会越来越多。
解决方案
到此线上线程数过高的问题已经找到了罪魁祸首，接下来就是解决该问题，目前通过编写一个全局的线程池工具，工全局服务调用使用即可：
package com.frznkj.common.utils;
import lombok.extern.slf4j.Slf4j;
import java.util.concurrent.*;
/**
* 服务线程池
* 系统启动时，自带三个线程池，其余业务直接使用该线程池
*
* @author wanggc
* @version 1.0.0
* @email wgcqwfy@aliyun.com
* @date 2021-03-19 17:24
**/
@Slf4j
public class ThreadPoolUtil {
/**
* 创建一个最大并发为150个线程的无界线程池
*/
private final static ExecutorService unboundedThreadPool = new ThreadPoolExecutor(50, 50, 120, TimeUnit.SECONDS, new LinkedBlockingQueue<>());
/**
* 该线程池最多有50个线程同步执行，在业务处理中可以将处理很慢但是任务数不多的放置在此线程池中执行
* @return
*/
public static ExecutorService getUnboundedThreadPool() {
return unboundedThreadPool;
}
/**
* 创建一个最大并发为150个线程的有界线程池
*/
private final static ExecutorService boundedThreadPool = new ThreadPoolExecutor(50, 150, 120, TimeUnit.SECONDS, new LinkedBlockingQueue<>(2048), (r, executor) -> log.error("服务等待队列已经超过限制，当前任务被丢弃"));
/**
* 该线程池最多可以有150个并发线程，可以将业务中轻功能放在该池中执行
* @return
*/
public static ExecutorService getBoundedThreadPool() {
return boundedThreadPool;
}
/**
* 创建一个缓存线程池
*/
private final static ExecutorService cacheExecutor = Executors.newCachedThreadPool();
/**
* 该线程池会有无限多的线程，根据业务动态改变
* 正对业务中轻业务可以放在此池中执行
* @return
*/
public static ExecutorService getCacheThreadPool() {
return cacheExecutor;
}
}
