【正文】 gs = state_and_flags_。 int16_t old_state = 。 ...... do { ...... old_state_and_flags = state_and_flags_。 ...... if (UNLIKELY(( amp。 kSuspendRequest) != 0)) { // Wait while our suspend count is nonzero. MutexLock mu(this, *Locks::thread_suspend_count_lock_)。 old_state_and_flags = state_and_flags_。 ...... while (( amp。 kSuspendRequest) != 0) { // Recheck when Thread::resume_cond_ is notified. Thread::resume_cond_Wait(this)。 old_state_and_flags = state_and_flags_。 ...... } ...... } // Reacquire shared mutator_lock_ access. Locks::mutator_lock_SharedLock(this)。 // Atomically change from suspended to runnable if no suspend request pending. old_state_and_flags = state_and_flags_。 ...... if (LIKELY(( amp。 kSuspendRequest) == 0)) { union StateAndFlags new_state_and_flags = old_state_and_flags。 = kRunnable。 // CAS the value without a memory barrier, that occurred in the lock above. done = android_atomic_cas(, , amp。) == 0。 } if (UNLIKELY(!done)) { // Failed to transition to Runnable. Release shared mutator_lock_ access and try again. Locks::mutator_lock_SharedUnlock(this)。 } } while (UNLIKELY(!done))。 return static_castThreadState(old_state)。 } 這個函數(shù)定義在文件art/runtime/。 Thread類的成員函數(shù)TransitionFromSuspendedToRunnable的實現(xiàn)很簡單，它通過一個do...while循環(huán)不斷地判斷自己是否有一個掛起請求。如果有的話，就在Thread類的靜態(tài)成員變量resume_cond_描述的一個條件變量上進(jìn)行等待，直到被其它線程喚醒為止。被喚醒之后，又在獲取Locks類的靜態(tài)成員變量mutator_lock_描述的一個讀寫鎖的讀訪問的前提下，將自己的狀態(tài)設(shè)置為運行狀態(tài)，即kRunnable。如果設(shè)置成功，就結(jié)束執(zhí)行do...while循環(huán)。否則的話，就說明又可能有其它線程請求將自己掛起，因此Thread類的成員函數(shù)TransitionFromSuspendedToRunnable又需要釋放之前獲得的讀寫鎖的讀訪問，然后再重新執(zhí)行一遍do...while循環(huán)。 Thread類的成員函數(shù)TransitionFromRunnableToSuspended和TransitionFromSuspendedToRunnable均是在獲得Locks類的靜態(tài)成員變量mutator_lock_描述的讀寫鎖的讀訪問的前提下執(zhí)行的。假設(shè)執(zhí)行GC的線程在調(diào)用ThreadList類的成員函數(shù)SuspendAll獲得Locks類的靜態(tài)成員變量mutator_lock_描述的讀寫鎖的寫訪問之前，當(dāng)前線程還沒有獲得該讀寫鎖的讀訪問，那么很明顯當(dāng)它要獲得讀訪問時，就會進(jìn)入等待狀態(tài)，因為讀寫鎖的讀訪問和寫訪問是互斥的。 另一方面，如果執(zhí)行GC的線程在調(diào)用ThreadList類的成員函數(shù)SuspendAll獲得Locks類的靜態(tài)成員變量mutator_lock_描述的讀寫鎖的寫訪問之前，當(dāng)前線程已經(jīng)獲得了該讀寫鎖的讀訪問，那么隨后它就會調(diào)用Thread類的成員函數(shù)TransitionFromRunnableToSuspended釋放對該讀寫鎖的讀訪問，因此GC線程就可以獲得該讀寫鎖的寫訪問。等到當(dāng)前線程再調(diào)用Thread類的成員函數(shù)TransitionFromSuspendedToRunnable獲得該讀寫鎖的讀訪問時，就會進(jìn)入等待狀態(tài)了。 2. ART運行時線程的恢復(fù) 理解了ART運行時線程的掛起過程之后，再理解它們的恢復(fù)狀態(tài)就容易多了，這是通過調(diào)用ThreadList類的成員函數(shù)ResumeAll實現(xiàn)的，如下所示：[cpp] view plain copy 在CODE上查看代碼片派生到我的代碼片void ThreadList::ResumeAll() { Thread* self = Thread::Current()。 ...... Locks::mutator_lock_ExclusiveUnlock(self)。 { MutexLock mu(self, *Locks::thread_list_lock_)。 MutexLock mu2(self, *Locks::thread_suspend_count_lock_)。 // Update global suspend all state for attaching threads. suspend_all_count_。 // Decrement the suspend counts for all threads. for (const autoamp。 thread : list_) { if (thread == self) { continue。 } threadModifySuspendCount(self, 1, false)。 } // 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)。 } ...... } 這個函數(shù)定義在文件art/runtime/。 ThreadList類的成員函數(shù)ResumeAll所做的事情剛好與成員函數(shù)SuspendAll相反，它首先是釋放Locks類的靜態(tài)成員函數(shù)mutator_lock_描述的讀寫鎖的寫訪問，接著再減少ART運行時線程全局掛起計數(shù)器以及每一個ART運行時線程內(nèi)部的掛起計數(shù)器，最再喚醒等待在Thread類的靜態(tài)成員變量resume_cond_描述的一個條件變量上的其它ART運行時線程。 3. InitializePhase MarkSweep、PartialMarkSweep和StickyMarkSweep三個類的初始化階段都是相同的，都是由MarkSweep類的成員函數(shù)InitializePhase來實現(xiàn)，如下所示：[cpp] view plain copy 在CODE上查看代碼片派生到我的代碼片void MarkSweep::InitializePhase() { ()。 base::TimingLogger::ScopedSplit split(InitializePhase, amp。timings_)。 mark_stack_ = heap_()。 DCHECK(mark_stack_ != nullptr)。 SetImmuneRange(nullptr, nullptr)。 soft_reference_list_ = nullptr。 weak_reference_list_ = nullptr。 finalizer_reference_list_ = nullptr。 phantom_reference_list_ = nullptr。 cleared_reference_list_ = nullptr。 freed_bytes_ = 0。 freed_large_object_bytes_ = 0。 freed_objects_ = 0。 freed_large_objects_ = 0。 class_count_ = 0。 array_count_ = 0。 other_count_ = 0。 large_object_test_ = 0。 large_object_mark_ = 0。 classes_marked_ = 0。 overhead_time_ = 0。 work_chunks_created_ = 0。 work_chunks_deleted_ = 0。 reference_count_ = 0。 java_lang_Class_ = Class::GetJavaLangClass()。 CHECK(java_lang_Class_ != nullptr)。 FindDefaultMarkBitmap()。 // Do any pre GC verification. (PreGcVerification)。 heap_PreGcVerification(this)。 } 這個函數(shù)定義在文件art/runtime/gc/collector/。 MarkSweep類的成員函數(shù)InitializePhase主要就是重置一下接下來GC要用到的一些成員變量，其中，比較重要的就是調(diào)用另外一個成員函數(shù)FindDefaultMarkBitmap獲取一個Default Mark Bitmap，它的實現(xiàn)如下所示：[cpp] view plain copy 在CODE上查看代碼片派生到我的代碼片void MarkSweep::FindDefaultMarkBitmap() { base::TimingLogger::ScopedSplit split(FindDefaultMarkBitmap, amp。timings_)。 for (const autoamp。 space : GetHeap()GetContinuousSpaces()) { if (spaceGetGcRetentionPolicy() == space::kGcRetentionPolicyAlwaysCollect) { current_mark_bitmap_ = spaceGetMarkBitmap()。 CHECK(current_mark_bitmap_ != NULL)。 return。 } } ...... } 這個函數(shù)定義在文件art/runtime/gc/collector/。 從這里的就可以看出，Default Mark Bitmap就是回收策略為kGcRetentionPolicyAlwaysCollect的Space對應(yīng)的Mark Bitmap。從前面一文可以知道，這個Space就是Allocation Space（如果Allocation Space還沒有從Zygote Space劃分出來，那就是Zygote Space）。 獲得的Default Mark Bitmap保存在MarkSweep類的成員變量current_mark_bitmap_中。 4. MarkingPhase MarkSweep、PartialMarkSweep和StickyMarkSweep三個類的標(biāo)記階段都是以MarkSweep類的成員函數(shù)MarkingPhase為入口，它的實現(xiàn)如下所示：[cpp] view plain copy 在CODE上查看代碼片派生到我的代碼片