? ? ? ? ? 想寫一篇關(guān)于android的內(nèi)存分配和回收文章的想法來源于追查一個(gè)魅族手機(jī)圖片滑動(dòng)卡頓問題，我們想了很多辦法還是沒有避免他不停的GC，所以就打算詳細(xì)的看看內(nèi)存分配和GC的原理，為什么會(huì)不斷的GC，GC ALLOC和GC COCURRENT有什么區(qū)別，能不能想辦法擴(kuò)大堆內(nèi)存減少GC的頻次等等。
1、JVM內(nèi)存回收機(jī)制
1.1 回收算法
標(biāo)記回收算法（Mark and Sweep GC）
? ? ? ? 從"GC Roots"集合開始，將內(nèi)存整個(gè)遍歷一次，保留所有可以被GC Roots直接或間接引用到的對(duì)象，而剩下的對(duì)象都當(dāng)作垃圾對(duì)待并回收，這個(gè)算法需要中斷進(jìn)程內(nèi)其它組件的執(zhí)行并且可能產(chǎn)生內(nèi)存碎片
復(fù)制算法 (Copying）
? ? ? ? ?將現(xiàn)有的內(nèi)存空間分為兩快，每次只使用其中一塊，在垃圾回收時(shí)將正在使用的內(nèi)存中的存活對(duì)象復(fù)制到未被使用的內(nèi)存塊中，之后，清除正在使用的內(nèi)存塊中的所有對(duì)象，交換兩個(gè)內(nèi)存的角色，完成垃圾回收。
標(biāo)記-壓縮算法 (Mark-Compact)
? ? ? ? 先需要從根節(jié)點(diǎn)開始對(duì)所有可達(dá)對(duì)象做一次標(biāo)記，但之后，它并不簡單地清理未標(biāo)記的對(duì)象，而是將所有的存活對(duì)象壓縮到內(nèi)存的一端。之后，清理邊界外所有的空間。這種方法既避免了碎片的產(chǎn)生，又不需要兩塊相同的內(nèi)存空間，因此，其性價(jià)比比較高。
分代
? ? ? ? 將所有的新建對(duì)象都放入稱為年輕代的內(nèi)存區(qū)域，年輕代的特點(diǎn)是對(duì)象會(huì)很快回收，因此，在年輕代就選擇效率較高的復(fù)制算法。當(dāng)一個(gè)對(duì)象經(jīng)過幾次回收后依然存活，對(duì)象就會(huì)被放入稱為老生代的內(nèi)存空間。對(duì)于新生代適用于復(fù)制算法，而對(duì)于老年代則采取標(biāo)記-壓縮算法。
1.2 復(fù)制和標(biāo)記-壓縮算法的區(qū)別
? ? ? ?乍一看這兩個(gè)算法似乎并沒有多大的區(qū)別，都是標(biāo)記了然后挪到另外的內(nèi)存地址進(jìn)行回收，那為什么不同的分代要使用不同的回收算法呢？
其實(shí)2者最大的區(qū)別在于前者是用空間換時(shí)間后者則是用時(shí)間換空間。
? ? ? ? 前者的在工作的時(shí)候是不沒有獨(dú)立的“mark”與“copy”階段的，而是合在一起做一個(gè)動(dòng)作，就叫scavenge（或evacuate，或者就叫copy）。也就是說，每發(fā)現(xiàn)一個(gè)這次收集中尚未訪問過的活對(duì)象就直接copy到新地方，同時(shí)設(shè)置forwarding pointer。這樣的工作方式就需要多一份空間。
? ? ? ? ?后者在工作的時(shí)候則需要分別的mark與compact階段，mark階段用來發(fā)現(xiàn)并標(biāo)記所有活的對(duì)象，然后compact階段才移動(dòng)對(duì)象來達(dá)到compact的目的。如果compact方式是sliding compaction，則在mark之后就可以按順序一個(gè)個(gè)對(duì)象“滑動(dòng)”到空間的某一側(cè)。因?yàn)橐呀?jīng)先遍歷了整個(gè)空間里的對(duì)象圖，知道所有的活對(duì)象了，所以移動(dòng)的時(shí)候就可以在同一個(gè)空間內(nèi)而不需要多一份空間。
? ? ? ? ? ?所以新生代的回收會(huì)更快一點(diǎn)，老年代的回收則會(huì)需要更長時(shí)間，同時(shí)壓縮階段是會(huì)暫停應(yīng)用的，所以給我們應(yīng)該盡量避免對(duì)象出現(xiàn)在老年代。
2、Dalvik虛擬機(jī)
2.1 java堆
? ? ? ? Java堆實(shí)際上是由一個(gè)Active堆和一個(gè)Zygote堆組成的，其中，Zygote堆用來管理Zygote進(jìn)程在啟動(dòng)過程中預(yù)加載和創(chuàng)建的各種對(duì)象，而Active堆是在Zygote進(jìn)程fork第一個(gè)子進(jìn)程之前創(chuàng)建的。以后啟動(dòng)的所有應(yīng)用程序進(jìn)程是被Zygote進(jìn)程fork出來的，并都持有一個(gè)自己的Dalvik虛擬機(jī)。在創(chuàng)建應(yīng)用程序的過程中，Dalvik虛擬機(jī)采用COW策略復(fù)制Zygote進(jìn)程的地址空間。
? ? ? ? COW策略：一開始的時(shí)候（未復(fù)制Zygote進(jìn)程的地址空間的時(shí)候），應(yīng)用程序進(jìn)程和Zygote進(jìn)程共享了同一個(gè)用來分配對(duì)象的堆。當(dāng)Zygote進(jìn)程或者應(yīng)用程序進(jìn)程對(duì)該堆進(jìn)行寫操作時(shí)，內(nèi)核就會(huì)執(zhí)行真正的拷貝操作，使得Zygote進(jìn)程和應(yīng)用程序進(jìn)程分別擁有自己的一份拷貝，這就是所謂的COW。因?yàn)閏opy是十分耗時(shí)的，所以必須盡量避免copy或者盡量少的copy。
? ? ? ? 為了實(shí)現(xiàn)這個(gè)目的，當(dāng)創(chuàng)建第一個(gè)應(yīng)用程序進(jìn)程時(shí)，會(huì)將已經(jīng)使用了的那部分堆內(nèi)存劃分為一部分，還沒有使用的堆內(nèi)存劃分為另外一部分。前者就稱為Zygote堆，后者就稱為Active堆。這樣只需把zygote堆中的內(nèi)容復(fù)制給應(yīng)用程序進(jìn)程就可以了。以后無論是Zygote進(jìn)程，還是應(yīng)用程序進(jìn)程，當(dāng)它們需要分配對(duì)象的時(shí)候，都在Active堆上進(jìn)行。這樣就可以使得Zygote堆盡可能少地被執(zhí)行寫操作，因而就可以減少執(zhí)行寫時(shí)拷貝的操作。在Zygote堆里面分配的對(duì)象其實(shí)主要就是Zygote進(jìn)程在啟動(dòng)過程中預(yù)加載的類、資源和對(duì)象了。這意味著這些預(yù)加載的類、資源和對(duì)象可以在Zygote進(jìn)程和應(yīng)用程序進(jìn)程中做到長期共享。這樣既能減少拷貝操作，還能減少對(duì)內(nèi)存的需求。
2.2 對(duì)象分配和回收的幾個(gè)數(shù)據(jù)指標(biāo)
? ? ? ? 記得我們之前在優(yōu)化魅族某手機(jī)的gc卡頓問題時(shí)，發(fā)現(xiàn)他很容易觸發(fā)GC_FOR_MALLOC，這個(gè)GC類別后續(xù)會(huì)說到，是分配對(duì)象內(nèi)存不足時(shí)導(dǎo)致的。可是我們又設(shè)置了很大的堆Size為什么還會(huì)內(nèi)存不夠呢，這里需要了解以下幾個(gè)概念：分別是Java堆的起始大小（Starting Size）、最大值（Maximum Size）和增長上限值（Growth Limit）。
? ? ? ? ?在啟動(dòng)Dalvik虛擬機(jī)的時(shí)候，我們可以分別通過-Xms、-Xmx和-XX:HeapGrowthLimit三個(gè)選項(xiàng)來指定上述三個(gè)值，以上三個(gè)值分別表示表示
Starting Size : Dalvik虛擬機(jī)啟動(dòng)的時(shí)候，會(huì)先分配一塊初始的堆內(nèi)存給虛擬機(jī)使用。
Growth Limit:是系統(tǒng)給每一個(gè)程序的最大堆上限,超過這個(gè)上限，程序就會(huì)OOM
Maximum Size：不受控情況下的最大堆內(nèi)存大小，起始就是我們?cè)谟胠argeheap屬性的時(shí)候，可以從系統(tǒng)獲取的最大堆大小
? ? ? ? ? ? 同時(shí)除了上面的這個(gè)三個(gè)指標(biāo)外，還有幾個(gè)指標(biāo)也是值得我們關(guān)注的，那就是堆最小空閑值（Min Free）、堆最大空閑值（Max Free）和堆目標(biāo)利用率（Target Utilization）。假設(shè)在某一次GC之后，存活對(duì)象占用內(nèi)存的大小為LiveSize，那么這時(shí)候堆的理想大小應(yīng)該為(LiveSize / U)。但是(LiveSize / U)必須大于等于(LiveSize + MinFree)并且小于等于(LiveSize + MaxFree)，每次GC后垃圾回收器都會(huì)盡量讓堆的利用率往目標(biāo)利用率靠攏。所以當(dāng)我們嘗試手動(dòng)去生成一些幾百K的對(duì)象，試圖去擴(kuò)大可用堆大小的時(shí)候，反而會(huì)導(dǎo)致頻繁的GC，因?yàn)檫@些對(duì)象的分配會(huì)導(dǎo)致GC，而GC后會(huì)讓堆內(nèi)存回到合適的比例，而我們使用的局部變量很快會(huì)被回收理論上存活對(duì)象還是那么多，我們的堆大小也會(huì)縮減回來無法達(dá)到擴(kuò)充的目的。
2.3 對(duì)象的分配和GC
1. 調(diào)用函數(shù)dvmHeapSourceAlloc在Java堆上分配指定大小的內(nèi)存。如果分配成功，那么就將分配得到的地址直接返回給調(diào)用者了。函數(shù)dvmHeapSourceAlloc在不改變Java堆當(dāng)前大小的前提下進(jìn)行內(nèi)存分配，這是屬于輕量級(jí)的內(nèi)存分配動(dòng)作。
2. 如果上一步內(nèi)存分配失敗，這時(shí)候就需要執(zhí)行一次GC了。不過如果GC線程已經(jīng)在運(yùn)行中，即gDvm.gcHeap->gcRunning的值等于true，那么就直接調(diào)用函數(shù)dvmWaitForConcurrentGcToComplete等到GC執(zhí)行完成就是了。否則的話，就需要調(diào)用函數(shù)gcForMalloc來執(zhí)行一次GC了，參數(shù)false表示不要回收軟引用對(duì)象引用的對(duì)象。
3. GC執(zhí)行完畢后，再次調(diào)用函數(shù)dvmHeapSourceAlloc嘗試輕量級(jí)的內(nèi)存分配操作。如果分配成功，那么就將分配得到的地址直接返回給調(diào)用者了。
4. 如果上一步內(nèi)存分配失敗，這時(shí)候就得考慮先將Java堆的當(dāng)前大小設(shè)置為Dalvik虛擬機(jī)啟動(dòng)時(shí)指定的Java堆最大值，再進(jìn)行內(nèi)存分配了。這是通過調(diào)用函數(shù)dvmHeapSourceAllocAndGrow來實(shí)現(xiàn)的。
5. 如果調(diào)用函數(shù)dvmHeapSourceAllocAndGrow分配內(nèi)存成功，則直接將分配得到的地址直接返回給調(diào)用者了。
6. 如果上一步內(nèi)存分配還是失敗，這時(shí)候就得出狠招了。再次調(diào)用函數(shù)gcForMalloc來執(zhí)行GC。參數(shù)true表示要回收軟引用對(duì)象引用的對(duì)象。
7. GC執(zhí)行完畢，再次調(diào)用函數(shù)dvmHeapSourceAllocAndGrow進(jìn)行內(nèi)存分配。這是最后一次努力了，成功與事都到此為止。
示例圖如下：
2.4 GC的類型
GC_FOR_MALLOC:表示是在堆上分配對(duì)象時(shí)內(nèi)存不足觸發(fā)的GC。
GC_CONCURRENT: ? 當(dāng)我們應(yīng)用程序的堆內(nèi)存達(dá)到一定量，或者可以理解為快要滿的時(shí)候，系統(tǒng)會(huì)自動(dòng)觸發(fā)GC操作來釋放內(nèi)存。
GC_FOR_MALLOC: ? 當(dāng)我們的應(yīng)用程序需要分配更多內(nèi)存，可是現(xiàn)有內(nèi)存已經(jīng)不足的時(shí)候，系統(tǒng)會(huì)進(jìn)行GC操作來釋放內(nèi)存。
GC_EXPLICIT:表示是應(yīng)用程序調(diào)用System.gc、VMRuntime.gc接口或者收到SIGUSR1信號(hào)時(shí)觸發(fā)的GC。
GC_BEFORE_OOM:表示是在準(zhǔn)備拋OOM異常之前進(jìn)行的最后努力而觸發(fā)的GC。
實(shí)際上，GC_FOR_MALLOC、GC_CONCURRENT和GC_BEFORE_OOM三種類型的GC都是在分配對(duì)象的過程觸發(fā)的。
2.5 回收算法和內(nèi)存碎片
? ? ? ? 主流的大部分Davik采取的都是標(biāo)注與清理（Mark and Sweep）回收算法，也有實(shí)現(xiàn)了拷貝GC的，這一點(diǎn)和HotSpot是不一樣的，具體使用什么算法是在編譯期決定的，無法在運(yùn)行的時(shí)候動(dòng)態(tài)更換。如果在編譯dalvik虛擬機(jī)的命令中指明了"WITH_COPYING_GC"選項(xiàng)，則編譯"/dalvik/vm/alloc/Copying.cpp"源碼 – 此是Android中拷貝GC算法的實(shí)現(xiàn)，否則編譯"/dalvik/vm/alloc/HeapSource.cpp" – 其實(shí)現(xiàn)了標(biāo)注與清理GC算法。
? ? ? ? ?由于Mark and Sweep算法的缺點(diǎn)，容易導(dǎo)致內(nèi)存碎片，所以在這個(gè)算法下，當(dāng)我們有大量不連續(xù)小內(nèi)存的時(shí)候，再分配一個(gè)較大對(duì)象時(shí)，還是會(huì)非常容易導(dǎo)致GC，比如我們?cè)谠擏茸迨謾C(jī)上decode圖片，具體情況如下：
3、ART內(nèi)存回收機(jī)制
3.1 Java堆
? ? ? ? ART運(yùn)行時(shí)內(nèi)部使用的Java堆的主要組成包括Image Space、Zygote Space、Allocation Space和Large Object Space四個(gè)Space，Image Space用來存在一些預(yù)加載的類，?Zygote Space和Allocation Space與Dalvik虛擬機(jī)垃圾收集機(jī)制中的Zygote堆和Active堆的作用是一樣的，
? ? ? ? ?Large Object Space就是一些離散地址的集合，用來分配一些大對(duì)象從而提高了GC的管理效率和整體性能，類似如下圖：
? ? ? ? ? ?在下文的GC Log中，我們也能看到在art的GC Log中包含了LOS的信息，方便我們查看大內(nèi)存的情況。
3.2 GC的類型
kGcCauseForAlloc ，當(dāng)要分配內(nèi)存的時(shí)候發(fā)現(xiàn)內(nèi)存不夠的情況下引起的GC，這種情況下的GC會(huì)stop world
kGcCauseBackground，當(dāng)內(nèi)存達(dá)到一定的閥值的時(shí)候會(huì)去出發(fā)GC，這個(gè)時(shí)候是一個(gè)后臺(tái)gc，不會(huì)引起stop world
kGcCauseExplicit，顯示調(diào)用的時(shí)候進(jìn)行的gc，如果art打開了這個(gè)選項(xiàng)的情況下，在system.gc的時(shí)候會(huì)進(jìn)行g(shù)c
其他更多
3.2 并發(fā)和非并發(fā)GC
非并發(fā)GC
步驟1. 調(diào)用子類實(shí)現(xiàn)的成員函數(shù)InitializePhase執(zhí)行GC初始化階段。
步驟2. 掛起所有的ART運(yùn)行時(shí)線程。
步驟3. 調(diào)用子類實(shí)現(xiàn)的成員函數(shù)MarkingPhase執(zhí)行GC標(biāo)記階段。
步驟4. 調(diào)用子類實(shí)現(xiàn)的成員函數(shù)ReclaimPhase執(zhí)行GC回收階段。
步驟5. 恢復(fù)第2步掛起的ART運(yùn)行時(shí)線程。
步驟6. 調(diào)用子類實(shí)現(xiàn)的成員函數(shù)FinishPhase執(zhí)行GC結(jié)束階段。
并發(fā)GC
步驟1. 調(diào)用子類實(shí)現(xiàn)的成員函數(shù)InitializePhase執(zhí)行GC初始化階段。
步驟2. 獲取用于訪問Java堆的鎖。
步驟3. 調(diào)用子類實(shí)現(xiàn)的成員函數(shù)MarkingPhase執(zhí)行GC并行標(biāo)記階段。
步驟4. 釋放用于訪問Java堆的鎖。
步驟5. 掛起所有的ART運(yùn)行時(shí)線程。
步驟6. 調(diào)用子類實(shí)現(xiàn)的成員函數(shù)HandleDirtyObjectsPhase處理在GC并行標(biāo)記階段被修改的對(duì)象。。
步驟7. 恢復(fù)第4步掛起的ART運(yùn)行時(shí)線程。
步驟8. 重復(fù)第5到第7步，直到所有在GC并行階段被修改的對(duì)象都處理完成。
步驟9. 獲取用于訪問Java堆的鎖。
步驟10. 調(diào)用子類實(shí)現(xiàn)的成員函數(shù)ReclaimPhase執(zhí)行GC回收階段。
步驟11. 釋放用于訪問Java堆的鎖。
步驟12. 調(diào)用子類實(shí)現(xiàn)的成員函數(shù)FinishPhase執(zhí)行GC結(jié)束階段。
所以不論是并發(fā)還是非并發(fā)，都會(huì)引起stopworld的情況出現(xiàn)，并發(fā)的情況下單次stopworld的時(shí)間會(huì)更短。
3.4 并發(fā)GC的優(yōu)勢(shì)
可以通過如下2張圖來對(duì)比下并發(fā)GC和非并發(fā)GC
非并發(fā)GC：
并發(fā)GC
3.5 前后臺(tái)GC
? ? ? ? 前臺(tái)Foreground指的就是應(yīng)用程序在前臺(tái)運(yùn)行時(shí)，而后臺(tái)Background就是應(yīng)用程序在后臺(tái)運(yùn)行時(shí)。因此，F(xiàn)oreground GC就是應(yīng)用程序在前臺(tái)運(yùn)行時(shí)執(zhí)行的GC，而Background就是應(yīng)用程序在后臺(tái)運(yùn)行時(shí)執(zhí)行的GC。
? ? ? ? ?應(yīng)用程序在前臺(tái)運(yùn)行時(shí)，響應(yīng)性是最重要的，因此也要求執(zhí)行的GC是高效的。相反，應(yīng)用程序在后臺(tái)運(yùn)行時(shí)，響應(yīng)性不是最重要的，這時(shí)候就適合用來解決堆的內(nèi)存碎片問題。因此，Mark-Sweep GC適合作為Foreground GC，而Mark-Compact GC適合作為Background GC。
3.6 Art大法好
? ? ? ? 總的來看，art在gc上做的比dalvik好太多了，不光是gc的效率，減少pause時(shí)間，而且還在內(nèi)存分配上對(duì)大內(nèi)存的有單獨(dú)的分配區(qū)域，同時(shí)還能有算法在后臺(tái)做內(nèi)存整理，減少內(nèi)存碎片。對(duì)于開發(fā)者來說art下我們基本可以避免很多類似gc導(dǎo)致的卡頓問題了。另外根據(jù)谷歌自己的數(shù)據(jù)來看，Art相對(duì)Dalvik內(nèi)存分配的效率提高了10倍，GC的效率提高了2-3倍。
4、GC Log
? ? ? ? 當(dāng)我們想要根據(jù)GC日志來追查一些GC可能造成的卡頓時(shí)，我們需要了解GC日志的組成，不同信息代表了什么含義。
4.1 Dalvik GC日志
? ? ? ? ?dalvik的日志格式基本如下：
gc_reason：就是我們上文提到的，是gc_alloc還是gc_concurrent，了解到不同的原因方便我們做不同的處理。
amount_freed：表示系統(tǒng)通過這次GC操作釋放了多少內(nèi)存
Heap_stats：中會(huì)顯示當(dāng)前內(nèi)存的空閑比例以及使用情況（活動(dòng)對(duì)象所占內(nèi)存 / 當(dāng)前程序總內(nèi)存）
Pause_time：表示這次GC操作導(dǎo)致應(yīng)用程序暫停的時(shí)間。關(guān)于這個(gè)暫停的時(shí)間，在2.3之前GC操作是不能并發(fā)進(jìn)行的，也就是系統(tǒng)正在進(jìn)行GC，那么應(yīng)用程序就只能阻塞住等待GC結(jié)束。而自2.3之后，GC操作改成了并發(fā)的方式進(jìn)行，就是說GC的過程中不會(huì)影響到應(yīng)用程序的正常運(yùn)行，但是在GC操作的開始和結(jié)束的時(shí)候會(huì)短暫阻塞一段時(shí)間，所以還有后續(xù)的一個(gè)total_time。
Total_time:表示本次GC所花費(fèi)的總時(shí)間和上面的Pause_time,也就是stop all是不一樣的，卡頓時(shí)間主要看上面的pause_time。
4.2 Art GC日志
? ? ? ?基本情況和Dalvik沒有什么差別，GC的Reason更多了，還多了一個(gè)OS_Space_Status
LOS_Space_Status：Large Object Space，大對(duì)象占用的空間，這部分內(nèi)存并不是分配在堆上的，但仍屬于應(yīng)用程序內(nèi)存空間，主要用來管理 bitmap 等占內(nèi)存大的對(duì)象，避免因分配大內(nèi)存導(dǎo)致堆頻繁 GC。
