//VM options : -Xms20m -Xmx20m -XX:+HeapDumpOnOutOfMemoryError
//将堆的最小值-Xms 和堆的最大值-Xmx 参数设置成一样即可避免堆的自动扩展
//-XX:+HeapDumpOnOutOfMemoryError 可以让虚拟机在出现内存溢出异常的时候Dump出当前的内存堆转储快照以便进行事后分析
public class HeapOOM {
static class OOMobject{
}
public static void main(String[] args) {
List<OOMobject> list = new ArrayList<>();
while (true){
list.add(new OOMobject());
}
}
}
java.lang.OutOfMemoryError: Java heap space
Dumping heap to java_pid81290.hprof ...
Heap dump file created [27799210 bytes in 0.082 secs]
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
at java.util.Arrays.copyOf(Arrays.java:3210)
at java.util.Arrays.copyOf(Arrays.java:3181)
at java.util.ArrayList.grow(ArrayList.java:267)
at java.util.ArrayList.ensureExplicitCapacity(ArrayList.java:241)
at java.util.ArrayList.ensureCapacityInternal(ArrayList.java:233)
at java.util.ArrayList.add(ArrayList.java:464)
at HeapOOM.main(HeapOOM.java:25
Process finished with exit code 1
常规的处理方式:
用内存映像分析工具(如MAT),先确认内存中导致OOM的对象是否必要(分清是内存泄露Memory Leak,还是内存溢出Memory Overflow)
若是内存泄漏,可进一步用工具查看对象到GC Roots的引用链,找到泄露对象是通过怎样的引用路径,与哪些GC Roots相关联,才导致垃圾收集器无法回收它们
如果不是内存泄漏(对象必须存活),那就应当检查Java虚拟机堆参数(-Xms和-Xmx)设置,与机器的内存对比,看看是否还有向上调整的空间
再从代码上检查是否存在某些对象生命周期过长/持有状态时间过长/储存结构不合理等情况
虚拟机栈和本地方法栈溢出
如果线程请求的栈深度大雨虚拟机所允许的最大深度,将抛出StackOverFlowError异常
如果虚拟机的栈内存允许动态扩展,当扩展栈容量无法申请到足够的内存时,将抛出OutOfMemoryError异常
public class JavaVMStackSOF {
private int stackLenth = 1;
public void stackLeak(){
stackLenth++;
stackLeak();
}
public static void main(String[] args) throws Throwable{
JavaVMStackSOF oom = new JavaVMStackSOF();
try {
oom.stackLeak();
}catch (Throwable e){
System.out.println("stack lenth:"+oom.stackLenth);
throw e;
}
}
}
方法区和运行时常量池溢出
在JDK8以后,永久代被元空间代替。
在默认设置下,一般的正常动态创建新类型已经很难出现方法区的溢出异常了
本机直接内存溢出
直接内存(Direct Memory)的容量可以通过-XX:MaxDirectMemorySize参数来指定,
若不去指定,则默认与Java堆最大值(由-Xmx指定)一致
由直接内存导致的内存溢出,又一个明显的特征
在Heap Dump文件中不会看到明显的异常情况,若发现Dump文件很小,而程序中又直接使用了DirectMemory(典型的间接使用就是NIO)
则可以重新检查一下是否是直接内存的问题了