leakcanary思想全解析

[Toc]

顶层设计思想

顶层设计思路:提供一款应用运行时泄露检测系统 , 通过检测实例生命周期不一致导致的泄露进行可视化显示

依赖底层技术

在进行检测系统开发的时候,会依赖底层技术进行泄露的检测依据;
java的内存泄露检测的底层技术依赖就来自,4中类型的对象再gc时候的不同表现,提炼出一套可信的检测机制;

详细的文章-张绍文leakcanary和内存泄漏:

强引用:new 出来的对象属于强引用类型对象,在强引用作用域内操作系统不会回收内存,即时抛出oom异常也不会回收对象。在超过强引用作用域或者将实例对象置为null,就可以被垃圾回收掉;(那么activity在使用之后依据什么被回收掉了?)
软引用: softrefrence实现软引用,为强引用的弱化版本,在回收时机上比强引用多一些场景。当系统内存充足时候不会被回收;系统内存不足时候会被回收;

软引用再实际中应用很多,高速缓存用到软引用;
浏览器的缓存策略也来自软引用策略,网页结束就回收会造成每次加载速度慢,结束不回收又会造成内存膨胀;

弱引用: weakrefrence实现弱引用,弱引用比软引用发生回收几率更大。弱引用再gc发生时不论内存是否吃紧都会被回收;

这也是leakcanary依赖的底层实现技术,其他dump和文件解析溯源引用链都是在这基础上实现的;

虚引用: 虚引用并不决定对象的生命周期,一个对象仅持有虚引用那么跟没有持有引用一样;虚引用主要用来跟踪对象被gc垃圾回收的活动;

虚引用在垃圾回收之前就相当与没有引用一样,当被垃圾回收后,虚引用会被加入到引用队列中。以便在对象销毁后,我们可以做一些自己的事情

ReferenceQueue(引用队列):
引用队列的主要作用是,当一个引用被垃圾回收之前,会被放入到引用队列中。
对于软引用和弱引用,我们希望当一个对象被gc掉的时候通知用户线程,进行额外的处理时,就需要使用引用队列了。ReferenceQueue即这样的一个对象,当一个obj被gc掉之后,其相应的包装类,即ref对象会被放入queue中。我们可以从queue中获取到相应的对象信息,同时进行额外的处理。比如反向操作,数据清理等。

leakcanary主流程

leakcanary主流程

核心处理方法跟踪

private void ensureGoneAsync(final long watchStartNanoTime, final KeyedWeakReference reference) {
    watchExecutor.execute(new Retryable() {
    //开子线程进行分析
      @Override public Retryable.Result run() {
        return ensureGone(reference, watchStartNanoTime);
      }
    });
  }

  @SuppressWarnings("ReferenceEquality") 
  // Explicitly checking for named null. 核心处理类,完成弱引用的判断-回收-再判断-dump内存-分析内存
  Retryable.Result ensureGone(final KeyedWeakReference reference, final long watchStartNanoTime) {
    long gcStartNanoTime = System.nanoTime();
    long watchDurationMs = NANOSECONDS.toMillis(gcStartNanoTime - watchStartNanoTime);
    //尝试去掉已经回收的内存
    removeWeaklyReachableReferences();
    //调试模式直接返回
    if (debuggerControl.isDebuggerAttached()) {
      // The debugger can create false leaks.
      return RETRY;
    }
    //内存已回收直接返回
    if (gone(reference)) {
      return DONE;
    }
    //再次尝试回收内存 , 主要是去掉耗时gc的影响;
    gcTrigger.runGc();
    //再次尝试去掉已经回收的内存
    removeWeaklyReachableReferences();
    if (!gone(reference)) {
      //再次回收还存在内存中
      long startDumpHeap = System.nanoTime();
      long gcDurationMs = NANOSECONDS.toMillis(startDumpHeap - gcStartNanoTime);
      //dump内存信息
      File heapDumpFile = heapDumper.dumpHeap();
      if (heapDumpFile == RETRY_LATER) {
        // Could not dump the heap.
        return RETRY;
      }
      long heapDumpDurationMs = NANOSECONDS.toMillis(System.nanoTime() - startDumpHeap);
      //分析内存dump文件
      heapdumpListener.analyze(
          new HeapDump(heapDumpFile, reference.key, reference.name, excludedRefs, watchDurationMs,
              gcDurationMs, heapDumpDurationMs));
    }
    return DONE;
  }

以上是leakcanary核心的如何获取到可能有内存泄漏的核心处理方法,在可能有泄漏的位置会开始dump内存快照,拿到快照后会到haha库中进行快照处理;那么继续跟踪haha库的处理;

heapdumpListener.analyze(***)最终调用到:
HeapAnalyzerService intentservice中,intentservice调用HeapAnalyzer进行dump文件的格式化操作;

HeapAnalyzer heapAnalyzer = new HeapAnalyzer(heapDump.excludedRefs);

AnalysisResult result = heapAnalyzer.checkForLeak(heapDump.heapDumpFile, heapDump.referenceKey);
    
开始分析,checkForLeak();

public AnalysisResult checkForLeak(File heapDumpFile, String referenceKey) {
    long analysisStartNanoTime = System.nanoTime();

    if (!heapDumpFile.exists()) {
      Exception exception = new IllegalArgumentException("File does not exist: " + heapDumpFile);
      return failure(exception, since(analysisStartNanoTime));
    }

    try {
      HprofBuffer buffer = new MemoryMappedFileBuffer(heapDumpFile);
      //内部fileinputstream文件输入流读文件
      HprofParser parser = new HprofParser(buffer);
      //对文件读取内容进行格式化
      Snapshot snapshot = parser.parse();
      //去除重复gcroot
      deduplicateGcRoots(snapshot);

     //通过实例id查找snapshot中含有该实例的引用调用链
      Instance leakingRef = findLeakingReference(referenceKey, snapshot);

      // False alarm, weak reference was cleared in between key check and heap dump.
      if (leakingRef == null) {
        return noLeak(since(analysisStartNanoTime));
      }
    //做notification处理;
      return findLeakTrace(analysisStartNanoTime, snapshot, leakingRef);
    } catch (Throwable e) {
      return failure(e, since(analysisStartNanoTime));
    }
  }

库的局限

检测确实很方便,但是不是所有的泄露都能检测出来;
1.对于service的泄露无法检测,因为检测是依赖生命周期感知的 , fragment依附于activity也可以通过activity的生命周倩来感知;

2.对于作为mainactivity的活动无法检测,因为该activity在栈底,除非构建mainactivity不在栈底的操作,才好对其进行泄露检查;

底层验证代码

        ReferenceQueue<WeakReference<LeadEntry>> referenceQueue = new ReferenceQueue<WeakReference<LeadEntry>>();
        WeakReference<LeadEntry> weakReference1 = new WeakReference(new LeadEntry(),referenceQueue);

        System.out.println("weakReference1  :   " + weakReference1.get());
        System.out.println("referenceQueue.poll()   " + referenceQueue.poll());

        //一次gc 之后不管是否内存足够都会回收掉内存;
        System.gc();

        System.out.println("weakReference1  :   " + weakReference1.get());
        System.out.println("referenceQueue.poll()  " + referenceQueue.poll());
        
        
        最终执行结果:
        
        weakReference1  :   demo.java_theory.leak_demo.LeakDemo$LeadEntry@610455d6
        referenceQueue.poll()   null
        weakReference1  :   null
        referenceQueue.poll()  java.lang.ref.WeakReference@511d50c0
        
        在weakrefrencegc之前是拥有引用的,queue中没有该对象,在gc之后queue中新增了对象,同时弱引用为空了;