面试：Hprof文件的裁剪

剖析hprof文件的两种主要裁剪流派 - Yorek's Blog

性能优化之matrix学习-Resource Canary - 掘金

10.优化 - 内存优化之hprof文件处理 - 简书

Koom 解决hprof文件过大-源码解析_stone_cold_cool的博客-CSDN博客_hprof文件过大

一、为啥要裁剪

Hprof文件通常比较大，分析OOM时遇到500M以上的hprof文件并不稀奇，文件的大小，与dump成功率、dump速度、上传成功率负相关，且大文件额外浪费用户大量的磁盘空间和流量。我们因此想到了对hprof进行裁剪，只保留分析OOM必须的数据，另外，裁剪还有数据脱敏的好处，只上传内存中类与对象的组织结构，并不上传真实的业务数据（诸如字符串、byte数组等含有具体数据的内容），保护用户隐私。

所以HPROF文件在上传到服务器时，一般需要经过裁剪、压缩等工作。比如一个 100MB 的文件裁剪后一般只剩下 30MB 左右，使用 7zip 压缩最后小于 10MB，增加了文件上传的成功率。

下面是原始的HPROF经过各种裁剪方案，最后压缩后的文件大小。

可以看到，HPROF文件的裁剪、压缩过程在上报之前还是非常有必要的。

2、hprof存的内容都是些什么？数据如何组织的？哪些可以裁掉？

总体分为两部分，Header和Record，Header记录hprof的元信息，Record分很多条目，每一条有一个单独的TAG代表类型。
我们关注的Record类型主要是HEAP DUMP，其中又分五个子类，分别为GC ROOT、CLASS DUMP、INSTANCE DUMP、OBJECT ARRAY DUMP、PRIMITIVE ARRAY DUMP。

内存中绝大部分数据是PRIMITIVE ARRAY DUMP，通常占据80%以上，而我们分析OOM只关系对象的大小和引用关系，并不关心内容，因此这部分是我们裁剪的突破口。

3、裁剪方式有哪些

裁剪分为两大流派：

1. dump之后，对文件进行读取并裁剪的流派：比如Shark、微信的Matrix等
2. dump时直接对数据进行实时裁剪，需要hook数据的写入过程：比如美团的Probe、快手的KOOM等

总结

• Matrix方案裁剪的是HEAP_DUMP、HEAP_DUMP_SEGMENT里面的PRIMITIVE_ARRAY_DUMP段。该方案仅仅会保存字符串的数据以及重复的那一份Bitmap的buffer数据，其他基本类型数组会被剔除。
• 裁剪时KOOM会根据堆类型进行裁剪：
  • 针对system space（Zygote Space、Image Space）：会裁剪PRIMITIVE_ARRAY_DUMP、HEAP_DUMP_INFO、INSTANCE_DUMP和OBJECT_ARRAY_DUMP这4个子TAG，会删除这四个子TAG的全部内容（包函子TAG全都会删除）。
  • 针对app space：会处理PRIMITIVE_ARRAY_DUMP这一块数据，但会保留metadata，方便回填。