记一次老商家端应用内存突然飚高原因分析-Toy模板网

这篇具有很好参考价值的文章主要介绍了记一次老商家端应用内存突然飚高原因分析。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

一、排查过程

问题发现是因为当时接到了内存UMP报警信息，如下：

通过查看PFinder发现内存一直在增长，没有停止迹象，触发fullGC也并没有下降趋势：

当机立断，先立即去NP上摘除了此台机器流量，然后继续观察，发现内存依然在不断增长。

随即查看故障分析，并没有得到有效信息：

因为流量已经摘除，那么继续观察到底哪里的问题，约半小时后然后接到了机器的宕机告警如下：

由于在应用启动参数里配置了dump路径，那么就马上去把dump文件下载下来分析。

随后找到对应IP机器的目录，下载了dump文件java_pid432.hprof核对时间没有问题，随即使用MAT工具开展分析，通过泄露分析结果直接就可以看出problem1与problem2都是一个同一个问题，2个线程分别占用1.8G、1.5G：

通过查看问题对应的代码类方法，发现该方法功能是"导出WMS保质期商品数据"，该方法会调用库存分页接口查询保质期商品，大致如下：

1、查询无数据直接导出空表；

2、第一页查询总量小于1000的话直接把数据写入第一个sheet并导出表格；

3、第一页查询总量大于1000则循环分页查询，每1000条数据生成一个sheet表格进行导出。

可以看到，org.apache.poi.hssf.usermodel.HSSFWorkbook对象数量已经达到702个了。

翻看具体代码部分如下：

二、解决思路

经过对该功能代码分析，本着先解决问题的原则，先将循环调用功能进行限制，通过ducc配置导出页数大小限制，来避免一直循环调用。

至此，问题初步解决完毕，调整后没有出现问题。

但是，这个功能的优化并没有结束，随后将该问题及功能逻辑反馈给产品及库存相关方，一起讨论解决商家导出的问题，一方面我们要保障商家体验，另一方面又要确保系统稳定性。后续要从这2方面入手进行功能的优化，不断为提升商家体验而努力。

三、总结分析

回过头来咱们再分析以下这个功能，通过系统日志及监控，发现该功能商家日常使用较少，并且大部分商家的保质期商品较少，极少数会存在有非常多保质期商品数据的情况。但是一旦出现这样的问题就会很致命，所以在导出功能设计之初我们就应该考虑到将来任何可能出现的情况，并做好提前的预防。另外就是要做功能的限制，例如导出次数、导出数据量的限制功能来保障商家体验及系统的安全稳定。

另外再说一下，对导出功能的理解，对于商家而已，导出需求是正常的。但是过多大批量数据的一起导出无论对哪个系统来说都是非常危险的一个功能。以下列举了一些个人总结的导出功能设计时的一些常见规则，希望大家一起参与讨论分析，拙见如下：