2.1.2 垃圾回收器是如何工作回收内存的

2.1.3 对象占据多大的内存空间

2.1.4 Java OOM的发生

//方法

void Heap::ThrowOutOfMemoryError(Thread* self, size_t byte_count, AllocatorType allocator_type) 

//异常信息

  oss << "Failed to allocate a " << byte_count << " byte allocation with " << total_bytes_free

      << " free bytes and " << PrettySize(GetFreeMemoryUntilOOME()) << " until OOM,"

      << " target footprint " << target_footprint_.load(std::memory_order_relaxed)

      << ", growth limit "

      << growth_limit_;

• Runtime.getRuntime().maxMemory() ： 当前虚拟机实例的内存使用上限
• Runtime.getRuntime().totalMemory() ： 当前已经申请的内存，包括已经使用的和还没有使用的
• Runtime.getRuntime().freeMemory() ： totalMemory中已经申请但是尚未使用的部分
• used=totalMemory() - freeMemory()： 已经申请并且正在使用的部分
• totalFree=maxMemory()-used： Java虚拟机还可以使用的部分

• 都是线下工具，线下复现Java OOM问题困难
• 自动化程度低，只能手动操作分析内存问题
• 都是单点工具，只能分析单个hprof文件，没法聚合找到核心问题

• 高度还原场景：可以拿到Java OOM时候的场景内存数据
• 自动化分析：可以自动化进行内存数据分析
• 聚合找到核心问题：可以根据问题特征聚合发现核心问题
• 隐私安全：因为是线上监控，所以需要满足用户隐私安全的要求

1. 端SDK：负责Hprof文件的采集、裁剪、压缩及上报等
2. 服务端：Hprof文件存储、还原、自动分析、结果Retrace、issue聚合，自动分配等
3. 前端：问题展示包括内存泄露、大对象、类大对象等

• OOM之后还要再进行 dump 操作确实会容易dump失败。
• OOM时候App崩溃不可用，dump操作会在崩溃时候导致卡顿。

• 规避隐私风险：Hprof保存了执行Dump时刻Java堆上所有的内存信息，包括存在内存中的账户信息等，这些敏感信息必须裁剪掉。
• 减小文件大小：因为堆内存不足而OOM的时候获到的Hprof文件，约等于设备单进程最大可用内存，一般文件比较大有几百M，大文件上传浪费用户流量、带宽以及导致上报成功率降低。

1. 根据Hprof文件的格式进行分析，分析我们不需要关注的数据块
2. 将文件映射进内存，根据文件格式找到想要裁剪的数据块
3. 再次写入文件的时候不要写第2步找到的数据块
4. 这样产生的Hprof文件就是裁剪后的

 

裁剪效果：

隐私安全:裁剪后的字符串和图片像素等数据已经为空

Hprof文件大小变化明显: 头条裁剪前后数据平均值对比 355M-> 44M

3.2.3 内存文件的自动化解析

当服务端接收到上报的内存快照之后会进行自动的分析，直接定位内存核心问题，分析之后的结果主要包含三部分：

• 内存泄露
• 大对象
• 小对象

分析 Hprof 文件需要首先将 Hprof 文件按照格式进行解析， 并根据解析后数据构建引用关系图 。

我们参考业界已经存在的Hprof解析实现，包括MAT，LeakCanary等，实现了 一套Hprof内存快照自动解析库。

下面讲解这三部分内容是如何定义的，如何解析的，解析了哪些数据用来归因，平台效果如何。

3.2.3.1 内存泄露

内存泄露是在计算机中，由于疏忽或错误造成程序未能释放已经不再使用的内存，是需要修复的问题。

例如Activity生命周期已经结束，执行了onDestroy()，但是依然存在到GC Root的引用链，导致Activity无法被GC回收。这个Activity 就可以认定为内存泄露。

根据 Retained Size大小我们可以判断Activity的 泄露问题严重程度，越大越应该被优先解决。

根据 GC引用链我们可以判断这个 Activity泄露的原因，被谁持有导致的泄露，确认如何解决。

如何判定泄露：

通过分析 Activity 的源码发现Activity调用 onDestroy 之后一个变量的值会发生变化，通过这个变量我们可以判断 Activity 是不是走了 onDestroy，如果走了那说明这个 Activity 对象存在属于泄露，没有走则说明属于正常使用。

private boolean mDestroyed;

final void performDestroy() {

    mDestroyed = true;

    xxx

}

通过Hprof解析库找出Activity的实例，并对其mDestroyed属性进行判断是否为true。这样就找到了泄露的Activity。

引用链和Retained大小：

找到了泄露对象之后我们需要知道它究竟是被谁引用导致不能释放，上文已经介绍 Java 的垃圾回收机制通过可达性分析算法判断对象是否存活，一个对象能不能被回收就看 GC Root 到它之间有没有强引用链。泄露的对象和 GCRoot 之间必然是存在强引用链。

根据Hprof中的实例信息解析成描述引用关系的图结构后，使用经典的图搜索算法即可找到泄漏的对象到 GCRoot 的强引用链了，同时计算出对象的Retained Size大小。

泄露展示效果：

泄露类和导致它泄露的 引用链非常直观展现了出来，可以通过 断掉引用链来解决泄露。

所有发现的泄漏问题都应该被解决修复，上面的case是因为静态变量持有了Activity导致，这里的mContext可以通过替换为Application来解决。

 

3.2.3.2 大对象

大对象：顾名思义就是比较大的对象，前面背景知识里说的 RetainSize 较大的对象，也就是释放掉之后总共可以回收的较大的对象。

大对象标准：目前判断的依据是 RetainSize 大于 1 M的对象会被当做大对象，然后去找引用链。

if (object != null && object.getRetainedHeapSize() > MINIMAL){

    // 算作大对象

 }

同时我们会计算大对象持有了谁导致他比较大，也是通过大对象持有的变量来计算判断。

大对象展示效果：

根据引用链判断这个大对象被谁持有引用，是否属于泄露可以修复。如果属于正常使用，判断大对象持有对象有谁，是否缓存过大可以清除部分缓存。下图可以看到内存缓存过大，Retained Size达到210M可以清除部分缓存优化。

大对象往往是导致Java OOM的核心问题，关注高频出现的Retained Size超大的大对象，优化后对Java OOM有非常好的优化效果。

 

3.2.3.3 类大对象

一个对象虽然比较小，但是它特别多，对象加在一起比较大也是需要我们重点关注的。例如一个对象只占10kb，但是如果内存里有2000个对象实例，总的内存占用也是特别大的。

当前类大对象的默认定义：对象实例数量超过10，Retained Size超过20M的类。

我们会解析出这部分类大对象，然后计算出他们的引用链。

类大对象展示效果：

上面的case是说类ArticleCell的对象有364个，总Retained Size 是51.29M。其中280个被MainActivity所持有。所以如果要优化ArticleCell的内存占用，可以优化MainActivity里面的引用。

3.2.4 聚合和Retrace

3.2.4.1 聚合

通过聚合我们可以找到同类问题，并把高频问题体现出来优先解决，达到四两拨千斤的效果。

泄露是通过泄露类和引用它的业务代码作为聚合特征来进行聚合。

大对象是通过大对象类和引用它的业务代码作为聚合特征来进行聚合。

类大对象是根据类名来进行聚合。

泄露的聚合效果如下，可以根据排序直接定位到高频泄露的Acitvity。

 

3.2.4.2 Retrace

类名和引用链Retrace:

Hprof文件是混淆后的数据，对于解析出来的类名和引用链可以和崩溃一样通过符号表进行自动解析还原。

Hprof文件Retrace:

为了更好的分析单点问题，平台也提供了单点自动化分析数据展示和单点原始Hprof文件下载的能力。

 

对于下载下来的Hprof原始文件也是混淆后的，客户端分析非常不友好，是否可以把Hprof文件也进行反混淆还原呢。

当然可以，当前开发了一个Hprof文件Retrace工具，可以解析Hprof文件，读取类、变量和方法等数据，根据符号表还原成Retrace后的Hprof文件，线下分析更方便。

通过平台下载下来的Hprof就是经过填充还原Hprof结构，并且自动Retrace后的Hprof文件。

解析前：

解析后：

3.2.5 自动分配

对于分析出来的问题，只分析出来还不足够，并没有实现闭环，我们需要通知到相应的同学去解决才可以，否则需要有同学来手动分配线上问题，比较浪费精力。

因此需要有自动分配的能力，内部通过解析聚合后issue的泄露Class，去代码仓库或者根据配置找这个 Class 的Owner，发送 Lark 通知给这位同学。

当前在火山引擎的MARS-APMPlus 应用性能监控无法获取用户的仓库解析Class Owner，暂时无法自动分配。

3.2.6 总结

以上就是这套 基于Hprof内存快照的线上 Java OOM 归因方案的原理介绍，这套方案实现了 高度场景还原、 自动化内存分析、 自动聚合Retrace、并实现了 隐私安全。

接入后优先分析解决聚合后的TOP问题，包括频繁的泄露和频繁出现的大对象，对Java OOM指标会有非常明显的优化效果。

 

四、优化效果

4.1 内部效果

当前该解决方案已在字节内部广泛应用。包括头条抖音在内的数十个App业务方在接入后，Java OOM均有明显优化。以Helo为例，一个双月内 优化了80+%的Java OOM问题，次日存留增长了2+%，效果显著。

4.2 外部效果

当前这套方案已经在 火山引擎 MARS-APM Plus应用性能监控上线，美篇作为早期客户，在一个双月的优化后 Java OOM 降低了80%， 用户卡顿率也下降了80%，优化效果非常明显。

五、接入使用

MARS-APM Plus应用性能监控企业助力行动： MARS-APM Plus 当前开始了企业助力行动，可以免费试用，欢迎注册试用产品，发现并解决Java OOM问题。MARS-APM Plus除了支持对App进行监控，也支持对SDK进行稳定性监控和自定义事件打点。

进群：扫码进群，会有同学对接如何开通 MARS-APM Plus应用性能监控服务。

MARS-APM Plus 应用性能监控为企业提供 针对应用的品质、性能以及自定义 埋点 的 APM  应用性能监控服务，帮助团队打造极致的用户体验。基于海量数据的聚合分析，平台可帮助客户发现多类异常问题，并及时报警，做分配处理，同时平台提供了丰富的归因能力，包括且不限于异常分析、多维分析、自定义上报、单点日志查询等，结合灵活的报表能力可了解各类指标的趋势变化。APM Plus 已服务了抖音、今日头条、TikTok 等多个超大规模用户量级移动 App。

 

 

当前讲解的Java OOM解决方案，只是MARS-APM Plus 应用性能监控的一个功能模块，还有更多的能力会在后续进一步讲解，也欢迎同学抢先接入试用。

 

---

🔥  火山引擎 APMPlus 应用性能监控是火山引擎应用开发套件 MARS 下的性能监控产品。我们通过先进的数据采集与监控技术，为企业提供全链路的应用性能监控服务，助力企业提升异常问题排查与解决的效率。目前产品正在免费公测阶段，👉  戳这里了解更多产品信息。欢迎大家进行试用！