赶紧从会高下来，SSH登录做事器，利用 top 命令查看，几个Java进程CPU占用达到180%，190%，这几个Java进程对应同一个业务做事的几个Pod（或容器）。
定位利用 docker stats 命令查看本节点容器资源利用情形，对占用CPU很高的容器利用 docker exec -it <容器ID> bash 进入。在容器内部实行 top 命令查看，定位到占用CPU高的进程ID，利用 top -Hp <进程ID> 定位到占用CPU高的线程ID。利用 jstack <进程ID> > jstack.txt 将进程的线程栈打印输出。退出容器， 利用 docker cp <容器ID>:/usr/local/tomcat/jstack.txt ./ 命令将jstack文件复制到宿主机，便于查看。获取到jstack信息后，赶紧重启做事让做事规复可用。将2中占用CPU高的线程ID利用 pringf '%x\n' <线程ID> 命令将线程ID转换为十六进制形式。假设线程ID为133，则得到十六进制85。在jstack.txt文件中定位到 nid=0x85的位置，该位置即为占用CPU高线程的实行栈信息。如下图所示，
！
！
查看SQL查询记录，该导出功能一次导出50w条数据，并且每条数据都须要做转换打算，更为糟糕的是，操作者由于导出时久久没有相应，于是连续点击，几分钟内发起了10多次的导出要求。。。于是，CPU被打满，做事崩溃了，我也崩溃了。。办理
对付此类耗资源的操作，一定要做好相应的限定。比如可以限定要求量，掌握最大分页大小，同时可以限定访问频率，比如同一用户一分钟内最多要求多少次。
做事重启后规复。到了下午，又一台做事器节点CPU告警，依前面步骤定位到占用CPU高的线程，如下
"GC task thread#0 (ParallelGC)" os_prio=0 tid=0x00007fa114020800 nid=0x10 runnable "GC task thread#1 (ParallelGC)" os_prio=0 tid=0x00007fa114022000 nid=0x11 runnable
利用命令 jstat -gcutil <进程ID> 2000 10 查看GC情形，如图
创造Full GC次数达到1000多次，且还在不断增长，同时Eden区，Old区已经被占满（也可利用jmap -heap <进程ID>查看堆内存各区的占用情形），利用jmap将内存利用情形dump出来，
jmap -dump:format=b,file=./jmap.dump 13
退出容器，利用 docker cp <容器ID>:/usr/local/tomcat/jmap.dump ./ 将dump文件复制到宿主机目录，下载到本地，利用 MemoryAnalyzer（下载地址：https://www.eclipse.org/mat/downloads.php ）打开，如图
如果dump文件比较大，须要增大MemoryAnalyzer.ini配置文件中的-Xmx值
创造占用内存最多的是char[], String工具，通过右键可以查看引用工具，但点开貌似也看不出以是然来，进入内存透露报告页面，如图
该页面统计了堆内存的占用情形，并且给出疑似透露点，在上图中点开“see stacktrace”链接，进入线程栈页面，
似曾熟习的画面，还是跟excel导出有关，数据太多，导致内存溢出。。。于是GC频繁，于是CPU爆了。根源还是同一个。
总结本文以处理一次线上做事CPU 100%的实战过程示例了在碰着Java做事造成做事器CPU花费过高或内存溢出的一样平常处理方法，希望对大家定位线上类似问题供应参考。同时，开拓实现功能时须要考虑的更深远一些，不能勾留在办理当前的场景，须要考虑数据量不断增大时，你的实现是否还能适用。俗话说，低级程序员办理当前问题，中级程序员办理两年后的问题，高等程序员办理五年后的问题，^_^。
作者：雨歌
欢迎关注作者公众年夜众号：半路雨歌，查看更多技能干货文章
