Koom和LeakCanary

1.LeakCanary原理

在 Java 中软引用(SoftReference)和弱引用(WeakReference)在创建的时候都可以关联一个引用队列。
当 GC（垃圾回收线程）准备回收一个对象时，如果发现它还仅有软引用(或弱引用，或虚引用)指向它，就会在回收该对象之前，
把这个软引用（或弱引用，或虚引用）加入到与之关联的引用队列（ReferenceQueue）中。如果一个软引用（或弱引用，或虚引用）
对象本身在引用队列中，则说明该引用对象所指向的对象被回收了。

LeakCanary 的实现就是将所有的 Activity 或 Fragment 实例放入到弱引用中，并关联一个引用队列。
如果实例进行了回收，那么弱引用就会放入到 ReferenceQueue 中，并调用 
removeWeaklyReachableObjects 方法将已经回收的对象从watchedObjects 
集合中删除，然后剩下的就是没有被回收，发生内存泄漏的。如果一段时间
后，所监控的实例还未在 ReferenceQueue 中出现，那么可以证明出现了内存
泄漏导致了实例没有被回收。

leakcanary的缺陷：

2.koom

1、监控机制
2、Dump内存镜像:
   内存镜像的工作原理与硬盘的[热备份](https://baike.baidu.com/item/%E7%83%AD%E5%A4%87%E4%BB%BD/8862202)类似，内存镜像是将内存数据做两个拷贝，分别放在主内存和镜像内存中

   dump hprof 可分析的文件

   KOOM高性能dump：KOOM利用 Linux 的Copy-on-write机制(COW)，fork子进程dump内存镜像

   fork成功以后，父进程立刻恢复虚拟机运行，子进程dump内存镜像期间不会受到父进程数据变动的影响

   COW机制：写时复制

   fork()会创建一个子进程，子进程的是父进程的副本；
   exec()重新装载程序，清空数据；

   一般的fork()会直接将父进程的数据拷贝到子进程中，拷贝完之后，会执行exec()，父进程和子进程之间的数据段和堆栈是相互独立的

   为了节省fork子进程的内存消耗和耗时，fork出的子进程并不会copy父进程的内存，而是和父进程共享内存空间，父子进程只在发生内存写入操作时，系统才会分配新的内存为写入方保留单独的拷贝。

   进程保留了fork瞬间时父进程的内存镜像，且后续父进程对内存的修改不会影响子进程。

   Copy-on-write的fork创建出的子进程，与父进程共享内存空间。既保留了镜像数据，同时子进程dump的过程也不会影响主进程执行**

   暂停虚拟机需要调系统库，但谷歌从Android 7.0开始对调用系统库做了限制，基于此前提，快手自研了kwai-linker组件，绕过了这一限制

  3、解析流程

   不同的Detector有不同的isLeak策略
   解析性能优化
   KOOM没有采用LeakCanary1.0版本的HAHA解析引擎，使用HAHA解析过程中非常容易OOM，且解析速度极慢。LeakCanary2.0版本使用Shark新版解析引擎，KOOM基于Shark引擎进行解析。

   Total：KOOM利用Linux Copy-on-write机制fork子进程dump大大提高了dump效率。 内存阈值检测方式，将对象是否泄漏的判断延迟到了解析时，避免传统的频繁主动gc**