场景:分页递归调用第三方接口,返回大批量数据,导致OOM异常
模拟代码
// JVM参数 -Xmx2G -Xmn1G
class Node{
public int id;
public String name;
public Node(int id, String name) {
this.id = id;
this.name = name;
}
}
public class TestDemo {
public static void main(String[] args){
method(1);
}
/** 模拟递归方法 **/
private static void method(int page){
// 模拟调动第三方方法,page为模拟分页参数
List resultList = remoteMethod(page);
if (resultList == null) return;
// 处理数据
insertMethod(page,resultList);
// 递归处理下一页
method(++page);
}
/** 模拟处理数据接口 **/
private static void insertMethod(int page,List list){
// 模拟业务数据处理
System.out.println(page + ":" +list.size());
}
/** 模拟第三方接口 **/
private static List remoteMethod(int page){
if (page > 100)
return null;
// 模拟分页数据
List list = new ArrayList();
for (int i = 0; i < 100000; i++) {
list.add(new Node(i,"name"+i,i));
}
return list;
}
}
持续一段时间后,日志不再继续输出,控制台拋OOM异常。
原因分析
使用console查看内存(生产环境各公司一般有内存监控报警系统)
占用情况可看到堆内存使用量持续增高,到达峰值后居高不下,说明内存未被有效回收。
使用jstat命令查看可知持续触发YGC,同时FGC也开始频繁执行,但依旧不能有效回收内存。
但线上环境我们一般分析的是dump日志,使用Eclipse MemoryAnalyzer工具分析并定位。线上环境JVM配置如下参数:-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/temp/dump
,表示一旦虚拟机发生OOM异常时自动打印dump日志道指定文件夹。
解决方法
方法一:将递归内不再使用的大对象置空处理
public class TestDemo {
...
/** 模拟递归方法 **/
private static void method(int page){
// 模拟调动第三方方法,page为模拟分页参数
List resultList = remoteMethod(page);
if (resultList == null) return;
// 处理数据
insertMethod(page,resultList);
// 及时释放对象,以便GC回收,也可使用resultList.clear()清除
resultList = null;
// 递归处理下一页
method(++page);
}
...
}
由于递归调用方法未结束时,方法类的对象如未明确指定为null,则gc是不会将该对象标记为垃圾进行处理,所以我们如果能确定递归对象在递归后不再使用,应尽量显示的将该对象置为null,以便gc回收。经过对象的清除,此时再观察内存使用情况可看到不再像上次那样出现持续增高的情况,而是呈锯齿状上升回落的过程,此说明GC能有效执行回收内存。
方法二:将递归改成while循环方式
public class TestDemo {
...
private static void methodWhile(int page){
boolean flag = true;
do {
// 模拟调动第三方方法,page为模拟分页参数
List resultList = remoteMethod(page);
if (resultList == null) {
flag = false;
continue;
}
// 处理数据
insertMethod(page,resultList);
page++;
}while (flag);
}
...
}
单方法执行while循环,如对象未在while循环外使用,则循环内的对象会自动被gc处理,无需特殊操作。当递归的层级过高或递归内处理的数据量很大时,应优先使用循环方法,否则要考虑对象不能被主动回收的问题导致OOM。