现象：
image.png
排查步骤：
1.看内存情况
free -m -h
image.png
2.查看本台机器上的所有进程，找到本项目所属PID
ps axu | grep keep(公司关键字)
image.png
3.从本机器上找jmap工具
image.png
终于找到啦
4.用jmap工具排查
./jmap -histo:live 11505(PID)
./jmap -histo:live 11505 | head -30
image.png
前三十情况
我们发现，最大的对象占用的内存也就20多兆，一般来说不可能是内存泄露（基本都是百万量级），排除此怀疑。后来发现这台机器上有很多项目共享，所以一启动内存就占60%左右。
5.那cpu为什么一下涨40%呢？我们继续排查
//查看本机内存情况
ps -mp 11505 -o THREAD,tid,time | sort -rn | more
image.png
6.用jstack工具分析
//转十六进制
printf "%x" 11588
//查看这个进程中线程情况
./jstack 11505 | grep 2d44 -A 30
image.png
继续查看top的进程
image.png
我们查看了cpu最高的一个进程下的几个子线程，发现并没有占用cpu过多的情况，那可能是大家都占不多，但线程同时开启的太多，并没有及时关闭，导致飚高。
我们继续找了几个线程查看具体情况，发现大部分情况都类似，处于"grpc-default-executor-26" #791 daemon prio=5 os_prio=0 tid=0x00007f8a3404b000 nid=0x4d87 waiting on condition [0x00007f8a0c2ac000]情况：
image.png
我们继续用jstack查看这个进程下的具体情况,发现罪魁祸首就是http-nio-8028-exec-*，可惜这个名字并不能看出什么问题（说明合理命名线程多么重要！）：
./jstack 11505
image.png
将此文件拷贝一份
./jstack 11505 > ~/j.txt
vim j.txt
grep "http-nio-8028-exec" j.txt
//统计个数
grep "http-nio-8028-exec" j.txt | wc -l
居然有196个
我们仔细分析了下这个线程，发现是tomcat在qps较高时会同时启动线程任务池，默认200个，所以基本可以排除代码有问题的可能了。
image.png
继续压测了一晚上之后，发现各项指标都比较平稳。至此，真相大白，告一段落。
