征服Android面试官路漫漫（二）：关于OutOfMemoryError是否可以被try-catch的探讨

2401_84007049

于 2024-04-13 14:34:59 发布

阅读量621

点赞数 7

分类专栏： 2024年程序员学习文章标签： android

本文链接：https://blog.csdn.net/2401_84007049/article/details/137715065

版权

2024年程序员学习专栏收录该内容

214 篇文章 0 订阅

订阅专栏

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 。

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

虽然《Java 虚拟机规范》中把方法区描述为堆的一个逻辑部分，但是它却有一个别名叫做“非堆”，目的是与 Java 堆分开来。

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

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

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

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

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

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

如何进阶Android？

有些东西你不仅要懂，而且要能够很好地表达出来，能够让面试官认可你的理解，例如Handler机制，这个是面试必问之题。有些晦涩的点，或许它只活在面试当中，实际工作当中你压根不会用到它，但是你要知道它是什么东西。

对于程序员来说，要学习的知识内容、技术有太多太多，要想不被环境淘汰就只有不断提升自己，从来都是我们去适应环境，而不是环境来适应我们！

最后我在这里分享一下这段时间从朋友，大佬那里收集到的一些2019-2020BAT 面试真题解析，里面内容很多也很系统，包含了很多内容：Android 基础、Java 基础、Android 源码相关分析、常见的一些原理性问题等等，可以很好地帮助我们深刻理解Android相关知识点的原理以及面试相关知识。

1、确定好方向，梳理成长路线图

不用多说，相信大家都有一个共识：无论什么行业，最牛逼的人肯定是站在金字塔端的人。所以，想做一个牛逼的程序员，那么就要让自己站的更高，成为技术大牛并不是一朝一夕的事情，需要时间的沉淀和技术的积累。

关于这一点，在我当时确立好Android方向时，就已经开始梳理自己的成长路线了，包括技术要怎么系统地去学习，都列得非常详细。