线上内存泄漏工具Koom

首先看下LeakCanary原理

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

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

LeakCanary Code

AppWatcher

fun appDefaultWatchers(
application: Application,
reachabilityWatcher: ReachabilityWatcher = objectWatcher
): List<InstallableWatcher> {
return listOf(
  ActivityWatcher(application, reachabilityWatcher),
  FragmentAndViewModelWatcher(application, reachabilityWatcher),
  RootViewWatcher(reachabilityWatcher),
  ServiceWatcher(reachabilityWatcher)
)}

fun manualInstall(
application: Application,
retainedDelayMillis: Long = TimeUnit.SECONDS.toMillis(5),
watchersToInstall: List<InstallableWatcher> = appDefaultWatchers(application) ) {
checkMainThread()
check(retainedDelayMillis >= 0) {
  "retainedDelayMillis $retainedDelayMillis must be at least 0 ms"
}
this.retainedDelayMillis = retainedDelayMillis
// Requires AppWatcher.objectWatcher to be set
LeakCanaryDelegate.loadLeakCanary(application)
watchersToInstall.forEach {
  it.install()
}}

ActivityWatcher 配置项

private val lifecycleCallbacks =
object : Application.ActivityLifecycleCallbacks by noOpDelegate() {
  override fun onActivityDestroyed(activity: Activity) {
    reachabilityWatcher.expectWeaklyReachable(
      activity, "${activity::class.java.name} received Activity#onDestroy() callback"
    )
  }
}

ObjectWatcher

private val watchedObjects = mutableMapOf<String, KeyedWeakReference>()
private val queue = ReferenceQueue<Any>()

@Synchronized override fun expectWeaklyReachable(watchedObject: Any,description: String) {
removeWeaklyReachableObjects()
val key = UUID.randomUUID()
  .toString()
val watchUptimeMillis = clock.uptimeMillis()
val reference =
  KeyedWeakReference(watchedObject, key, description, watchUptimeMillis, queue)
SharkLog.d {
  "Watching " +
    (if (watchedObject is Class<*>) watchedObject.toString() else "instance of ${watchedObject.javaClass.name}") +
    (if (description.isNotEmpty()) " ($description)" else "") +
    " with key $key"
}
watchedObjects[key] = reference //key:uuid, value:弱引用
checkRetainedExecutor.execute {
  moveToRetained(key)
}
}
private fun removeWeaklyReachableObjects() {
// 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.
var ref: KeyedWeakReference?
do {
  ref = queue.poll() as KeyedWeakReference?
  if (ref != null) {
    watchedObjects.remove(ref.key)
  }
} while (ref != null)
}

KeyedWeakReference

class KeyedWeakReference(
  referent: Any,
  val key: String,
  val description: String,
  val watchUptimeMillis: Long,
  referenceQueue: ReferenceQueue<Any>
  ) : WeakReference<Any>(
  referent, referenceQueue
  )

log

Watching instance of com.mthq.viewlib.maintab.MainTabActivity 
(com.mthq.viewlib.maintab.MainTabActivity received Activity#onDestroy()     
callback) with key 89224b7d-3280-45c8-bdfc-9a9ebeb601e7

leakcanary的缺陷：

leakcanary缺点

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**

   [https://blog.csdn.net/Kwai_tech/article/details/107964806](https://blog.csdn.net/Kwai_tech/article/details/107964806)