共计 1713 个字符，预计需要花费 5 分钟才能阅读完成。
告警
正在散会，忽然钉钉告警声音个不停，同时市场人员反馈客户在投诉零碎登不进了，报 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 信息后，连忙重启服务让服务复原可用。
5. 将 2 中占用 CPU 高的线程 ID 应用 pringf ‘%xn’ < 线程 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（下载地址：www.eclipse.org/mat/downloa…）关上，如图
如果 dump 文件比拟大，须要增大 MemoryAnalyzer.ini 配置文件中的 -Xmx 值
发现占用内存最多的是 char[], String 对象，通过右键能够查看援用对象，但点开貌似也看不出所以然来，进入内存泄露报告页面，如图
该页面统计了堆内存的占用状况，并且给出疑似泄露点，在上图中点开“see stacktrace”链接，进入线程栈页面，
似曾相熟的画面，还是跟 excel 导出无关，数据太多，导致内存溢出。。。于是 GC 频繁，于是 CPU 爆了。本源还是同一个。
总结
本文以解决一次线上服务 CPU 100% 的实战过程示例了在遇到 Java 服务造成服务器 CPU 耗费过高或内存溢出的个别解决办法，心愿对大家定位线上相似问题提供参考。同时，开发实现性能时须要思考的更深远一些，不能停留在解决以后的场景，须要思考数据量一直增大时，你的实现是否还能实用。俗话说，高级程序员解决以后问题，中级程序员解决两年后的问题，高级程序员解决五年后的问题，^_^。
作者：雨歌