1 事情回顾
2 开始分析
- 2.1 日志分析
- 2.2 使用 MAT 分析 dump 文件
- 2.3 根本原因
3 性能优化
- 3.1 业务、代码逻辑梳理
- 3.2 通过 VisualVM 进行对比
4 技术总结
- 4.1 开发注意点
- 4.2 应对故障注意点
5 多说两句
1 事情回顾
在某次周五，通过 Grafana 监控，发现线上环境突然出现CPU和内存飙升的情况：
但是看到网络输出和输入流量都不是很高，所以网站被别人攻击的概率不高，后来其它服务器的负荷居高不下。
阿粉先 dump 下当时的堆栈信息，保留现场，接着进行了简单的分析，为了稳住用户，通知运维一台一台服务器进行重新启动，让大家继续使用服务。
接着就开始分析和回顾事情了
2 开始分析
2.1 日志分析
建议大家了解一些常用的 Linux 语法，例如 Grep 查询命令，是日志分析的一大利器，还能通过正则表达式查询更多内容。
、既然服务器在某个时间点出现了高负荷，于是就先去找一开始出现问题的服务器，去找耗时比较长的服务，例如我当时去找数据库耗时的服务，由于发生 OOM 时的日志已经被刷掉，于是我大致描述一下：
[admin@xxx xxxyyyy]$ grep '15:14:' common-dal-digest.log | grep -E '[0-9]{4,}ms' 2018-08-25 15:14:21,656 - [(xxxxMapper,getXXXListByParams,Y,1089ms)](traceId=5da451277e14418abf5eea18fd2b61bf)
很明显，上述语句是 查询在15:14那一分钟内，在common-dal-digest.log文件中，耗时超过1000ms的SQL服务（查的是耗时超过10秒的服务）。
日志中有个特殊的标志 traceId，在请求链路中是唯一的，所以根据这个标志能分析单请求的全链路操作，建议大家的日志框架中也加上这种字段，让服务可追溯和排查。
通过 traceId去查 http 保存的访问日志，定位在该时间点内，分发到该服务器上的用户请求。还有根据该traceId，定位到整个调用流程所使用到的服务，发现的确十分耗时...
于是拿到了该请求具体信息，包括用户的登录手机号码，因为这个时候，其它几台服务器也出现了 CPU 和内存负载升高，于是根据手机号查询了其它几台服务器的访问日志，发现同一个请求，该用户也调用了很多次...
于是初步确认了某个耗时接口
2.2 使用 MAT 分析 dump 文件
官方介绍：
MAT是Memory Analyzer的简称，它是一款功能强大的 Java 堆内存分析器。可以用于查找内存泄露以及查看内存消耗情况。MAT 是基于Eclipse开发的，是一款免费的性能分析工具。读者可以在 http://www.eclipse.org/mat/ 下载并使用 MAT。
在前面提到，出现问题时，顺手保存了一份堆栈信息，使用工具打开后，效果图如下所示：
整个应用的内存大小 1.6G，然后有一块内存块竟然占用了 1.4G，占比达到了 87.5%，这也太离谱了吧！
于是阿粉决定好好分析该对象的引用树，右键选择【class_reference】，查看对象列表，和观察 GC 日志，定位到具体的对象信息。
