大家好，我是鸭血粉丝（大家会亲切的喊我 「阿粉」），是一位喜欢吃鸭血粉丝的程序员，回想起之前线上出现 OOM 的场景，毕竟当时是第一次遇到这么 紧脏 的大事，要好好记录下来。
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 日志，定位到具体的对象信息。
2.3 根本原因
通过日志分析以及 dump 文件分析，都指向了某个文件导出接口，接着在代码中分析该接口具体调用链路，发现导出的数据很多，而且老代码进行计算的逻辑嵌套了很多 for 循环，而且是 for 循环调用数据库，计算效率极低。
模拟了该用户在这个接口的所调用数据量，需要查询多个表，然后 for 循环中大概会计算个 100w+ 次，导致阻塞了其它请求，由于请求未结束，java 对象无法被 GC 回收，线上的服务器 CPU 和内存使用情况一直飙升。
3 性能优化
3.1 业务、代码逻辑梳理
点开该段代码的 git 提交记录，发现是我在实习期写的时候，我的内心是崩溃的，当时对业务不熟悉，直接循环调用了老代码，而且也没有测试过这么大的数据量，所以 GG了。
然后我就开始做代码性能优化，首先仔细梳理了一下整个业务流程，通过增加 SQL 查询条件，减少数据库 IO 和查询返回的数据量，优化判断条件，减少 for 嵌套、循环次数和计算量。
3.2 通过 VisualVM 进行对比
官方描述：
VisualVM，能够监控线程，内存情况，查看方法的CPU时间和内存中的对象，已被GC的对象，反向查看分配的堆栈(如100个String对象分别由哪几个对象分配出来的).
该插件不需要另外下载，在 ${JAVA_HOME}/bin 目录下就能找到，所以安装了 jdk 就能使用它~
对比了新老代码所占用的 CPU 时间和内存状态
优化前：
优化后：
通过上述优化之后，计算 1w 条数据量，进行导出成报表文件，在老代码需要 48s，新代码下降到了 8s，不过这是大数据量的情况下，实际用户的数据没有这么多，所以基本上满足了线上 99% 的用户使用。（看到这个结果时，阿粉露出了「纯洁的微笑」）
当然，由于这些数据是本地开发环境新增加的，与出现 OOM 问题的用户数据量还有些差别，但通过优化后的代码，已经在数据库查询的时候就过滤掉很多无效的数据，在 for 循环计算前也加了过滤条件，所以真正计算起来起来就降低了很多计算量！
恩，自己代码优化好了，还要等测试爸爸们测试后才敢上线，这次要疯狂造数据！
4 技术总结
阿粉周末会自己做点饭????，喜欢看王刚老师的视频，觉得最后出现的 「技术总结」 很棒，让我能够快速记住重要步骤
（但学习跟做饭一样，还是得经过反复看和实践才能好好记住，哼儿哈儿，大伙知道阿粉想说的是啥了吧哈哈哈）
4.1 开发注意点
在开发初期，阿粉没有考虑到性能问题，想着满足需求就完成任务，但数据量一大起来，就有可能出现这些 OOM 问题，所以以后开发时，需要先提前考虑以下几点：
- 梳理设计流程
- 考虑是否有性能问题
- 与产品经理商量控制查询条件，减少查询的范围
- 与数据库交互时，减少无效的查询，合并查询和合并更新操作
- 减少 for 循环，尤其注意多层 for 循环嵌套问题！
- 调用老代码要注意=-=
4.2 应对故障注意点
出现问题时也不要惊慌，好好去解决它才是王道，「在解决问题中学到更多技术」
可以参考以下步骤：
- 保留现场，dump 堆栈信息
- 进行限流，对出现问题的接口进行降级
- 如没有降级措施，服务器本身无法快速恢复正常，联系运维重启进行恢复的同时，记录下有可能出现问题的数据，等待后面修复
- 日志、堆栈信息分析
- 定位问题并解决
5 多说两句
在定位到问题时，看到是阿粉写的，原本以为会受到批评，但领导并没有责怪我，还叫阿粉之后好好改，避免下次出现这种问题，心情很开朗，希望各位小伙伴也能遇到这种开明的领导。（肯定不是阿粉的颜值高）
在这次问题排查过程中，熟悉了问题排查步骤，巩固了 jdk 工具的使用方法和流程，也加深了对业务的理解程度，果然 「遇到问题能够快速成长」
同时解决 BUG 后，阿粉的内心更开心了，下班后点了一份小碗鸭血粉丝。
各位小伙伴看完觉得有趣或者有用，来个素质三连，让阿粉能升级吃大碗哈哈哈~
