安卓筆記俠

專(zhuān)注安卓開(kāi)發(fā)

導(dǎo)航

新隨筆
管理

Koom和LeakCanary

1.LeakCanary原理

在 Java 中軟引用(SoftReference)和弱引用(WeakReference)在創(chuàng)建的時(shí)候都可以關(guān)聯(lián)一個(gè)引用隊(duì)列。
當(dāng) GC（垃圾回收線程）準(zhǔn)備回收一個(gè)對(duì)象時(shí)，如果發(fā)現(xiàn)它還僅有軟引用(或弱引用，或虛引用)指向它，就會(huì)在回收該對(duì)象之前，
把這個(gè)軟引用（或弱引用，或虛引用）加入到與之關(guān)聯(lián)的引用隊(duì)列（ReferenceQueue）中。如果一個(gè)軟引用（或弱引用，或虛引用）
對(duì)象本身在引用隊(duì)列中，則說(shuō)明該引用對(duì)象所指向的對(duì)象被回收了。

LeakCanary 的實(shí)現(xiàn)就是將所有的 Activity 或 Fragment 實(shí)例放入到弱引用中，并關(guān)聯(lián)一個(gè)引用隊(duì)列。
如果實(shí)例進(jìn)行了回收，那么弱引用就會(huì)放入到 ReferenceQueue 中，并調(diào)用 
removeWeaklyReachableObjects 方法將已經(jīng)回收的對(duì)象從watchedObjects 
集合中刪除，然后剩下的就是沒(méi)有被回收，發(fā)生內(nèi)存泄漏的。如果一段時(shí)間
后，所監(jiān)控的實(shí)例還未在 ReferenceQueue 中出現(xiàn)，那么可以證明出現(xiàn)了內(nèi)存
泄漏導(dǎo)致了實(shí)例沒(méi)有被回收。

leakcanary的缺陷：

2.koom

1、監(jiān)控機(jī)制
2、Dump內(nèi)存鏡像:
   內(nèi)存鏡像的工作原理與硬盤(pán)的[熱備份](https://baike.baidu.com/item/%E7%83%AD%E5%A4%87%E4%BB%BD/8862202)類(lèi)似，內(nèi)存鏡像是將內(nèi)存數(shù)據(jù)做兩個(gè)拷貝，分別放在主內(nèi)存和鏡像內(nèi)存中

   dump hprof 可分析的文件

   KOOM高性能dump：KOOM利用 Linux 的Copy-on-write機(jī)制(COW)，fork子進(jìn)程dump內(nèi)存鏡像

   fork成功以后，父進(jìn)程立刻恢復(fù)虛擬機(jī)運(yùn)行，子進(jìn)程dump內(nèi)存鏡像期間不會(huì)受到父進(jìn)程數(shù)據(jù)變動(dòng)的影響

   COW機(jī)制：寫(xiě)時(shí)復(fù)制

   fork()會(huì)創(chuàng)建一個(gè)子進(jìn)程，子進(jìn)程的是父進(jìn)程的副本；
   exec()重新裝載程序，清空數(shù)據(jù)；

   一般的fork()會(huì)直接將父進(jìn)程的數(shù)據(jù)拷貝到子進(jìn)程中，拷貝完之后，會(huì)執(zhí)行exec()，父進(jìn)程和子進(jìn)程之間的數(shù)據(jù)段和堆棧是相互獨(dú)立的

   為了節(jié)省fork子進(jìn)程的內(nèi)存消耗和耗時(shí)，fork出的子進(jìn)程并不會(huì)copy父進(jìn)程的內(nèi)存，而是和父進(jìn)程共享內(nèi)存空間，父子進(jìn)程只在發(fā)生內(nèi)存寫(xiě)入操作時(shí)，系統(tǒng)才會(huì)分配新的內(nèi)存為寫(xiě)入方保留單獨(dú)的拷貝。

   進(jìn)程保留了fork瞬間時(shí)父進(jìn)程的內(nèi)存鏡像，且后續(xù)父進(jìn)程對(duì)內(nèi)存的修改不會(huì)影響子進(jìn)程。

   Copy-on-write的fork創(chuàng)建出的子進(jìn)程，與父進(jìn)程共享內(nèi)存空間。既保留了鏡像數(shù)據(jù)，同時(shí)子進(jìn)程dump的過(guò)程也不會(huì)影響主進(jìn)程執(zhí)行**

   暫停虛擬機(jī)需要調(diào)系統(tǒng)庫(kù)，但谷歌從Android 7.0開(kāi)始對(duì)調(diào)用系統(tǒng)庫(kù)做了限制，基于此前提，快手自研了kwai-linker組件，繞過(guò)了這一限制

  3、解析流程

   不同的Detector有不同的isLeak策略
   解析性能優(yōu)化
   KOOM沒(méi)有采用LeakCanary1.0版本的HAHA解析引擎，使用HAHA解析過(guò)程中非常容易OOM，且解析速度極慢。LeakCanary2.0版本使用Shark新版解析引擎，KOOM基于Shark引擎進(jìn)行解析。

   Total：KOOM利用Linux Copy-on-write機(jī)制fork子進(jìn)程dump大大提高了dump效率。 內(nèi)存閾值檢測(cè)方式，將對(duì)象是否泄漏的判斷延遲到了解析時(shí)，避免傳統(tǒng)的頻繁主動(dòng)gc**

posted on 2024-10-20 18:19 安卓筆記俠閱讀(195) 評(píng)論(0) 收藏舉報(bào)

刷新頁(yè)面返回頂部