OOM率指标介绍
1、背景
在Android开发中，OOM（Out of Memory）问题通常指的是Java堆内存不足导致的java.lang.OutOfMemoryError异常。然而，OOM问题不仅限于Java堆内存，还可能涉及到文件描述符（FD）资源使用超标或本地内存地址空间使用超标，例如下面这个很常见的java.lang.OutOfMemoryError异常：
java.lang.OutOfMemoryError: Could not allocate JNI Env
java.lang.Thread.nativeCreate(Native Method)
java.lang.Thread.start(Thread.java:1063)
kotlinx.coroutines.scheduling.CoroutineScheduler.int createNewWorker()(CoroutineScheduler.java:485)
kotlinx.coroutines.scheduling.CoroutineScheduler.boolean tryCreateWorker(long)(CoroutineScheduler.java:440)
kotlinx.coroutines.scheduling.CoroutineScheduler.boolean tryCreateWorker$default(kotlinx.coroutines.scheduling.CoroutineScheduler,long,int,java.lang.Object)(CoroutineScheduler.java:431)
kotlinx.coroutines.scheduling.CoroutineScheduler.void signalCpuWork()(CoroutineScheduler.java:427)
kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.void beforeTask(int)(CoroutineScheduler.java:758)
kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.void executeTask(kotlinx.coroutines.scheduling.Task)(CoroutineScheduler.java:749)
kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.void runWorker()(CoroutineScheduler.java:678)
kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.void run()(CoroutineScheduler.java:665)
表面上看是一个虚拟机内存相关的问题，但从源码角度来看，其实是因为创建线程的时候因为没有可用的FD资源，创建线程失败 ，所以上报为java.lang.OutOfMemoryError异常，从系统日来看也能验证这一点，在出错之前，有很多“Too many open files” 的系统日志：
03-18 13:44:17.426 28516 809 W System.err: java.net.ConnectException: failed to connect to up-hl.3g.qq.com/61.241.53.46 (port 443) after 10000ms: connect failed: EMFILE (Too many open files)
03-18 13:44:17.427 28516 809 W System.err: Caused by: android.system.ErrnoException: connect failed: EMFILE (Too many open files)
03-18 13:44:17.519 28516 765 W System.err: java.io.FileNotFoundException: /data/user/0/******.temp: open failed: EMFILE (Too many open files)
03-18 13:44:17.519 28516 765 W System.err: Caused by: android.system.ErrnoException: open failed: EMFILE (Too many open files)
03-18 13:44:18.239 28516 802 E art : ashmem_create_region failed for 'indirect ref table': Too many open files
03-18 13:44:18.243 28516 801 W System.err: java.net.SocketException: socket failed: EMFILE (Too many open files)
03-18 13:44:18.243 28516 801 W System.err: Caused by: android.system.ErrnoException: socket failed: EMFILE (Too many open files)
除了FD资源外，Native内存不足也会导致创建线程失败，像这种资源使用超标导致的Crash问题堆栈是多种多样的，Crash堆栈很可能只是压倒骆驼的最后一根稻草，所以基于Crash堆栈和异常类型的常规聚类方式往往起不到一个好的聚类效果，针对这一类问题有必要将这些问题按照资源使用的角度来分开，然后针对性的优化和解决。为了更全面地了解和解决一个业务OOM相关的问题，我们将OOM重新分为 Java OOM、FD OOM和Native OOM，并且扩充了原本的OOM率指标含义。
2、调整后的OOM问题分类
Java OOM
Java OOM是最常见的OOM问题，通常由于Java堆内存不足导致。当应用程序请求的内存超过Java堆的可用空间时，会抛出java.lang.OutOfMemoryError异常。这可能是由于Java内存泄漏、大对象分配、大图等原因引起的。
java.lang.OutOfMemoryError
Failed to allocate a 176 byte allocation with 5025912 free bytes and 4908KB until OOM, target footprint 536870912, growth limit 536870912; giving up on allocation because <1% of heap free after GC.
java.lang.OutOfMemoryError: Failed to allocate a 176 byte allocation with 5025912 free bytes and 4908KB until OOM, target footprint 536870912, growth limit 536870912; giving up on allocation because <1% of heap free after GC.
java.util.Arrays.copyOf(Arrays.java:3766)
java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:125)
java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:449)
java.lang.StringBuilder.append(StringBuilder.java:137)
......
FD OOM
FD OOM是指文件描述符资源使用超标导致的OOM问题。每个进程在运行时都有一定数量的文件描述符可用，用于打开、读取和写入文件等
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Crash type: 'native'
Start time: '2024-03-18T12:32:49.406+0800'
Crash time: '2024-03-18T16:09:33.763+0800'
App version: 'x.x.x.x'
Rooted: 'No'
API level: '27'
Build fingerprint: 'OPPO/R11/R11:8.1.0/OPM1.171019.011/1575877917:user/release-keys'
ABI: 'arm64'
pid: 9096, tid: 18434, name: HalleyTempTaskT >>> com.tencent.xxxxx <<<
signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
Abort message: 'Could not make wake event fd: Too many open files'
x0 0000000000000000 x1 0000000000004802 x2 0000000000000006 x3 0000000000000008
x4 0000007dce36f588 x5 0000007dce36f588 x6 0000007dce36f588 x7 0000007dce36f588
x8 0000000000000083 x9 0000000010000000 x10 0000007dce36e9b0 x11 cd4becaebf0bf9bc
x12 cd4becaebf0bf9bc x13 0000000000000020 x14 ffffffffffffffdf x15 cd4becaebf0bf9bc
x16 0000000a2bfd9fa8 x17 0000007ed34b7540 x18 0000000000000001 x19 0000000000002388
x20 0000000000004802 x21 0000000000000083 x22 000000007018bbc0 x23 0000000000004802
x24 0000000000000001 x25 00000000701d41f0 x26 0000000015f00088 x27 0000000015f000b0
x28 0000000015f00100 x29 0000007dce36e9f0
sp 0000007dce36e9b0 lr 0000007ed3460770 pc 0000007ed3460798
backtrace:
#00 pc 000000000001e798 /system/lib64/libc.so (abort+120)
#01 pc 0000000000008348 /system/lib64/liblog.so (__android_log_assert+296)
#02 pc 000000000001542c /system/lib64/libutils.so (_ZN7android6LooperC1Eb+308)
#03 pc 000000000011b5e0 /system/lib64/libandroid_runtime.so (_ZN7android18NativeMessageQueueC1Ev+160)
#04 pc 000000000011bebc /system/lib64/libandroid_runtime.so (_ZN7androidL34android_os_MessageQueue_nativeInitEP7_JNIEnvP7_jclass+28)
#05 pc 000000000065b420 /system/framework/arm64/boot-framework.oat (android.os.Binder.clearCallingIdentity [DEDUPED]+144)
#06 pc 0000000000c8731c /system/framework/arm64/boot-framework.oat (android.os.HandlerThread.run+332)
#07 pc 000000000054ad88 /system/lib64/libart.so (art_quick_invoke_stub+584)
#08 pc 00000000000dcf74 /system/lib64/libart.so (_ZN3art9ArtMethod6InvokeEPNS_6ThreadEPjjPNS_6JValueEPKc+200)
#09 pc 000000000046d6a0 /system/lib64/libart.so (_ZN3artL18InvokeWithArgArrayERKNS_33ScopedObjectAccessAlreadyRunnableEPNS_9ArtMethodEPNS_8ArgArrayEPNS_6JValueEPKc+100)
#10 pc 000000000046e8cc /system/lib64/libart.so (_ZN3art35InvokeVirtualOrInterfaceWithJValuesERKNS_33ScopedObjectAccessAlreadyRunnableEP8_jobjectP10_jmethodIDP6jvalue+836)
#11 pc 0000000000496e4c /system/lib64/libart.so (_ZN3art6Thread14CreateCallbackEPv+1120)
#12 pc 0000000000074d74 /system/lib64/libc.so (_ZL15__pthread_startPv+36)
#13 pc 000000000001fce4 /system/lib64/libc.so (__start_thread+68)
Native OOM
Native OOM是指本地内存地址空间使用超标导致的OOM问题。在Android开发中，应用程序可以使用本地代码（如C/C++）来执行一些高性能的任务。如果本地代码中存在内存泄漏或者大量的本地内存分配，就会导致本地内存地址空间耗尽，从而引发Native内存分配相关的OOM问题，常见的像mmap失败或者显存爆了的问题。
03-18 14:39:31.424 9236 30371 W .tencent.xxx: Large object allocation failed: Failed anonymous mmap(0x0, 2101248, 0x3, 0x22, -1, 0): Out of memory. See process maps in the log.
03-18 14:39:31.437 9236 30371 W .tencent.xxx: Throwing OutOfMemoryError "Failed to allocate a 2097172 byte allocation with 24542160 free bytes and 283MB until OOM, target footprint 264041288, growth limit 536870912" (VmSize 4039036 kB)
03-18 14:39:32.128 9236 4592 D CCodecBufferChannel: [c2.mtk.hevc.decoder#869] DEBUG: elapsed: mInputMetEos 20, hasPendingOutputsInClient 0, n=1 [in=4 pipeline=0 out=16]
03-18 14:39:32.492 9236 30526 E CursorWindow: Failed mmap: Out of memory
03-18 15:42:31.466 18578 18864 W Adreno-GSL: <sharedmem_gpuobj_alloc:2713>: sharedmem_gpumem_alloc: mmap failed errno 12 Out of memory
03-18 15:42:32.351 18578 18864 W Adreno-GSL: <sharedmem_gpuobj_alloc:2713>: sharedmem_gpumem_alloc: mmap failed errno 12 Out of memory
03-18 15:42:33.279 18578 18864 W Adreno-GSL: <sharedmem_gpuobj_alloc:2713>: sharedmem_gpumem_alloc: mmap failed errno 12 Out of memory
03-18 15:42:33.321 18578 18864 E OpenGLRenderer: GL error: Out of memory!
3、调整后的OOM率指标
之前的oom率指标只考虑了java.lang.OutOfMemroyError这一种异常的概率，而在新的oom率指标体系中，java.lang.OutOfMemoryError只是其中的一种，我们可以称作为java oom率，除了java oom率之外，这次我们增加了fd oom率、native oom率，分别对应的是因fd资源导致的崩溃问题概率和因进程native内存导致的崩溃问题概率，新的oom率体系只需要升级到Bugly 4.3.2 之后的版本就可以正常体验，不需要业务端做任何修改， 其入口还是在oom这个tab里面：
重新定义OOM率和将OOM问题细分为不同类型的好处在于更准确地定位和解决OOM问题。通过监控和分析不同类型的OOM率，我们可以更好地了解应用程序在不同方面的资源使用情况，从而采取相应的优化措施。
Java OOM率：通过Java OOM率。可以促使我们积极去发现内存泄漏问题、优化垃圾回收策略、调整堆内存大小等，以减少Java OOM问题的发生。
FD OOM率：通过FD OOM率。可以帮助我们发现文件描述符的泄漏或滥用情况，及时关闭不再使用的文件描述符，以避免FD OOM问题的发生。
Native OOM率：通过Native OOM率。这可以帮助我们发现本地代码中的内存泄漏或者过度分配问题，及时释放不再使用的本地内存，以避免Native OOM问题的发生。
通过细分和监控不同类型的OOM率，我们可以更精确地定位和解决OOM问题，提高应用程序的稳定性和性能，另外针对几种不同的oom问题，Bugly也已经分别提供了相应的监控功能，欢迎使用。