LeakCanary 源码分析

作者: 莫库施勒 | 来源:发表于2019-06-08 16:14 被阅读0次

使用

LeakCanary 已经有了最新的2.0 版本，可以去获取最新版本https://github.com/square/leakcanary
但是呢，我们还是先分析下旧的版本，添加完依赖后我们需要作如下初始化

public class ExampleApplication extends Application {

  @Override public void onCreate() {
    super.onCreate();
    if (LeakCanary.isInAnalyzerProcess(this)) {
      // This process is dedicated to LeakCanary for heap analysis.
      // You should not init your app in this process.
      return;
    }
    LeakCanary.install(this);
    // Normal app init code...
  }
}

总体框架

先是一张盗的图，先来个总体印象

总体框架

初始化

我们分析也是从两方面入手，一个是install 方法，另一个是 watch 方法

  public static @NonNull RefWatcher install(@NonNull Application application) {
    return refWatcher(application).listenerServiceClass(DisplayLeakService.class)
        .excludedRefs(AndroidExcludedRefs.createAppDefaults().build())
        .buildAndInstall();
  }
  public static @NonNull AndroidRefWatcherBuilder refWatcher(@NonNull Context context) {
    return new AndroidRefWatcherBuilder(context);
  }

这里先是创建一个 AndroidRefWatcherBuilder,然后通过 builder 模式进行配置

public final class AndroidRefWatcherBuilder extends RefWatcherBuilder<AndroidRefWatcherBuilder> {
  ...
  private boolean watchActivities = true; 
  private boolean watchFragments = true;
  
  public @NonNull RefWatcher buildAndInstall() {
    RefWatcher refWatcher = build();
    if (refWatcher != DISABLED) {
      ...
      if (watchActivities) { // 1
        ActivityRefWatcher.install(context, refWatcher);
      }
      if (watchFragments) {  // 2
        FragmentRefWatcher.Helper.install(context, refWatcher);
      }
    }
    return refWatcher;
  }
}

从1, 2 两处，我们知道它们的是监控 Activity 和 Fragment，需要把 refWatcher 的句柄传过。从它们的定义我们可以看出来，默认值都是 true。也就是默认都监听/

接下来是 watch 方法

public final class RefWatcher {

  private final WatchExecutor watchExecutor;

  public void watch(Object watchedReference, String referenceName) {
    ...
    String key = UUID.randomUUID().toString();
    retainedKeys.add(key);
    final KeyedWeakReference reference = new KeyedWeakReference(watchedReference, key, referenceName, queue);

    ensureGoneAsync(watchStartNanoTime, reference);
  }
  
  private void ensureGoneAsync(final long watchStartNanoTime, final KeyedWeakReference reference) {
    watchExecutor.execute(new Retryable() {
      @Override public Retryable.Result run() {
        return ensureGone(reference, watchStartNanoTime);
      }
    });
  }
}

我们看到参数会被封装成WeakReference，并把封装后的参数传递给一个 Executor，这是用来避免同步造成的阻塞。

我们追踪 AndroidRefWatcherBuilder, 这个默认的 Executor 是 AndroidWatchExecutor,它继承的并不是一个 Executor, 而是WatchExecutor,它执行异步的原理是通过 Handler来实现的，而且用的是 IdleHandler。用的是postRunnable，用来在 app 空闲的时候执行
它所要异步执行的方法是 ensureGone

  Retryable.Result ensureGone(final KeyedWeakReference reference, final long watchStartNanoTime) {
    removeWeaklyReachableReferences();  // 2
    ...
    if (gone(reference)) {  // 3
      return DONE;
    }
    gcTrigger.runGc();  // 4
    removeWeaklyReachableReferences();  // 5
    if (!gone(reference)) { // 6
      // 发现泄漏
      ...
    }
    return DONE;
  }

  private void removeWeaklyReachableReferences() {
    // WeakReferences are enqueued as soon as the object to which they point to becomes weakly
    // reachable. This is before finalization or garbage collection has actually happened.
    KeyedWeakReference ref;
    while ((ref = (KeyedWeakReference) queue.poll()) != null) {
      retainedKeys.remove(ref.key);
    }
  }

我们 watch 的流程是这样的：
主线程 onDestroy() -> watch() -> retainedKeys.add(ref.key)。WatchExecutor 启动

然后就是WatchExecutor.execute
WatchExecutor.execute() -> ensureGone() -> removeWeaklyReachableReferences() -> 遍历 ReferenceQueue，从 retainedKeys.remove(ref.key)。gone 方法判断是否可达，如果不可达直接返回，否则就可能会存在泄漏问题。

GC

我们使用Runtime.getRuntime().gc() 来触发gc

public final class RefWatcher {
  private final HeapDumper heapDumper;
  private final HeapDump.Listener heapdumpListener;

  Retryable.Result ensureGone(final KeyedWeakReference reference, final long watchStartNanoTime) {
    ...
    gcTrigger.runGc();  
    removeWeaklyReachableReferences();  
    if (!gone(reference)) { 
      // 发现泄漏
      File heapDumpFile = heapDumper.dumpHeap();

      HeapDump heapDump = heapDumpBuilder.heapDumpFile(heapDumpFile) // 生成堆快照 .hprof
          ...
          .build();

      heapdumpListener.analyze(heapDump);
    }
    return DONE;
  }
}

public final class AndroidHeapDumper implements HeapDumper {

  @Override @Nullable 
  public File dumpHeap() {
    File heapDumpFile = leakDirectoryProvider.newHeapDumpFile();
    ...
    try {
      Debug.dumpHprofData(heapDumpFile.getAbsolutePath());
      ...
      return heapDumpFile;
    } catch (Exception e) { ... }
  }
}

之后由 heapdumpListener.analyze(heapDump) 把数据传到日志展示层

弱引用

从JDK1.2版本开始，把对象的引用分为四种级别，从而使程序能更加灵活的控制对象的生命周期。这四种级别由高到低依次为：强引用、软引用、弱引用和虚引用。
1. 强引用
平时我们编程的时候例如：Object object=new Object（）；那object就是一个强引用了。如果一个对象具有强引用，那就类似于必不可少的生活用品，垃圾回收器绝不会回收它。当内存空间不足，Java虚拟机宁愿抛出OutOfMemoryError错误，使程序异常终止，也不会靠随意回收具有强引用的对象来解决内存不足问题。

2. 软引用（SoftReference）

如果一个对象只具有软引用，那就类似于可有可物的生活用品。如果内存空间足够，垃圾回收器就不会回收它，如果内存空间不足了，就会回收这些对象的内存。只要垃圾回收器没有回收它，该对象就可以被程序使用。软引用可用来实现内存敏感的高速缓存。软引用可以和一个引用队列（ReferenceQueue）联合使用，如果软引用所引用的对象被垃圾回收，Java虚拟机就会把这个软引用加入到与之关联的引用队列中。

3. 弱引用（WeakReference）

如果一个对象只具有弱引用，那就类似于可有可物的生活用品。弱引用与软引用的区别在于：只具有弱引用的对象拥有更短暂的生命周期。在垃圾回收器线程扫描它所管辖的内存区域的过程中，一旦发现了只具有弱引用的对象，不管当前内存空间足够与否，都会回收它的内存。不过，由于垃圾回收器是一个优先级很低的线程，因此不一定会很快发现那些只具有弱引用的对象。弱引用可以和一个引用队列（ReferenceQueue）联合使用，如果弱引用所引用的对象被垃圾回收，Java虚拟机就会把这个弱引用加入到与之关联的引用队列中。

4. 虚引用（PhantomReference）

"虚引用"顾名思义，就是形同虚设，与其他几种引用都不同，虚引用并不会决定对象的生命周期。如果一个对象仅持有虚引用，那么它就和没有任何引用一样，在任何时候都可能被垃圾回收。虚引用主要用来跟踪对象被垃圾回收的活动。虚引用与软引用和弱引用的一个区别在于：虚引用必须和引用队列（ReferenceQueue）联合使用。当垃圾回收器准备回收一个对象时，如果发现它还有虚引用，就会在回收对象的内存之前，把这个虚引用加入到与之关联的引用队列中。程序可以通过判断引用队列中是否已经加入了虚引用，来了解被引用的对象是否将要被垃圾回收。程序如果发现某个虚引用已经被加入到引用队列，那么就可以在所引用的对象的内存被回收之前采取必要的行动。

//创建一个强引用   
String str = new String("hello");   
//创建引用队列, 为范型标记，表明队列中存放String对象的引用 
ReferenceQueue rq = new ReferenceQueue();  
//创建一个弱引用，它引用"hello"对象，并且与rq引用队列关联
WeakReference wf = new WeakReference(str, rq);

它们在内存中的关系

引用队列是垃圾收集器向应用程序返回关于对象生命周期的信息的主要方法，在弱引用对象成为 GC 候选对象时，这个引用对象就在引用清除后加入到引用队列中

Reference 对象

pending 在gc时会将要处理的对象放到这个静态字段上面
discovered 被VM使用，表示要处理的对象的下一个对象

pending 和 discovered示意图
referent 由GC特别处理，表示其引用的对象，也就是我们在构造的时候需要被包装在其中的对象。如果一旦被回收，则会直接置为null
next 即描述当前引用节点所存储的下一个即将被处理的节点。但next仅在放到queue中才会有意义。因为，只有在enqueue的时候，会将next设置为下一个要处理的Reference对象。
queue 是对象即将被回收时所要通知的队列。
对象有四种状态 Active(新创建的)、Pending(等着被内部线程ReferenceHandler处理入队)、Enqueued(对象已经为待回收，并且引用对象已经放到queue当中了)、Inactive(由外部从queue中获取到，并且已经处理掉了,并且此引用对象可以被回收，并且对内部封装的对象也可以被回收掉了)

状态转换图

ReferenceHandler

继承 Thread, 在Reference类的static构造块中启动，并且被设置为高优先级和daemon状态。此线程要做的事情，是不断的检查pending 是否为null，如果pending不为null，则将pending进行enqueue，否则线程进入wait状态。
pending是由jvm来赋值的，当Reference内部的referent对象的可达状态改变时，jvm会将Reference对象放入pending链表。
ReferenceQueue是作为 JVM GC与上层Reference对象管理之间的一个消息传递方式，它使得我们可以对所监听的对象引用可达发生变化时做一些处理

LeakCanary 源码分析

使用

总体框架

初始化

GC

弱引用

Reference 对象

ReferenceHandler

相关文章

网友评论

延伸阅读

深度阅读

栏目导航

热点阅读