记一次老商家端应用内存突然飚高原因分析
一、排查过程
问题发现是因为当时接到了内存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方面入手进行功能的优化，不断为提升商家体验而努力。
三、总结分析
回过头来咱们再分析以下这个功能，通过系统日志及监控，发现该功能商家日常使用较少，并且大部分商家的保质期商品较少，极少数会存在有非常多保质期商品数据的情况。但是一旦出现这样的问题就会很致命，所以在导出功能设计之初我们就应该考虑到将来任何可能出现的情况，并做好提前的预防。另外就是要做功能的限制，例如导出次数、导出数据量的限制功能来保障商家体验及系统的安全稳定。
另外再说一下，对导出功能的理解，对于商家而已，导出需求是正常的。但是过多大批量数据的一起导出无论对哪个系统来说都是非常危险的一个功能。以下列举了一些个人总结的导出功能设计时的一些常见规则，希望大家一起参与讨论分析，拙见如下：
- 明确导出数据的价值分析
- 明确导出数据的使用倾向
- 明确导出数据的安全要求
- 明确导出数据的权限控制
- 明确需要导出的数据量级
- 明确导出数据的方式方法
- 明确到仓数据的频率频次
- 明确导出数据的性能效率
- 明确导出数据的限制方法
- 明确导出功能的隔离及降级方案
- 明确导出数据的格式样式
- 明确导出数据的下载方案
- 明确导出数据的错误监控
以上是个人想到的一些导出设计的简单规则，需要产研测一起沟通明确，还希望大家多提提意见，一起完善导出规则。
另外我们再从商家角度来考虑一下导出的目的，个人从询问业务及相关人员，发现商家导出数据有以下一些目的：
- 存储归档方便查历史资料
- 利用系统业务数据进行数据分析已指导商家业务工作或给领导汇报工作
- 导出来使用表格工具等其他商家熟悉的工具进行查看，更便捷便利
- 对导出的数据进行加工，并用于其他非京东系统的数据输入
- 无意识的导出并无其他作用
以上是个人总结的一些商家导出的需求目的，其实针对商家导出来说可能还有很多其他目的，我们不能全部都能了解。但是可以积极与商家沟通理解商家的真实目的。
另外，我们需要去分析商家的诉求，挖掘商家需求背后的目的。假如有个服装行业的商家需要做服务订单业务数据、库存数据分析，是否我们可以利用数智侧的系统能力，为商家打造通用的数据分析能力呢，这样既可以避免导出数据手动分析的鸡肋，同时也提升了商家对京东物流的系统使用体验。
以上仅仅代表个人观点，一点愚见，还请大家批评指正！
欢迎大家一起探讨！
作者：京东物流 刘邓忠
来源：京东云开发者社区 自猿其说Tech 转载请注明来源