StringBuilder引起的OOM[线上]

背景

最近一个大版本上线，上线前做了codereview，发布时也只发了一台机器，放量10%，结果这一台机器到了晚上10点时，eureka状态被置为outofservice；当时没有同视这一情况，加上各种产品催，冒着风险全量发布了，晚上6点左右被叫去分析问题，晚上8点左右服务器出现内存异常升高，机器上的应用直接被系统kill掉，晚上9：21服务不可用，工单狂涨，然后回滚，20分钟后恢复服务。
服务高峰期是晚上6:30到8:30,这是典型的死在了下坡上。从这种现象分析，泄漏点不是核心流程。

分析

第二天重启组织代码分析，dump文件(出事前把流量切断dump出来的)分析。

一、通过jProfiler分析

堆内存使用仅283M，线程倒是很多，然后啥也没能分析出来

二、通过MAT分析

使用MAT查看内存使用的饼图，跟jprofiler的情况是差不多的。

点南[Dominator Tree] 去查看大对象

这样看也是啥也看不出来，那么分析一下，上一个版本的代码没出问题，这个版本的代码了出现这种情况，那肯定是这之间改动有关，查找这期间改动的类，进行分析。

在顶部Class Name下面的查询输入框中输入包名或类名进行查找，结果发布

把StringBuilder做为成员变量了！！！！！
分析相关代码，终于找到真相，在方法中，调用了StringBuilder#append(String)方法， 而且这几个方法都是用户在核心流程完成之后，会调用的接口执行，所以这也解释了为啥会死在下坡上。

总结

1、在上线后发现问题，并且没有找到原因的情况下，严禁全量发布。
2、使用一些静态扫描工具分析代码，添加会引起故障的扫描规范在上线前扫代码。
3、出现问题，要眼观全局，当事情无法快速定位、快速恢复的情况下，及时回滚。
4、对线上一定要有敬畏之心！！！！敬畏之心！！！！敬畏之心！！！！