这是「Android 内存泄漏自动检测」系列的第 3 篇，也是最后一篇。 前两篇解决了"怎么采"和"怎么判"，本篇讲最后一步——检测到泄漏后，怎么抓对应的诊断文件。
抓 hprof 不是万能的
很多团队检测到内存泄漏后，不管三七二十一就抓一个 hprof。这么做有两个问题：
问题一：hprof 只能看 Java 堆。
hprof 记录的是 Java/Kotlin 对象的引用关系。如果泄漏发生在 Native 层（C/C++ 的 malloc 没 free）、GPU 层（纹理缓冲区没释放）、或者线程层（线程创建后不销毁），hprof 里什么都看不到。你花了 90 秒 dump 出一个几百 MB 的文件，打开一看——Java 堆很正常，白忙一场。
问题二：hprof dump 本身很重。
抓 hprof 需要触发 GC → 暂停进程 → 遍历整个 Java 堆写文件，耗时 60~90 秒，对被测应用干扰很大。如果不分类就每次都 dump，一个 1 小时的压测可能产出十几个无效 hprof 文件。
所以关键不是"抓不抓"，而是"抓什么"。 响应层的核心设计就是：先分类、再对症下药。
泄漏分类：8 个维度独立回归
dumpsys meminfo 的 App Summary 会列出进程内存的 8 个维度。在中篇讲的 CONFIRMING 阶段，检测层会对每个维度独立做线性回归 + t 统计，找出"谁在涨"：
| 维度 | 含义 | 典型泄漏场景 |
|---|---|---|
| Java Heap | Java/Kotlin 对象 | Activity/Fragment 未释放、静态引用持有大对象 |
| Native Heap | C/C++ malloc 分配 | JNI 代码中 malloc 未 free、三方 so 库泄漏 |
| Code | 加载的 dex/oat/so 代码段 | 动态加载过多插件 |
| Stack | 线程栈空间（每线程约 1MB） | 线程创建后不销毁 |
| Graphics | GPU 纹理/帧缓冲区 | Bitmap 绑定到 GPU 未释放 |
| Private Other | 匿名共享内存等 | Ashmem 泄漏、大量未关闭的 Cursor |
| System | 系统级分配 | 通常不可控，一般不泄漏 |
| TOTAL | 以上所有之和 | 用于和 smaps PSS 做 GPU 辅助对比 |
分类规则很简单：哪个维度的 t 值最大且 > 2.0，就判定为哪种泄漏。
flowchart LR
DIM["8 维度各自<br>线性回归"] --> CMP["比较 t 值"]
CMP --> |"Java Heap t 最大且 > 2.0"| J[java_leak]
CMP --> |"Native Heap t 最大且 > 2.0"| N[native_leak]
CMP --> |"Stack t 最大且 > 2.0"| T[thread_leak]
CMP --> |"Graphics t 最大且 > 2.0"| G[gpu_leak]
CMP --> |"无维度显著 / 多维度同时"| U[unknown]
5 种泄漏，5 种抓法
分类确定后，进入响应层。不同类型走完全不同的诊断路径：
flowchart TD
LEAK["泄漏确认 + 分类完成"] --> COOL{"冷却检查<br>距上次 dump ≥ 30min?"}
COOL -->|"否"| LOG["仅上报事件<br>类型 + 速率 + 当前 PSS"]
COOL -->|"是"| LOCK{"全局锁<br>其他进程在 dump?"}
LOCK -->|"是"| WAIT["下轮重试"]
LOCK -->|"否"| TYPE{"泄漏类型?"}
TYPE --> JAVA["java_leak<br>60-90s"]
TYPE --> NATIVE["native_leak<br>3-5s"]
TYPE --> GPU["gpu_leak<br>10-20s"]
TYPE --> THREAD["thread_leak<br>1-2s"]
TYPE --> UNK["unknown<br>70-100s"]
1. java_leak — Java 堆泄漏
这是唯一需要 hprof 的类型。
| 步骤 | 命令 | 说明 |
|---|---|---|
| 1 | kill -10 {pid} | 触发 GC，清除可回收对象 |
| 2 | sleep 30 | 等待 GC 充分执行 |
| 3 | am dumpheap {进程名} {路径} | 生成 hprof 堆快照 |
| 4 | adb pull | 拉取到主机 |
产出：hprof 文件。记录所有 Java 对象的引用关系，可定位 GC Root → 泄漏对象的完整引用链。耗时 60-90 秒。
2. native_leak — Native 内存泄漏
| 步骤 | 命令 | 说明 |
|---|---|---|
| 1 | showmap -v {pid} | 进程内存映射详情 |
| 2 | cat /proc/{pid}/smaps | 完整 VMA 列表 |
| 3 | cat /proc/{pid}/maps | 内存映射简表 |
产出：showmap + smaps + maps 三个文件。showmap 列出每个 .so 和匿名映射的内存占用，可定位哪个库的堆区在增长。不抓 hprof——Native malloc 不在 Java 堆里。耗时仅 3-5 秒。
3. gpu_leak — GPU 显存泄漏
| 步骤 | 命令 | 说明 |
|---|---|---|
| 1 | dumpsys meminfo {进程名} | 完整 meminfo（含 Graphics 明细） |
| 2 | dumpsys gfxinfo {进程名} | 图形渲染信息、纹理缓存 |
| 3 | dumpsys SurfaceFlinger | Surface/图层状态 |
产出：meminfo + gfxinfo + SurfaceFlinger 信息。GPU 显存由驱动管理，gfxinfo 可查看纹理缓存占用。耗时 10-20 秒。
4. thread_leak — 线程泄漏
| 步骤 | 命令 | 说明 |
|---|---|---|
| 1 | cat /proc/{pid}/status | 线程数（Threads 字段） |
| 2 | ls /proc/{pid}/task/ | 线程 ID 列表 |
| 3 | dumpsys meminfo {进程名} | 完整 meminfo 快照 |
产出：线程数 + 线程列表 + meminfo。Stack 每涨约 1MB ≈ 多了 1 个线程，task 列表可查看哪些线程没有被销毁。耗时仅 1-2 秒。
5. unknown — 不确定类型
触发条件：所有维度的 t < 2.0（无法确定哪个在涨），或多个维度同时显著（无法确定主因），或由突增检测直通（没经过分类）。
兜底策略：同时抓 Java + Native 两套文件（hprof + showmap + smaps + maps），覆盖最常见的两种类型。耗时较长（70-100 秒），但 unknown 出现频率低。
响应耗时对比
| 泄漏类型 | 耗时 | 说明 |
|---|---|---|
| java_leak | 60-90s | 需要 GC + dumpheap |
| native_leak | 3-5s | 仅文件读取命令 |
| thread_leak | 1-2s | 仅文件读取命令 |
| gpu_leak | 10-20s | dumpsys 级命令 |
| unknown | 70-100s | Java + Native 全量 |
非 Java 泄漏只需几秒，不会对被测应用造成 GC + dumpheap 的额外干扰。这就是分类诊断的价值——大部分情况下，响应开销从 90 秒降到了个位数。
冷却与并发控制
诊断文件不是越多越好。需要两个保护机制防止过度采集：
进程级冷却：同一进程 30 分钟内不重复 dump
如果一个进程持续泄漏，检测层会不断报告"泄漏"。但实际上第一份诊断文件通常就包含了足够的定位信息——泄漏对象在那里，引用链在那里。
冷却期内如果再次检测到泄漏，只上报事件（类型 + 速率 + 当前 PSS），不执行 dump 操作，零开销。
全局锁：同一时刻最多 1 个进程在 dump
多进程场景下（主进程 + 小程序进程 + 推送进程），可能多个进程同时被判定泄漏。如果同时 dump，system_server 需要同时处理多个 am dumpheap 请求，可能导致 ANR。
全局锁确保同一时刻只有一个进程在做诊断操作。其他进程等锁释放后下轮重试。
| 机制 | 说明 |
|---|---|
| 进程级冷却 | 同一进程两次 dump 间隔 ≥ 30 分钟 |
| 全局锁 | 同一时刻最多 1 个进程在诊断 |
| 状态重置 | 诊断完成后回到 NORMAL，冷却结束后需重新积累证据才能再次触发 |
健壮性：别让检测工具自己出问题
一个自动化工具如果自己不稳定，比没有工具更糟糕。这里列出几个关键的防护设计：
误报防护
| 场景 | 可能的问题 | 怎么防 |
|---|---|---|
| 启动阶段 | 加载资源时内存正常增长，被误判为泄漏 | 线性回归至少需要 10 个数据点（约 5 分钟），启动期数据不足不做判定；P25 在稳定后不再递增，即使误入 SUSPICIOUS 也会超时回退 |
| 业务高峰 | 用户高频操作导致内存飙高 | P25 只看底线水位，业务峰值只拉高 P75/P90 不影响 P25 |
| 阶梯跳变 | 打开地图插件一次性 +80MB 后稳定 | R² < 0.6（台阶不是斜坡），P25 跳变后稳定不递增 |
| 周期性业务 | 定时任务每 5 分钟抖一次 | 连续 2 窗口要求过滤偶发波动，P25 忽略周期峰值 |
一句话总结防误报的逻辑：正常业务波动是"高点涨、低点不涨"，泄漏是"高点低点一起涨"。P25 精准地区分了这两种模式。
运行时异常防护
| 场景 | 怎么防 |
|---|---|
| 进程重启 PID 变化 | 每次采集前验证 PID 有效性，失效则按进程名重新查询，清空数据窗口并重置状态机 |
| dumpsys 格式异常 | 每个维度独立 try-except 解析，单字段失败不影响其他维度 |
| 采集间隔不均匀 | 数据存为 (timestamp, value) 元组，线性回归以真实时间为 x 轴，不受变频影响 |
| 工具自身内存增长 | 使用 deque(maxlen=240) 固定窗口，每个进程全部数据约 15KB，10 个进程也只有 150KB |
| 中间状态卡死 | SUSPICIOUS 最大 30 分钟、CONFIRMING 最大 10 分钟，超时强制回退 |
全系列回顾：从零到完整链路
三篇文章讲完了从采集到检测到响应的完整方案，做个全景回顾：
泄漏场景覆盖
| 泄漏场景 | 检测手段 | 预计检出时间 |
|---|---|---|
| 快速泄漏 >600 MB/h | t 检验 | ~5 分钟 |
| 中速泄漏 100-600 MB/h | t 检验 + P25 | 10-20 分钟 |
| 慢泄漏 20-100 MB/h | t 检验（长窗口） + P25 | 20-30 分钟 |
| 极慢泄漏 <20 MB/h | P25 长期积累 | 60 分钟+ |
| 突发泄漏（瞬间 >200MB） | 突增检测 | 30 秒 |
| 阶梯跳变（不是泄漏） | R² 过滤 + P25 不递增 | 正确排除 |
| 纯 GPU 泄漏 | GPU 辅助路径 | 20-30 分钟 |
三层协作总结
| 层 | 做什么 | 核心设计 |
|---|---|---|
| 采集层 | 低干扰拿数据 | 双通道（50ms 高频 + 轮转低频）+ 三级设备适配 + GPU 校准 |
| 检测层 | 准确判泄漏 | 线性回归 + t 检验（零配置）+ P25 基线 + 四级状态机 |
| 响应层 | 对症抓文件 | 5 类泄漏 5 种诊断路径 + 冷却 + 全局锁 |
和传统方案的对比
| 维度 | 传统方案 | 本方案 |
|---|---|---|
| 采集开销 | dumpsys 5-15s/次 | 高频 50ms/次 |
| 阈值配置 | 人工拍 50MB | 零配置，t 检验自适应 |
| 检测灵敏度 | 慢泄漏检不到 | 理论上任何速率都能发现 |
| 泄漏分类 | 不分类，统一抓 hprof | 5 种类型精准分类 |
| 诊断耗时 | 一律 60-90s | 非 Java 泄漏仅 1-5s |
| 多进程 | 5+ 进程必超时 | 轮转制永不超时 |
| 误报控制 | 无 | 四级状态机 + 超时回退 |
已知边界
没有万能的方案，这套系统也有覆盖不到的场景：
| 场景 | 原因 | 建议补充方案 |
|---|---|---|
| 极慢泄漏 <20MB/h | 需要 >1 小时才能积累足够统计证据 | 压测首末内存对比 |
| GC 压住的对象泄漏 | 对象已泄漏但 GC 能回收软引用，内存量不变 | GC 日志监控 |
| 文件描述符/连接泄漏 | 不是内存泄漏，不在本方案范围内 | fd 监控 |
写在最后
这套方案的核心思想可以总结为三个词：按需升级、统计驱动、对症下药。
- 按需升级：平时用最轻的方式巡逻，只在需要确认时才用重量级命令
- 统计驱动：用 t 检验让数据自己说话，不需要人工调参
- 对症下药：不同泄漏类型采集不同的诊断文件，不做无效操作
如果你也在做 Android 性能测试或稳定性压测，希望这个系列能给你一些启发。欢迎在评论区交流你遇到的内存泄漏检测问题，我会尽量回复。
系列目录
- 上篇：为什么传统方案不靠谱 + 采集层设计
- 中篇：用统计学替代"拍脑袋阈值"——检测层设计
- 本篇（下）：对症下药，5 种泄漏 5 种抓法——响应层设计
我是测试工坊，专注自动化测试和性能工程。 如果这个系列对你有帮助，点个赞 + 收藏支持一下 👍 关注我，后续还有更多自动化测试和性能工程的干货分享。
