症状###
每次导出，导出的内存利用率都会小幅或大幅增长。一次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天内存占用率图来看，在最后一次发布后，尽管有多次大流量导出，内存占用保持平稳。
参考文章###
10 Tips for using the Eclipse Memory Analyzer
MAT - Memory Analyzer Tool 使用进阶