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

症状###

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

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

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

排查步骤###

从网上查资料知，可以使用 MAT 工具来排查此类问题。排查基本步骤如下：

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.bin scp 到本地

scp shuqin@IP:/tmp/mem.bin /tmp/mem.bin
scp shuqin@IP:/tmp/mem.bin /tmp/mem.bin

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

STEP4: 在 MAT 工具打开 mem.bin ，分析内存文件，定位原因和修复问题。

第一轮优化###

概览####

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天内存占用率图来看，在最后一次发布后，尽管有多次大流量导出，内存占用保持平稳。