【正文】 運(yùn)行時(shí)線程。 weak_reference_list_ = nullptr。 class_count_ = 0。 work_chunks_deleted_ = 0。 MarkSweep類的成員函數(shù)InitializePhase主要就是重置一下接下來GC要用到的一些成員變量，其中，比較重要的就是調(diào)用另外一個(gè)成員函數(shù)FindDefaultMarkBitmap獲取一個(gè)Default Mark Bitmap，它的實(shí)現(xiàn)如下所示：[cpp] view plain copy 在CODE上查看代碼片派生到我的代碼片void MarkSweep::FindDefaultMarkBitmap() { base::TimingLogger::ScopedSplit split(FindDefaultMarkBitmap, amp。從前面一文可以知道，這個(gè)Space就是Allocation Space（如果Allocation Space還沒有從Zygote Space劃分出來，那就是Zygote Space）。 // Need to do this before the checkpoint since we don39。 MarkConcurrentRoots()。 D. 調(diào)用Heap類的成員函數(shù)SwapStacks交換ART運(yùn)行時(shí)的Allocation Stack和Live Stack。 J. 調(diào)用成員函數(shù)MarkReachableObjects遞歸標(biāo)記那些可以從根集對象到達(dá)的其它對象。 } } ()。 // Find out if the previous space is immune. for (space::ContinuousSpace* cur_space : GetHeap()GetContinuousSpaces()) { if (cur_space == space) { break。 } } } 這個(gè)函數(shù)定義在文件art/runtime/gc/collector/。 另一方面，如果之前沒有Space也被設(shè)置過不進(jìn)行回收，那么MarkSweep類的成員函數(shù)ImmuneSpace就會(huì)將參數(shù)space描述的Space占用的內(nèi)存區(qū)域的開始位置和結(jié)束位置記錄在MarkSweep類的成員變量immune_begin_ 和immune_end_中，以便 后面可以調(diào)用MarkSweep類的成員函數(shù)IsImmune判斷一個(gè)對象是否位于非回收Space中。 immune_end_ = reinterpret_castObject*(prev_spaceEnd())) { immune_begin_ = std::min(reinterpret_castObject*(spaceBegin()), immune_begin_)。 SetImmuneRange(reinterpret_castObject*(spaceBegin()), reinterpret_castObject*(spaceEnd()))。 // Mark all of the spaces we never collect as immune. for (const autoamp。 H. 調(diào)用成員函數(shù)MarkConcurrentRoots標(biāo)記那些可以在沒有獲得Locks類的靜態(tài)成員變量mutator_lock_描述的讀寫鎖的情況下訪問的根集對象。這個(gè)函數(shù)我們在前面已經(jīng)分析過了。 // At this point the live stack should no longer have any mutators which push into it. MarkNonThreadRoots()。 FindDefaultMarkBitmap()。 } } ...... } 這個(gè)函數(shù)定義在文件art/runtime/gc/collector/。 heap_PreGcVerification(this)。 overhead_time_ = 0。 freed_objects_ = 0。 SetImmuneRange(nullptr, nullptr)。 } // Broadcast a notification to all suspended threads, some or all of // which may choose to wake up. No need to wait for them. ...... Thread::resume_cond_Broadcast(self)。 2. ART運(yùn)行時(shí)線程的恢復(fù) 理解了ART運(yùn)行時(shí)線程的掛起過程之后，再理解它們的恢復(fù)狀態(tài)就容易多了，這是通過調(diào)用ThreadList類的成員函數(shù)ResumeAll實(shí)現(xiàn)的，如下所示：[cpp] view plain copy 在CODE上查看代碼片派生到我的代碼片void ThreadList::ResumeAll() { Thread* self = Thread::Current()。如果有的話，就在Thread類的靜態(tài)成員變量resume_cond_描述的一個(gè)條件變量上進(jìn)行等待，直到被其它線程喚醒為止。 = kRunnable。 old_state_and_flags = state_and_flags_。 設(shè)置好線程新的標(biāo)記位和狀態(tài)之后，Thread類的成員函數(shù)TransitionFromRunnableToSuspended再檢查線程原來的標(biāo)記位kCheckpointRequest是否等于1。) != 0))。接下來我們就繼續(xù)分析它們是怎么實(shí)現(xiàn)的。此外，函數(shù)CheckSuspend還會(huì)檢查線程內(nèi)部的另外一個(gè)標(biāo)記位kCheckpointRequest是否被設(shè)置為1。 函數(shù)CheckSuspendFromCode調(diào)用另外一個(gè)函數(shù)CheckSuspend檢查當(dāng)前線程是否需要掛起，后者的實(shí)現(xiàn)如下所示：[cpp] view plain copy 在CODE上查看代碼片派生到我的代碼片static inline void CheckSuspend(Thread* thread) SHARED_LOCKS_REQUIRED(Locks::mutator_lock_) { for (。否則的話，就調(diào)用成員函數(shù)AtomicSetFlag將成員變量state_and_flags_的int值的kSuspendRequest位置1，表示線程有掛起請求。 } void Thread::AtomicClearFlag(ThreadFlag flag) { android_atomic_and(1 ^ flag, amp。 } else Locks::mutator_lock_ExclusiveLock(self)。 ...... { MutexLock mu(self, *Locks::thread_list_lock_)。如果不對這些對象進(jìn)行重新標(biāo)記的話，那么就會(huì)導(dǎo)致它們被GC回收，造成錯(cuò)誤。 7. 恢復(fù)第4步掛起的ART運(yùn)行時(shí)線程。 5. 恢復(fù)第2步掛起的ART運(yùn)行時(shí)線程。 duration_ns_ = end_time start_time。 uint64_t pause_end = NanoTime()。 } bool done = false。 ReclaimPhase()。 uint64_t start_time = NanoTime()。 4. 找到合適的垃圾收集器之后，就將參數(shù)clear_soft_references的值保存它的成員變量clear_soft_references_中，以便可以告訴它要不要回收被軟引用對象引用的對象，然后再調(diào)用它的成員函數(shù)Run來執(zhí)行GC。注意，在當(dāng)前GC執(zhí)行之前，Heap類的成員變量is_gc_running_會(huì)被設(shè)置為true。 is_gc_running_ = false。 for (const autoamp。 while (!start_collect) { { MutexLock mu(self, *gc_plete_lock_)。 } 這個(gè)函數(shù)定義在文件art/runtime/gc/。 } } 這個(gè)函數(shù)定義在文件art/runtime/gc/。一旦檢測那些重定了成員函數(shù)finalize的對象在執(zhí)行成員函數(shù)finalize時(shí)超出一定的時(shí)候，那么就會(huì)退出VM。我們知道，在創(chuàng)建引用對象的時(shí)候，可以關(guān)聯(lián)一個(gè)隊(duì)列。 最后。 CHECK(!envExceptionCheck())。 } { MutexLock mu(self, *Locks::runtime_shutdown_lock_)。本文就詳細(xì)分析ART運(yùn)行時(shí)的垃圾收集過程。這樣就可以使得每次執(zhí)行GC時(shí)，可以最大限度地減少應(yīng)用程序停頓。 if (runtime == NULL || !runtimeIsFinishedStarting() || !runtimeIsConcurrentGcEnabled()) { return。 envCallStaticVoidMethod(WellKnownClasses::java_lang_Daemons, WellKnownClasses::java_lang_Daemons_requestGC)。 上述4個(gè)條件都滿足之后，Heap類的成員函數(shù)RequestConcurrentGC就將成員變量concurrent_start_bytes_的值設(shè)置為類型size_t的最大值，表示目前正有一個(gè)并行GC在等待執(zhí)行，以阻止觸發(fā)另外一個(gè)并行GC。 這五個(gè)守護(hù)線程分別是： 1. ReferenceQueueDaemon：引用隊(duì)列守護(hù)線程。用來監(jiān)控FinalizerDaemon線程的執(zhí)行。 } } // Wait for any GCs currently running to finish. if (WaitForConcurrentGcToComplete(self) == collector::kGcTypeNone) { CollectGarbageInternal(next_gc_type_, kGcCauseBackground, false)。 CollectGarbageInternal(collector::kGcTypeFull, kGcCauseExplicit, clear_soft_references)。 ...... // Ensure there is only one GC at a time. bool start_collect = false。 } ...... collector::MarkSweep* collector = NULL。 ...... { MutexLock mu(self, *gc_plete_lock_)。當(dāng)它的值等于true時(shí)，就表示在其它線程正在執(zhí)行GC，這時(shí)候就要調(diào)用Heap類的成員函數(shù)WaitForConcurrentGcToComplete等待其執(zhí)行完成。這里說的合適的垃圾收集器，是指并行性與Heap類的成員變量concurrent_gc_一致，并且類型也與參數(shù)gc_type一致的垃圾收集器。從前面一文可以知道，所有的垃圾收集器都是從GarbageCollector類繼承下來的，因此上面的第四步實(shí)際上執(zhí)行的是GarbageCollector類的成員函數(shù)Run，它的實(shí)現(xiàn)如下所示：[cpp] view plain copy 在CODE上查看代碼片派生到我的代碼片void GarbageCollector::Run() { ThreadList* thread_list = Runtime::Current()GetThreadList()。 MarkingPhase()。 MarkingPhase()。 ATRACE_END()。 } } uint64_t end_time = NanoTime()。 4. 調(diào)用子類實(shí)現(xiàn)的成員函數(shù)ReclaimPhase執(zhí)行GC回收階段。 6. 調(diào)用子類實(shí)現(xiàn)的成員函數(shù)HandleDirtyObjectsPhase處理在GC并行標(biāo)記階段被修改的對象。 2. 并行GC的標(biāo)記階段只鎖住了J