排查订单导出内存占用率逐步增大的问题

症状

每次导出，导出的内存利用率都会小幅或大幅增长。一次VIP导出后，导出的内存利用率会较大增长。

十次较小导出的结果，从 15:30 有一个小步的内存利用率攀升。

一次VIP大流量导出的结果，从 14:04 有一个大幅的陡峭的攀升。

基本步骤

STEP1:
运行一次比较大的导出后，使用 jmap 工具从服务器生成内存文件 mem.bin。使用 top -c M 拿到占用内存最高的 pid;然后

sudo su app
jmap -dump:live,format=b,file=/tmp/mem.bin pid
chmod 777 /tmp/mem.bin

STEP2:
将 mem.dat scp 到本地

scp [email protected]:/tmp/mem.bin /tmp/mem.bin
scp [email protected]:/tmp/mem.bin /tmp/mem.bin

STEP3:
在 http://www.eclipse.org/mat/downloads.php 下载 MAT 工具，解压安装即可。
打开 mem.dat

STEP4: 分析内存文件，定位原因和修复问题。

第一轮优化

概览

Overview: 内存全貌，找到最大内存占用对象；

点击TopConsumers， 概览所有占用内存比较较大的对象集合。

点击 DominatorTree (支配树) ，可以看到所有占用内存比较多的对象的引用链

内存占用明细分析

点击 Leak Suspects ，查看内存泄露的最大嫌疑。可以看到 export-execute-thread1 占用了一个大对象列表 List。

线程栈引用

分析和定位原因

为什么这些对象被导出任务线程持有？ 原因很可能是：导出线程是 Context 持有者，Context 在导出结束时没有清理， 而线程因为某种原因没有退出和被回收，导致 Context 依然在内存里。 做了个 Context 清理之后，再部署并 dump 文件，发现之前的List大对象已经没有了。

第二轮优化

清理 Context 之后，重新运行发现内存占用依然逐增。 重新 dump， 发现貌似 groovy 脚本导致。原因可能是： 在每次导出前，都会把字段配置的groovy脚本加载到单个线程中，而导出结束时这些脚本没有清理。再做一层脚本引用的清理:

fieldConfig.getCacheScript().setBinding(null);
fieldConfig.setCacheScript(null);

发现不再有 Groovy 脚本占用内存的嫌疑。

第二轮优化后，虽然 groovy 的嫌疑有所减轻，可是还是没有完全消除。这下，从代码上确实看不出什么了。

第三轮优化

原来的策略是每次导出，都从数据库的配置克隆一份配置，创建一个缓存的Script对象，导出结束时清除（可能没真正清除掉）；现在的策略是，做一个Script对象的缓存池。如果没有Script对象的执行，那么也不会创建多余的Script占用空间。从30天内存占用率图来看，在最后一次发布后，尽管有多次大流量导出，内存占用保持平稳。

参考文章

https://eclipsesource.com/blogs/2013/01/21/10-tips-for-using-the-eclipse-memory-analyzer/
http://www.lightskystreet.com/2015/09/01/mat_usage/
https://blog.csdn.net/wanghuiqi2008/article/details/50724676
https://www.jianshu.com/p/efec4c77e265
https://www.ibm.com/developerworks/cn/opensource/os-cn-ecl-ma/index.html?ca=drs-
https://blog.csdn.net/dashuniuniu/article/details/52224882

原文地址：https://www.cnblogs.com/lovesqcc/p/9521047.html