自己编写的一个Activity内存泄漏检测工具_explicit concurrent copying gc freed-CSDN博客

本文链接：https://blog.csdn.net/mingC0758/article/details/81545119

本文介绍了作者自己编写的Activity内存泄漏检测工具，包括其使用方法、工具架构和实现细节。通过解决GC误判问题，提高检测准确性，并提供了如何定位内存泄漏的步骤，使用MAT工具分析泄漏实例的强引用链。

摘要由CSDN通过智能技术生成

自己编写的一个Activity内存泄漏检测工具

自己编写的一个Activity内存泄漏检测工具

看完LeakCanary的源码之后，有点想自己动手写一个内存泄漏的工具了，正所谓自己动手，丰衣足食。

真正做起来，其实会出现各种问题，最大的问题就是误判，经常由于GC没有及时把销毁的Activity回收而误判未内存泄漏，即便把检测时间延长也是如此：

（这是在两次gc后等待10秒仍然存活的activity，此时仅被虚引用指向）

最后的解决办法就是，尽可能多地调用GC，让误判率降低，这样导致的一个结果时，当频繁的活动销毁时会带来性能下降。

使用

配置

首先在Application中安装：

public class MyApplication extends Application{
   
    @Override
    public void onCreate() {
        super.onCreate();
        new LeakMonitor().install(this);
    }
}

当发生内存泄漏时会弹出通知：
这里写图片描述

创建一个模拟内存泄漏的activity：
这里写图片描述

定位内存泄漏

打开目录:

/storage/emulated/0/Android/data/com.newsapp/files/Documents/

把文件导出到桌面：
这里写图片描述

用以下命令转换为标准的hprof文件：

hprof-conv C:\Users\mingC\Desktop\com.newsapp.main.LeakActivity@a4c55ea heapdump.hprof

用MAT工具打开heapdump.hprof，进入Histogram页面：
这里写图片描述

在regex中输入疑似内存泄漏的类名，回车：
这里写图片描述

可以看到LeakActivity虽然已经走完了生命周期，但是仍然存在它是一个实例，LeakActivity$1表示内部类Thread，接下来查看该对象的强引用链（exclude掉弱引用、软应用、虚引用）：
这里写图片描述

最终我们定位到了引用着LeakActivity的是内部类Thread：
这里写图片描述

Java会将内部类表示为”外部类 1"的形式，非静态内部类