try-catch OOM，可行吗？

最新推荐文章于 2024-04-20 17:48:41 发布

承香墨影

最新推荐文章于 2024-04-20 17:48:41 发布

阅读量1.8k

点赞数 4

文章标签： java jvm 编程语言 javascript 内存泄漏

本文链接：https://blog.csdn.net/plokmju88/article/details/118586077

版权

try {
  var byte = ByteArray(10000000 * 1024 * 1024)
} catch (ignore: OutOfMemoryError) {
}

首先我们来了解一下，什么是 Error。

在 Java 中，可以被 try-catch 语句捕获的，都是 Throwable 的子类，分为 Error 和 Exception。

其中只有 Exception 可以被捕获，例如最常见的 NullPointException。因为当发生 Error 时，通常表示当前的执行环境，已经无法恢复，通常会直接导致线程终止甚至 JVM 终止。此时再通过 try-catch 捕获这个 Error，也无法恢复运行状态，即捕获毫无意义。

而这里提到的 OutOfMemoryError 也是一个 Error。原则上触发它时，执行环境已经无法恢复，不应该由应用层代码去捕获这个错误。具体可以参见之前的文章《Java 异常捕获》。

接下来，我们再来理清楚 OOM 产生的原因。

OOM 产生的原因很多，比较常见的，有申请大段连续的内存、堆内存不足、程序调用栈内存不足申请更多内存时，都有可能触发 OOM。

多数情况，OOM 触发时，只是压死骆驼的最后一根稻草。也许只是一个简单的申请内存的操作，但此时 JVM 中，已经没有更多内存可分配，并且 GC 也无法缓解，就会引发 OOM。

例如上面这种 OOM，其实就是开启了一个新页面，在页面的布局中加载了一个本地资源，直接导致触发 OOM 了。

那么是不是所有的 OOM 都不能被捕获？其实也有特殊的场景。

想通过 try-catch 成功捕获 OOM，需要 2 个先决条件：

加载一个大图 Bitmap、构造一个大数组对象等，都算是申请大段连续的内存。

当满足这 2 个条件时，触发的 OOM 才是可以被 catch 的。

这种技巧，已经在一些开源库中使用。例如 Volley 中，ImageRequest 中，就有这样一段代码。

在处理图片时，若捕获到 OOM，则放弃此次操作。此时并不会影响程序的正常执行，也就是这个 OOM 被成功 catch 住了。

正如前面说过，触发 Error 时，它的执行环境已经无法恢复。此时会导致线程终止甚至 JVM 终止，这种 Error 不应该由我们应用层去捕获。

理论上我们不应该去主动 catch OOM。哪怕在此处 catch 住了，可 App 当前的执行状态也已经处于「濒危」状态。如果不采取措施，此时不崩，换一个地方也会崩，逃的了初一，逃不过十五。

正确的做法是，主动去管理内存。图片是吃内存的大户，而如果 App 内统一了图片加载库，例如 Glide，在内存吃紧的时候，就可以通过 Glide 主动释放掉一些内存，让 App 恢复到健康的状态。

OOM 作为一个 Error，在某些条件下是可以被 catch 的。仅针对我们可控的代码，并且在 try 块中，由于申请大段连续内存的情况下，触发的 OOM，才是可以被 catch 的。

当 catch 住 OOM 时，应该主动释放一些可控的内存，做好内存管理，避免在后续的操作中，在其他操作中又触发 OOM，导致崩溃。

毕竟，出来混迟早是要还的。

本文对你有帮助吗？留言、好看、转发是最大的支持，谢谢！

Refrence:

-- End --

本文对你有帮助吗？留言、转发、点好看是最大的支持，谢谢！