深入理解java虚拟机(第三版)笔记-OOM实战

java堆溢出

我们只要不断创建对象，保证GC Roots到对象之间有可达路径来避免垃圾回收机制清楚这些对象，那么随着对象数量的增加，总容量触及最大堆的容量限制后就会发生内存溢出异常。

可以限制java堆的大小为20MB，不可扩展(将堆的最小值-Xms和最大值-Xmx设置为一样可以避免堆自动扩展)，通过参数

-XX:+HeapDumpOnOutOfMemoryError可以让虚拟机在出现内存异常的时候Dump出当前的内存堆快照以便进行事后分析。

public class OOMTest {
    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_pid3332.hprof …
Heap dump file created [28339396 bytes in 0.072 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:265)
at java.util.ArrayList.ensureExplicitCapacity(ArrayList.java:239)
at java.util.ArrayList.ensureCapacityInternal(ArrayList.java:231)
at java.util.ArrayList.add(ArrayList.java:462)
at JVM.OOMTest.main(OOMTest.java:14)

生成hprof文件在项目根目录下，可以用eclipse的分析软件Eclipse Memory Analyzer进行分析，(Jprofiler貌似更好用但是收费)。

根据堆快照它会自动分析可能存在的问题，Suspect 1就指出了是java.lang.Object[]大量堆积，我们刚好用的就是ArrayList，泛型擦除后就是Object数组，展开看一下发现全是我们往里加的OOMObject对象

单击某个对象，可以查看到GC Roots的path，现实中碰到问题可以查看到底是怎么和GC Root连接上导致无法被回收的，进而定位问题代码所在。如果对象都是必须存活的，那就看-Xms -Xmx是否还有调整的空间，以及代码设计的是否合理。

虚拟机栈和本地方法栈溢出

HotSpot虚拟机并不区分虚拟机栈和本地方法栈，因此-Xoss参数(设置本地方法栈大小)没有任何效果，栈容量只能由-Xss参数来设置。《java虚拟机规范》中描述了两种异常：

• 如果线程请求的深度大于虚拟机所允许的最大深度，将抛出StackOverflowError异常
• 如果虚拟机内存允许动态扩展，当扩展容量无法申请到足够内存时，将抛出OOM异常

但是HotSpot虚拟机不支持扩展栈，所以除非在创建线程时就无法获得足够内存而出现OOM异常 ，否则在线程运行时是不会因为扩展而导致内存溢出的，只会因为栈容量无法容纳新的栈帧而导致SOF异常。

下面可以通过两个实验，尝试能否让HotSpot虚拟机产生OOM异常

• 使用-Xss参数减小栈内存容量

  结果：抛出SOF异常

• 定义大量本地变量，增大此方法中本地变量表的长度

  结果：抛出SOF异常

第一个实验的代码：

// -Xss180k
public class StackSOF {
    private int stackLength = 1;

    public void stackLeak() {
        stackLength++;
        stackLeak();
    }

    public static void main(String[] args) {
        StackSOF sof = new StackSOF();
        try {
            sof.stackLeak();
        } catch (Throwable e) {
            System.out.println("stack length: " + sof.stackLength);
            throw e;
        }
    }
}

stack length: 1728
Exception in thread “main” java.lang.StackOverflowError
at JVM.StackSOF.stackLeak(StackSOF.java:7)
at JVM.StackSOF.stackLeak(StackSOF.java:8)
at JVM.StackSOF.stackLeak(StackSOF.java:8)
at JVM.StackSOF.stackLeak(StackSOF.java:8)
at JVM.StackSOF.stackLeak(StackSOF.java:8)

…

第二个实验，代码太长了，直接粘书上的了

运行结果：

结论：无论是由于栈帧太大还是虚拟机栈容量太小，当新的栈帧内存无法分配的时候，HotSpot虚拟机抛出的都是SOF异常。如果是允许动态扩展栈容量大小的虚拟机上，第二个实验代码抛出的会是OOM异常。

如果代码不局限于单线程，而是不停分配线程，那么当线程无法分配的时候就会抛出OOM异常：

出现SOF异常时，会有明确的错误堆栈可供分析，相对容易定位到问题所在，如果使用HotSpot默认参数，栈深度大多数情况下到达1000-2000完全没有问题。但是如果是因为建立线程过多而导致的OOM，在不能减少线程数量或者更换64位虚拟机的情况下，只能通过减少最大堆和减少栈容量来换取更多线程。

方法区和运行时常量池溢出

运行时常量池是方法区的一部分，在jdk 8中使用元空间实现方法区。如果在jdk1.6中进行测试下面的代码，是会出现永久代的OOM异常的

但是jdk1.7的时候把字符串常量池和静态变量移到java堆中了，所以在jdk1.7及以上的版本中不论设置-XX:MaxPermSize还是在jdk1.8中设置-XX：MaxMetaspaceSize都不会让字符串常量池发生内存溢出，这个时候只要通过-Xmx6m设置最大堆内存就能发生字符串常量池的溢出。

方法区主要是存放类型的相关信息，如类名、访问修饰符、常量池、字段描述、方法描述等。对于方法区的测试，大体的思路是产生大量的类去填充方法区，由于jdk1.7中还有永久代，只要调低永久代的最大值，就可以让永久代发生OOM异常。

到了jdk1.8，改用元空间实现方法区，默认配置下很难让虚拟机产生方法区OOM异常了，但是HotSpot还是提供了一些参数作为元空间的防御措施：

• -XX:MaxMetaspaceSize 设置元空间最大值，默认是-1，不受限制(即受限于本机内存)
• -XX:MetaspaceSize 指定元空间的初始大小，以字节为单位，打到该值就出发垃圾收集进行类型卸载，同时收集器会对该值进行调整；如果释放了大量的空间，就适当降低该值；如果释放了很少的空间，那么在不超过Max值的情况下适当提高该值
• -XX:MinMetaspaceRatio 在垃圾收集之后控制最小的元空间剩余容量的百分比，可以减少因为元空间不足导致的垃圾收集的频率。

直接内存溢出

直接内存容量大小可以通过-XX:MaxDirectMemorySize参数来设置，如果不指定默认和java堆最大值一致。通过DirectByteBuffer分配内存可以抛出OOM异常，但是该方法是通过计算得知内存无法分配就直接抛出异常的，并没有真正分配。真正申请分配内存的是Unsafe::allocateMemory()方法，但是Unsafe类只有引导类加载器才会返回实例，设计者希望只有虚拟机标准库里的类才能使用Unsafe的功能，所以需要通过反射来获取Unsafe实例。

// -Xmx20m -XX:MaxDirectMemorySize=10m
public class DirectMemoryOOM {
    private static int _1MB = 1024 * 1024;
    public static void main(String[] args) throws IllegalAccessException {
        Field unsafeField = Unsafe.class.getDeclaredFields()[0];
        unsafeField.setAccessible(true);
        Unsafe unsafe = (Unsafe)unsafeField.get(null);
        while (true) {
            unsafe.allocateMemory(_1MB);
        }
    }
}

直接内存导致的内存溢出，一个明显的特征就是HeapDump文件中不会看见有什么明显的异常情况，如果实际中碰到内存溢出后Dump文件又很小，程序中还直接或间接使用了DirectMemory(比如使用了NIO)，就可以重点检查一下直接内存的原因了。