首先看下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)
网友评论