[Toc]

顶层设计思想

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

依赖底层技术

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

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

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

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

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

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

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

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

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中新增了对象，同时弱引用为空了；

leakcanary思想全解析