Android高级性能调优；难以想象的OOM！

时间  2021-08-14 标签 java linux git github markdown 网络 多线程 app socket ionic

前言；

本文发现了一类OOM(OutOfMemoryError），这类OOM的特色是崩溃时java堆内存和设备物理内存都充足，下文将带你探索并解释这类OOM抛出的缘由。java

文末有demo地址。linux

关键词:git

OutOfMemoryError, OOM,pthread_create failede,Could not allocate JNI Envgithub

1、引子

对于每个移动开发者，内存是都须要当心使用的资源，而线上出现的 OOM（OutOfMemoryError）都会让开发者抓狂，由于咱们一般仰仗的直观的堆栈信息对于定位这种问题一般帮助不大。网上有不少资料教咱们如何“紧衣缩食“的利用宝贵的堆内存（好比，使用小图片，bitmap 复用等），但是:markdown

1.线上的 OOM 真的全是因为堆内存紧张致使的吗？网络

2.有没有 App 堆内存宽裕，设备物理内存也宽裕的状况下发生 OOM 的可能？多线程

内存充裕的时候出现 OOM 崩溃？app

3.看似难以想象，然而，最近笔者在调查一个问题的时候，经过自研的 APM 平台发现公司的一个产品的大部分 OOM 确实有这样的特征，即：OOM 崩溃时，java 堆内存远远低于 Android 虚拟机设定的上限，而且物理内存充足，SD 卡空间充足socket

既然内存充足，这时候为何会有 OOM 崩溃呢？ionic

2、问题描述

在详细描述问题以前，先弄清楚一个问题：

什么致使了 OOM 的产生？

下面是几个关于 Android 官方声明内存限制阈值的 API：


一般认为 OOM 发生是因为 java 堆内存不够用了，即；


这种 OOM 能够很是方便的验证（好比: 经过 new byte[] 的方式尝试申请超过阈值maxMemory() 的堆内存），一般这种 OOM 的错误信息一般以下：


而前面已经提到了，本文中发现的 OOM 案例中堆内存充裕（Runtime.getRuntime().maxMemory() 大小的堆内存还剩余很大一部分），设备当前内存也很充裕（ActivityManager.MemoryInfo.availMem 还有不少）。这些 OOM 的错误信息大体有下面两种：

1 . 这种 OOM 在 Android6.0，Android7.0 上各个机型均有发生，文中简称为 OOM 一，错误信息以下：


2 . 集中发生在 Android7.0 及以上的华为手机（EmotionUI_5.0 及以上）的 OOM，简称为 OOM 二，对应错误信息以下：


3、问题分析及解决

3.1代码分析

Android 系统中，OutOfMemoryError 这个错误是怎么被系统抛出的？下面基于 Android6.0 的代码进行简单分析：

1. Android 虚拟机最终抛出OutOfMemoryError 的代码位于/art/runtime/thread.cc


2. 搜索代码能够发现如下几个地方调用了上述方法抛出 OutOfMemoryError 错误

3. 第一个地方是堆操做时


这种抛出的其实就是堆内存不够用的时候，即前面提到的申请堆内存大小超过了Runtime.getRuntime().maxMemory()

1 . 第二个地方是建立线程时


对比错误信息，能够知道咱们遇到的 OOM 崩溃就是这个时机，即建立线程的时候（Thread::CreateNativeThread）产生的。

2 . 还有其余的一些错误信息如“[XXXClassName] of length XXX would overflow”是系统限制String/Array 的长度所致，不在本文讨论之列。

那么，咱们关心的就是Thread::CreateNativeThread 时抛出的 OOM 错误，建立线程为何会致使 OOM 呢？

3.2推断

既然抛出来 OOM，必定是线程建立过程当中触发了某些咱们不知道的限制，既然不是 Art 虚拟机为咱们设置的堆上限，那么多是更底层的限制。Android 系统基于 linux，因此 linux 的限制对于 Android 一样适用，这些限制有：

1 ./proc/pid/limits 描述着 linux 系统对对应进程的限制，下面是一个样例：


用排除法筛选上面样例中的 limits：

  • Max stack size，Max processes 的限制是整个系统的，不是针对某个进程的，排除；
  • Max locked memory ，排除，后面会分析，线程建立过程当中分配线程私有 stack 使用的 mmap 调用没有设置 MAP_LOCKED，因此这个限制与线程建立过程无关 ；
  • Max pending signals，c 层信号个数阈值，无关，排除 ；
  • Max msgqueue size，Android IPC 机制不支持消息队列，排除。

剩下的 limits 项中，Max open files 这一项限制最可疑Max open files 表示 每一个进程最大打开文件的数目，进程 每打开一个文件就会产生一个文件描述符 fd（记录在 /proc/pid/fd 下面），这个限制代表 fd 的数目不能超过 Max open files 规定的数目。

后面分析线程建立过程当中会发现过程当中涉有及到文件描述符。

2 . /proc/sys/kernel 中描述的限制

这些限制中与线程相关的是 /proc/sys/kernel/threads-max，规定了每一个进程建立线程数目的上限，因此线程建立致使 OOM 的缘由也有可能与这个限制相关。

3.3验证

下面对上述的推断进行验证，分两步：本地验证和线上验收。

  • 本地验证：在本地验证推断，试图复现与图 [2-4]OOM 一与图 [2-5]OOM 二所示错误消息一致的 OOM
  • 线上验收：下发插件，验收线上用户 OOM 时确实是因为上面的推断的缘由致使的。

本地验证

实验一： 触发大量网络链接（每一个链接处于独立的线程中）并保持，每打开一个 socket 都会增长一个 fd（/proc/pid/fd 下多一项）

注：不仅有这一种增长 fd 数的方式，也能够用其余方法，好比打开文件，建立 handlerthread 等等

  • 实验预期：当进程 fd 数（能够经过 ls /proc/pid/fd | wc -l 得到）突破 /proc/pid/limits 中规定的 Max open files 时，产生 OOM；
  • 实验结果：当 fd 数目到达 /proc/pid/limits 中规定的 Max open files 时，继续开线程确实会致使 OOM 的产生。

错误信息及堆栈以下：


能够看出，此 OOM 发生时的错误信息确与线上发现的 OOM 一的“Could not allocate JNI Env” 吻合，所以线上上报的 OOM 一 可能 就是由 FD 数超限致使的，不过最终肯定须要到线上进行验证 (下一小节)。此外从 ART 虚拟机的 Log 中看出，还有一个关键的信息 “ art: ashmem_create_region failed for 'indirect ref table': Too many open files”，后面会用于问题定位及解释。

实验二：建立大量的空线程（不作任何事情，直接 sleep）

  • 实验预期：
  • 当线程数（能够在/proc/pid/status 中的threads项实时查看）超过/proc/sys/kernel/threads-max 中规定的上限时产生 OOM 崩溃。
  • 实验结果：
  • 在 Android7.0 及以上的华为手机（EmotionUI_5.0 及以上）的手机产生 OOM，这些手机的线程数限制都很小 (应该是华为 rom 特地修改的 limits)，每一个进程只容许最大同时开 500 个线程，所以很容易复现了。

OOM 时错误信息以下：


能够看出 错误信息与咱们线上遇到的 OOM 二吻合："pthread_create (1040KB stack) failed: Out of memory" 另外 ART 虚拟机还有一个关键 Log：“pthread_create failed: clone failed: Out of memory”，后面会用于问题定位及解释。

1 . 其余 Rom 的手机线程数的上限都比较大，不容易复现上述问题。可是，对于 32 位的系统，当进程的逻辑地址空间不够的时候也会产生 OOM，每一个线程一般须要 mapp 1MB 左右的 stack 空间（stack 大小能够自行设置），32 为系统进程逻辑地址 4GB，用户空间少于 3GB。逻辑地址空间不够（已用逻辑空间地址能够查看 /proc/pid/status 中的 VmPeak/VmSize 记录），此时建立线程产生的 OOM 具备以下信息：


线上验收及问题解决

本地尝试复现的 OOM 错误信息中图 [3-5] 与线上 OOM 一状况比较吻合，图 [3-6] 与线上 OOM 二的状况比较吻合，但线上的 OOM 一真的时 FD 数目超限，OOM 二真的是因为华为手机线程数超限的缘由致使的吗？最终肯定还须要取线上设备的数据进行验证。

验证方法：

下发插件到线上用户，当 Thread.UncaughtExceptionHandler 捕获到OutOfMemoryError 时记录 /proc/pid 目录下的以下信息：

1. /proc/pid/fd 目录下文件数 (fd 数)

2. /proc/pid/status 中 threads 项（当前线程数目）

3. OOM 的日志信息（出了堆栈信息还包含其余的一些 warning 信息

线上 OOM 一验证

发生 OOM 一的线上设备中采集到的信息：

1. /proc/pid/fd 目录下文件数与 /proc/pid/limits 中的 Max open files 数目持平，证实 FD 数目已经满了；

2. 崩溃时日志信息与图 [3-5] 基本一致；

由此，证实 线上的 OOM 一确实是因为 FD 数目过多致使的 OOM，推断验证成功。

OOM 一的定位与解决：

最终缘由是 App 中使用的长链接库再某些时候会有瞬时发出大量 http 请求的 bug(致使 FD 数激增)，已修复。

线上 OOM 二验证 集中在华为系统的 OOM 二崩溃时收集到的信息样例以下，（收集的样例中包含的 devicemodel 有 VKY-AL00，TRT-AL00A，BLN-AL20，BLN-AL10，DLI-AL10，TRT-TL10，WAS-AL00 等）：

1. /proc/pid/status 中 threads 记录所有到达上限：Threads： 500；

2. 崩溃时日志信息与图 [3-6] 基本一致；

推断验证成功，即 线程数受限致使建立线程时 clone failed 致使了线上的 OOM 二。

OOM 二的定位与解决：

关于 App 业务代码中的问题还在定位修复中。

3.4解释

下面从代码分析本文描述的 OOM 是怎么发生的，首先线程建立的简易版流程图以下所示：


上图中，线程建立大概有两个关键的步骤：

  • 第一列中的 建立线程私有的结构体 JNIENV(JNI 执行环境，用于 C 层调用 Java 层代码)
  • 第二列中的 调用 posix C 库的函数 pthread_create 进行线程建立工做

下面对流程图中关键节点（图中有标号的）进行说明：

1. 图中节点①，/art/runtime/thread.cc 中的函数Thread:CreateNativeThread部分节选代码以下：


可知：

  • JNIENV 建立不成功时产生 OOM 的错误信息为 "Could not allocate JNI Env"，与文中 OOM 一一致

pthread_create失败时抛出 OOM 的错误信息为"pthread_create (%s stack) failed: %s"．其中详细的错误信息由 pthread_create 的返回值（错误码）给出。错误码与错误描述的对应关系能够参见 bionic/libc/include/sys/_errdefs.h中的定义。文中 OOM 二的具体错误信息为"Out of memory"，就说明 pthread_create 的返回值为 12。


2. 图中节点②和③是建立 JNIENV 过程的关键节点，节点②/art/runtime/mem_map.cc 中 函数 MemMap:MapAnonymous 的做用是为 JNIENV 结构体中Indirect_Reference_table（C 层用于存储 JNI 局部 / 全局变量）申请内存，申请内存的方法是节点③所示的函数ashmem_create_region（建立一块 ashmen 匿名共享内存, 并返回一个文件描述符）。节点②代码节选以下：


咱们线上的OOM 一的错误信息＂ashmem_create_region failed for 'indirect ref table': Too many open files＂，与此处打印的信息吻合。＂Too many open files＂的错误描述说明此处的 errno（系统全局错误标识）为 24(见图 [3-10] 系统错误定义 _errdefs.h)。由此看出咱们线上的 OOM 一是因为文件描述符数目已满，ashmem_create_region 没法返回新的 FD 而致使的。

3. 图中节点④和⑤是调用 C 库建立线程时的环节，建立线程首先 调用 __allocate_thread 函数申请线程私有的栈内存 (stack) 等，而后 调用 clone 方法进行线程建立．申请 stack 采用的时 mmap 的方式，节点⑤代码节选以下：


打印的错误信息与图 [3-7] 中进程逻辑地址占满致使的 OOM 错误信息吻合，图 [3-7] 中错误信息＂ Try again＂说明系统全局错误标识 errno 为 11(见图 [3-10] 系统错误定义_errdefs.h). pthread_create 过程当中，节点４相关代码以下：


此处输出的错误日志"pthread_create failed: clone failed: %s"与咱们线上发现的 OOM 二吻合，图 [3-6] 中的错误描述＂ Out of memory＂说明系统全局错误标识 errno 为 12(见图 [3-10] 系统错误定义 _errdefs.h)。 由此线上的 OOM 二就是因为线程数的限制而在节点 5 clone 失败致使 OOM。

4、结论及监控

4.1致使OOM发生的缘由

综上，能够致使 OOM 的缘由有如下几种：

1. 文件描述符 (fd) 数目超限，即 proc/pid/fd 下文件数目突破 /proc/pid/limits 中的限制。可能的发生场景有：短期内大量请求致使 socket 的 fd 数激增，大量（重复）打开文件等 ；

2. 线程数超限，即proc/pid/status中记录的线程数（threads 项）突破 /proc/sys/kernel/threads-max 中规定的最大线程数。可能的发生场景有：app 内多线程使用不合理，如多个不共享线程池的 OKhttpclient 等等 ；

3. 传统的 java 堆内存超限，即申请堆内存大小超过了Runtime.getRuntime().maxMemory()；

4. （低几率）32 为系统进程逻辑空间被占满致使 OOM；

5. 其余。

4.2监控措施

能够利用 linux 的 inotify 机制进行监控：

  • watch /proc/pid/fd来监控 app 打开文件的状况，
  • watch /proc/pid/task来监控线程使用状况。

5、Demo


六，难以想象的OOM，Android高级脑图，全套视频

1.难以想象的OOM；



2.Android高级脑图；


3.Android高级视频；



全套高级视频尚在整理完善，免费分享，欢迎关注谢谢
联系我们 沪ICP备13005482号-10