简单的OOM异常分析

示例程序

@RestController
public class TestController {

    @RequestMapping("/oom")
    public void OOM(){
        ArrayList<User> list=new ArrayList<User>();
        int i=0;
        while(true){
            i++;
            User user=new User();
            user.name="value"+i;
            list.add(user);
        }
    }
    class User{
        String name;
    }
}

OOM发生的过程

1：最开始会填满Eden区域，触发minor gc，但是第一次minor gc只是标记存活对象，之后如果eden区域还是不够，会进行第二次minor gc，这一次会将经过两次回收还存活的对象晋升到survivor
2：多次minor gc之后，会出现两种情况，survivor空间不足，而且回收不掉，那么对象就会被分配到老年代，还有一种就是在survivor区域的年龄超过15岁（这个数字不是固定的）的对象会被晋升到老年代
3：经过以上两个步骤，老年代空间出现不足，触发full gc，多次full gc之后空间还是不足，那么就会报OOM异常

JVM参数修改

-Xms30m -Xmx30m -XX:+PrintGCDetails -XX:+HeapDumpOnOutOfMemoryError -XX:-UseGCOverheadLimit -XX:HeapDumpPath=./dump.hprof

MAT分析dump.hprof

Dominator Tree与Leak Suspects结合，分析出内存中的大对象，
1：关注Dominator Tree里边占比最高的几个
2：Leak Suspects会给一个初步分析，可以作为参考，主要看Dominator Tree
经过分析我们发现内存中很多User对象，然后可以搜索User相关的代码，看是否可以优化重写