告警
正在散会，忽然钉钉告警声音个不停，同时市场人员反馈客户在投诉零碎登不进了，报504谬误。查看钉钉上的告警信息，几台业务服务器节点全副报CPU超过告警阈值，达100%。
连忙从会上下来，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高线程的执行栈信息。如下图所示，
- 与共事确认，该处为应用一个框架的excel导出性能，并且，导出excel时没有分页，没有限度！！！查看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/d... ）关上，如图
如果dump文件比拟大，须要增大MemoryAnalyzer.ini配置文件中的-Xmx值
发现占用内存最多的是char[], String对象，通过右键能够查看援用对象，但点开貌似也看不出所以然来，进入内存泄露报告页面，如图
该页面统计了堆内存的占用状况，并且给出疑似泄露点，在上图中点开“see stacktrace”链接，进入线程栈页面，
似曾相熟的画面，还是跟excel导出无关，数据太多，导致内存溢出。。。于是GC频繁，于是CPU爆了。本源还是同一个。
总结
本文以解决一次线上服务CPU 100%的实战过程示例了在遇到Java服务造成服务器CPU耗费过高或内存溢出的个别解决办法，心愿对大家定位线上相似问题提供参考。同时，开发实现性能时须要思考的更深远一些，不能停留在解决以后的场景，须要思考数据量一直增大时，你的实现是否还能实用。俗话说，高级程序员解决以后问题，中级程序员解决两年后的问题，高级程序员解决五年后的问题，^_^。
[转载请注明出处]
作者：雨歌
欢送关注作者公众号：半路雨歌，查看更多技术干货文章