OOM错误的类关系

上图展示了OutOfMemoryError类的继承关系。可以看到它继承自Error，而不是继承自Exception。所以catch Exception无法捕获OOM异常。由于Error继承自Throwable，所以如果捕获Throwable就可以捕获OOM错误（最好不要这样做！）。

构造一个OOM错误

要理解OOM错误，我们需要首先编写一段代码来抛出这个错误。分配内存时如果内存不足就会抛出这个错误。下面的代码将不断地将字符串插入到List中。显然，它最终会耗尽所有内存，从而抛出OOM 错误：

上面的代码还不够。我们还需要限制JVM的可用内存大小，以便运行时能够快速抛出异常。所以我们需要在VM启动参数中添加以下参数：

接下来，当我们运行这段java代码时，我们可以立即得到OOM错误：

OOM错误和我们的普通的异常有什么不同

从上面的错误信息来看，OOM错误似乎和我们平时遇到的各种Exception没有太大区别：

未处理的异常全部发生，然后向上抛出。如果没有接住，他们就会继续向上扔，直到程序启动。它们都记录了错误发生的堆栈信息（是真的吗？） 既然OOM 作为Error 独立存在，那么显然它肯定和我们平常的Exception 不同。首先我会列出这些差异，稍后再进行分析。

OutOfMemory 类不会等到需要抛出异常才将其加载到内存中。并不是每个OOM错误都会带来异常堆栈，这意味着很多OOM错误不会记录犯罪现场。一般异常是需要抛出时new产生的，而OOM是在JVM初始化时统一实例化的，在后续的操作中使用最初实例化的OOM对象。进行进一步分析

OutOfMemory实例化过程

上面的代码是JVM启动时首先创建一批OOM实例的代码。如果稍后抛出OOM 错误，将直接使用这些实例。

由于OutOfMemory对象是在JVM启动时创建的，所以这个类在JVM启动时肯定已经被加载了，以后就不会再出现new了。

为什么有些OOM不会带上案发现场

首先我们看下面的代码：

这段代码和上面代码唯一的区别是捕获了Throwable，也就是说OOM也能被捕获。然后我们看一下它的输出：

从上面的输出结果可以看出，OOM只会在前4次输出调用堆栈信息，后面的次数就不会输出调用堆栈了。

调用堆栈对于OOM 错误重要吗？其实这并不重要，因为往往导致OOM错误的地方并不是OOM最终爆发的地方。那个时候只是内存耗尽了，所以对于定位问题并不关键，所以这个堆栈信息并不重要。

JVM是如何实现OOM错误只有前4次才有调用堆栈的

如果想知道原因，需要回到上面提到的初始化函数：universe_post_init。它还有一些上面未发布的剩余代码：

这段代码会再创建几个OOM对象，其数量就是代码中硬编码的4。当稍后抛出异常时，它会首先检查此列表中是否有可用的OOM 对象。如果有，就会取出来使用，然后将相关的错误信息和调用栈组装起来扔掉。此列表中的物品是一次性的，使用后将被丢弃。由于总共只有4 个，所以上面的示例代码只输出前4 次的调用堆栈。

OOM错误如何分析解决

以上很多都是OOM实现的基本原理，虽然我们在日常工作中很少见到OOM。但遇到OOM基本上就是一个需要快速解决的大问题。

这样我们就可以分析唯一的一点错误信息了。从上面的代码我们可以知道，不同区域内存溢出抛出的OOM对象是不同的，错误信息也不同，所以我们可以根据这些错误信息进行分析。找出内存从哪个区域溢出。例如上面的示例代码中： Java堆空间代表堆内存溢出。如果错误信息为：PermGen space，则说明Perm区域已经溢出。