从 JVM 角度理解内存溢出（OOM）

一 点睛

内存溢出相对于内存泄漏来说，尽管更容易被理解，但是同样的，内存溢出也是引发程序崩溃的罪魁祸首之一。

由于 GC 一直在发展，所以一般情况下，除非应用程序占用的内存增长速度非常快，造成垃圾回收已经跟不上内存消耗的速度，否则不太容易出现 OOM 的情况。

大多数情况下，GC 会进行各种年龄段的垃圾回收，实在不行了就放大招，来一次独占式的 FullGC 操作，这时候会回收大量的内存，供应用程序继续使用。

javadoc 中 对 OutOfMemoryError 的解释是，没有空闲内存，并且垃圾收集器也无法提供更多内存。

二 没有空闲内存的情况

Java 虚拟机的堆内存不够，原因有二个。

1 Java虚拟机的堆内存设置不够

a 可能存在内存泄漏问题。

b 也很有可能就是堆的大小不合理，比如我们要处理比较可观的数据量，但是没有显式指定 JVM 堆大小或者指定数值偏小。我们可以通过参数 -Xms 、-Xmx 来调整。

2 代码中创建了大量大对象，并且长时间不能被垃圾收集器收集（存在被引用）

对于老版本的 Oracle JDK，因为永久代的大小是有限的，并且 JVM 对永久代垃圾回收（如，常量池回收、卸载不再需要的类型）非常不积极，所以当我们不断添加新类型的时候，永久代出现 OutOfMemoryError 也非常多见，尤其是在运行时存在大量动态类型生成的场合；类似 intern 字符串缓存占用太多空间，也会导致 OOM 问题。对应的异常信息，会标记出来和永久代相关：“java.lang.OutOfMemoryError:PermGen space"。

随着元数据区的引入，方法区内存已经不再那么窘迫，所以相应的 OOM 有所改观，出现 OOM，异常信息则变成了：“java.lang.OutofMemoryError:Metaspace"。

直接内存不足，也会导致 OOM。

三 垃圾收集器也无法提供更多内存

这里面隐含着一层意思是，在抛出 OutOfMemoryError之前，通常垃圾收集器会被触发，尽其所能去清理出空间。

例如：在引用机制分析中，涉及到 JVM 会去尝试回收软引用指向的对象等。

在 java.nio.BIts.reserveMemory() 方法中，我们能清楚的看到，System.gc（）会被调用，以清理空间。

四 特殊情况

当然，也不是在任何情况下垃圾收集器都会被触发的。

比如，我们去分配一个超大对象，类似一个超大数组超过堆的最大值，JVM 可以判断出垃圾收集并不能解决这个问题，所以直接抛出 OutOfMemoryError。