Java 的异常体系

一个思维导图回顾一下 Java 的异常体系。

​

上面的图片没有罗列出所有的异常类型，但也基本概括了 Java 异常的继承体系。所有的异常类都继承自 Throwable ，Throwable 有两个直接子类 Error 和 Exception 。

Exception 一般指可以/应该捕获和处理的异常。它的两个直接子类 IOException 和 RuntimeException 及其子类都是我们在代码中经常遇到的一些错误。RuntimeException 是在程序运行中可能发生的异常，我们可以不捕获它，但可能带来 Crash 的代价，但是过多的捕获异常又不利于暴露和调试异常情况。在开发过程中，我们更多的应该及时暴露问题。除了 RuntimeException 以外，其他异常可以统称为 非运行时异常 或者 受检异常，这些异常必须被捕获，否则编译期就会报错。

Error 一般指非正常状态的，比较严重的，不应该被捕获的系统错误。

再回头看看 OutOfMemoryError 的父类们，

OutOfMemoryError <- VirtualMachineError <- Error

OutOfMemoryError 是一个 Error ，Error 不应该被捕获。那么，捕获 OutOfMemoryError 有什么意义呢？

捕获 OutOfMemoryError 有什么意义？

一般情况下并没有什么太大意义，相信你在开发中也几乎没有写过 catch OOM 的代码。

如果你把捕获 OOM 当做处理 OOM 的一种手段，无疑是不合适的。你无法保证你 catch 的代码就是导致 OOM 的原因，可能它只是压死骆驼的最后一根稻草，甚至你也无法保证你的 catch 代码块中不会再次触发 OOM 。

我也从来没有写过捕获 OOM 的代码，但无意中在 Android 源码中发现了这样的操作。在 View.java 的 buildDrawingCacheImpl() 方法中有这么一段代码：

try {
    bitmap = Bitmap.createBitmap(mResources.getDisplayMetrics(),
                        width, height, quality);
    bitmap.setDensity(getResources().getDisplayMetrics().densityDpi);
    if (autoScale) {
        mDrawingCache = bitmap;
     } else {
         mUnscaledDrawingCache = bitmap;
     }
     if (opaque && use32BitCache) bitmap.setHasAlpha(false);
} catch (OutOfMemoryError e) {
    // If there is not enough memory to create the bitmap cache, just
    // ignore the issue as bitmap caches are not required to draw the
    // view hierarchy
    if (autoScale) {
        mDrawingCache = null;
    } else {
        mUnscaledDrawingCache = null;
}
mCachingFailed = true;
......

buildDrawingCacheImpl() 方法的大致作用是为当前 View 生成一个 Bitmap 缓存。在构建 Bitmap 对象的时候，如果捕捉到了 OOM ，就放弃生成 Bitmap 缓存，因为在 View 的绘制过程中 Bitmap Cache 并不是必须存在的。所以在这里没有必要抛出 OOM ，而是自己捕获就可以了。

在你自己明确知道可能发生 OOM 的情况下设置一个兜底策略，这可能是捕获 OOM 的唯一意义了。如果你有其他奇淫技巧，欢迎在评论区补充。

JVM 中哪一块内存不会发生 OOM ？

最后补充一道我曾经遇到过的面试题，JVM 中哪一块内存不会发生 OOM ？

当时面试的时候一下没反应过来，回来之后翻了翻 《深入理解Java虚拟机》 。但凡是 JVM 的相关问题，基本上都可以在这本书上找到答案。以下内容均总结摘抄自这本书，也可以查看我的相关读书笔记：第2章：Java内存区域与内存移溢出异常 。

Java 虚拟机在执行 Java 程序的过程中会把它所管理的内存划分为若干个不同的数据区域，如下图所示：

​

Java 虚拟机栈 。每个方法被执行的时候，Java 虚拟机栈都会同步创建一个栈帧用于存储局部变量表、操作数栈、动态连接、方法出口等信息。每个方法被调用直到执行完毕的过程，就对应着一个栈帧在虚拟机栈中从入栈到出栈的过程。

如果线程请求的栈深度大于虚拟机所允许的深度，将抛出 StackOverflowError 异常。如果 Java 虚拟机栈支持动态扩展，当栈扩展时无法申请到足够的内存会排抛出 OutOfMemoryError 异常。

本地方法栈。为虚拟机使用到的 Native 方法服务。《Java 虚拟机规范》对本地方法栈中方法使用的语言、使用方式和数据结构并没有任何强制规定，因此具体的虚拟机可以根据需要自由实现它。Hotspot 将本地方法栈和虚拟机栈合二为一。

本地方法栈也会在栈深度溢出和栈扩展失败时分别抛出 StackOverflowError 和 OutOfMemoryError 。

Java 堆。所有线程共享的一块内存区域，在虚拟机启动时创建。此内存区域的唯一目的就是存放对象实例，Java 世界里 “几乎” 所有的对象实例都在这里分配内存。在 《Java 虚拟机规范》中对 Java 堆的描述是：“所有的对象实例以及数组都应当在堆上分配”。

Java 堆以处于物理上不连续的内存空间，但在逻辑上它应该被视为连续的。但对于大对象(典型的如数组对象)，多数虚拟机实现出于实现简单、存储高效的考虑，很可能会要求连续的内存空间。

Java 堆既可以被实现成固定大小，也可以是扩展的。如果在 Java 堆中没有内存完成实例分配，并且堆无法再扩展时，Java 虚拟机将会抛出 OutOfMemoryError 。

方法区。方法区是各个线程共享的内存区域，它用于存储已被虚拟机加载的类型信息、常量、静态变量、即时编译器编译后的代码缓存等数据。

Hotspot 设计之初选择把垃圾收集器的分代设计扩展至方法区，或者说使用永久代来实现方法区而已，使得 HotSpot 的 GC 能够像管理 Java 堆一样管理这部分内存，但导致 Java 应用更容易遇到内存溢出的问题。在 JDK 8 中，彻底废弃了永久代的概念。

如果方法区无法满足新的内存分配的需求时，将抛出 OutOfMemoryError 。

运行时常量池。方法区的一部分。Class 文件的常量池表，用于存放编译期生成的各种字面量与符号引用，这部分内容将在类加载后方法方法去的运行时常量池。

运行时常量池具有动态性，运行期间也可以将新的常量放入池中，如 String.intern() 。

常量池受到方法区的限制，当无法再申请到内存时，会抛出 OutOfMemoryError 。

唯一一个在《Java虚拟机规范》中没有规定任何 OutOfMemoryError 情况的区域是 程序计数器。程序计数器（Program Counter Register）是一块较小的内存空间，它可以看作是当前线程所执行的字节码的行号指示器。如果线程正在执行的是一个Java方法，这个计数器记录的是正在执行的虚拟机字节码指令的地址；如果正在执行的是本地（Native）方法，这个计数器值则应为空（Undefined）。