現(xiàn)象：
排查步驟：
1.看內(nèi)存情況
free -m -h
2.查看本臺(tái)機(jī)器上的所有進(jìn)程，找到本項(xiàng)目所屬PID
ps axu | grep keep(公司關(guān)鍵字)
3.從本機(jī)器上找jmap工具
4.用jmap工具排查
./jmap -histo:live 11505(PID)
./jmap -histo:live 11505 | head -30
我們發(fā)現(xiàn)，最大的對(duì)象占用的內(nèi)存也就20多兆，一般來(lái)說(shuō)不可能是內(nèi)存泄露（基本都是百萬(wàn)量級(jí)），排除此懷疑。后來(lái)發(fā)現(xiàn)這臺(tái)機(jī)器上有很多項(xiàng)目共享，所以一啟動(dòng)內(nèi)存就占60%左右。
5.那cpu為什么一下漲40%呢？我們繼續(xù)排查
//查看本機(jī)內(nèi)存情況
ps -mp 11505 -o THREAD,tid,time | sort -rn | more
6.用jstack工具分析
//轉(zhuǎn)十六進(jìn)制
printf "%x" 11588
//查看這個(gè)進(jìn)程中線程情況
./jstack 11505 | grep 2d44 -A 30
繼續(xù)查看top的進(jìn)程
我們查看了cpu最高的一個(gè)進(jìn)程下的幾個(gè)子線程，發(fā)現(xiàn)并沒(méi)有占用cpu過(guò)多的情況，那可能是大家都占不多，但線程同時(shí)開(kāi)啟的太多，并沒(méi)有及時(shí)關(guān)閉，導(dǎo)致飚高。
我們繼續(xù)找了幾個(gè)線程查看具體情況，發(fā)現(xiàn)大部分情況都類似，處于"grpc-default-executor-26" #791 daemon prio=5 os_prio=0 tid=0x00007f8a3404b000 nid=0x4d87 waiting on condition [0x00007f8a0c2ac000]情況：
我們繼續(xù)用jstack查看這個(gè)進(jìn)程下的具體情況,發(fā)現(xiàn)罪魁禍?zhǔn)拙褪莌ttp-nio-8028-exec-*，可惜這個(gè)名字并不能看出什么問(wèn)題（說(shuō)明合理命名線程多么重要?。?
./jstack 11505
將此文件拷貝一份
./jstack 11505 > ~/j.txt
vim j.txt
grep "http-nio-8028-exec" j.txt
//統(tǒng)計(jì)個(gè)數(shù)
grep "http-nio-8028-exec" j.txt | wc -l
我們仔細(xì)分析了下這個(gè)線程，發(fā)現(xiàn)是tomcat在qps較高時(shí)會(huì)同時(shí)啟動(dòng)線程任務(wù)池，默認(rèn)200個(gè)，所以基本可以排除代碼有問(wèn)題的可能了。
繼續(xù)壓測(cè)了一晚上之后，發(fā)現(xiàn)各項(xiàng)指標(biāo)都比較平穩(wěn)。至此，真相大白，告一段落。
