罗升阳
罗升阳

ART运行时垃圾收集（GC）过程分析

  ART运行时与Dalvik虚拟机一样，都使用了Mark-Sweep算法进行垃圾回收，因此它们的垃圾回收流程在总体上是一致的。但是ART运行时对堆的划分更加细致，因而在此基础上实现了更多样的回收策略。不同的策略有不同的回收力度，力度越大的回收策略，每次回收的内存就越多，并且它们都有各自的使用情景。这样就可以使得每次执行GC时，可以最大限度地减少应用程序停顿。本文就详细分析ART运行时的垃圾收集过程。

老罗的新浪微博：http://weibo.com/shengyangluo，欢迎关注！

        ART运行时的垃圾收集收集过程如图1所示：

ART运行时垃圾收集（GC）过程分析_第1张图片

图1 ART运行时的GC执行流程

        图1的最上面三个箭头描述触发GC的三种情况，左边的流程图描述非并行GC的执行过程，右边的流程图描述并行GC的执行流程，接下来我们就详细图中涉及到的所有细节。

        在前面ART运行时为新创建对象分配内存的过程分析一文中，我们提到了两种可能会触发GC的情况。第一种情况是没有足够内存分配请求的分存时，会调用Heap类的成员函数CollectGarbageInternal触发一个原因为kGcCauseForAlloc的GC。第二种情况下分配出请求的内存之后，堆剩下的内存超过一定的阀值，就会调用Heap类的成员函数RequestConcurrentGC请求执行一个并行GC。

        Heap类的成员函数RequestConcurrentGC的实现如下所示：

[cpp]  view plain copy
  1. void Heap::RequestConcurrentGC(Thread* self) {  
  2.   // Make sure that we can do a concurrent GC.  
  3.   Runtime* runtime = Runtime::Current();  
  4.   DCHECK(concurrent_gc_);  
  5.   if (runtime == NULL || !runtime->IsFinishedStarting() ||  
  6.       !runtime->IsConcurrentGcEnabled()) {  
  7.     return;  
  8.   }  
  9.   {  
  10.     MutexLock mu(self, *Locks::runtime_shutdown_lock_);  
  11.     if (runtime->IsShuttingDown()) {  
  12.       return;  
  13.     }  
  14.   }  
  15.   if (self->IsHandlingStackOverflow()) {  
  16.     return;  
  17.   }  
  18.   
  19.   // We already have a request pending, no reason to start more until we update  
  20.   // concurrent_start_bytes_.  
  21.   concurrent_start_bytes_ = std::numeric_limits<size_t>::max();  
  22.   
  23.   JNIEnv* env = self->GetJniEnv();  
  24.   DCHECK(WellKnownClasses::java_lang_Daemons != NULL);  
  25.   DCHECK(WellKnownClasses::java_lang_Daemons_requestGC != NULL);  
  26.   env->CallStaticVoidMethod(WellKnownClasses::java_lang_Daemons,  
  27.                             WellKnownClasses::java_lang_Daemons_requestGC);  
  28.   CHECK(!env->ExceptionCheck());  
  29. }  
       这个函数定义在文件art/runtime/gc/heap.cc。

       只有满足以下四个条件，Heap类的成员函数RequestConcurrentGC才会触发一个并行GC：

       1. ART运行时已经启动完毕。

       2. ART运行时支持并行GC。ART运行时默认是支持并行GC的，但是可以通过启动选项-Xgc来关闭。

       3. ART运行时不是正在关闭。

       4. 当前线程没有发生栈溢出。

       上述4个条件都满足之后，Heap类的成员函数RequestConcurrentGC就将成员变量concurrent_start_bytes_的值设置为类型size_t的最大值，表示目前正有一个并行GC在等待执行，以阻止触发另外一个并行GC。

       最后，Heap类的成员函数RequestConcurrentGC调用Java层的java.lang.Daemons类的静态成员函数requestGC请求执行一次并行GC。Java层的java.lang.Daemons类在加载的时候，会启动五个与堆或者GC相关的守护线程，如下所示：

[java]  view plain copy
  1. public final class Daemons {  
  2.     ......  
  3.   
  4.     public static void start() {  
  5.         ReferenceQueueDaemon.INSTANCE.start();  
  6.         FinalizerDaemon.INSTANCE.start();  
  7.         FinalizerWatchdogDaemon.INSTANCE.start();  
  8.         HeapTrimmerDaemon.INSTANCE.start();  
  9.         GCDaemon.INSTANCE.start();  
  10.     }  
  11.   
  12.     ......  
  13. }  
       这个类定义在文件libcore/libart/src/main/java/java/lang/Daemons.java中。

       这五个守护线程分别是：

       1. ReferenceQueueDaemon：引用队列守护线程。我们知道，在创建引用对象的时候，可以关联一个队列。当被引用对象引用的对象被GC回收的时候，被引用对象就会被加入到其创建时关联的队列去。这个加入队列的操作就是由ReferenceQueueDaemon守护线程来完成的。这样应用程序就可以知道那些被引用对象引用的对象已经被回收了。

       2. FinalizerDaemon：析构守护线程。对于重写了成员函数finalize的对象，它们被GC决定回收时，并没有马上被回收，而是被放入到一个队列中，等待FinalizerDaemon守护线程去调用它们的成员函数finalize，然后再被回收。

       3. FinalizerWatchdogDaemon：析构监护守护线程。用来监控FinalizerDaemon线程的执行。一旦检测那些重定了成员函数finalize的对象在执行成员函数finalize时超出一定的时候，那么就会退出VM。

       4. HeapTrimmerDaemon：堆裁剪守护线程。用来执行裁剪堆的操作，也就是用来将那些空闲的堆内存归还给系统。

       5. GCDaemon：并行GC线程。用来执行并行GC。

       Java层的java.lang.Daemons类的静态成员函数requestGC被调用时，就会唤醒上述的并行GC线程，然后这个并行GC线程就会通过JNI调用Heap类的成员函数ConcurrentGC，它的实现如下所示：

[cpp]  view plain copy
  1. void Heap::ConcurrentGC(Thread* self) {  
  2.   {  
  3.     MutexLock mu(self, *Locks::runtime_shutdown_lock_);  
  4.     if (Runtime::Current()->IsShuttingDown()) {  
  5.       return;  
  6.     }  
  7.   }  
  8.   
  9.   // Wait for any GCs currently running to finish.  
  10.   if (WaitForConcurrentGcToComplete(self) == collector::kGcTypeNone) {  
  11.     CollectGarbageInternal(next_gc_type_, kGcCauseBackground, false);  
  12.   }  
  13. }  
        这个函数定义在文件art/runtime/gc/heap.cc中。

        只要ART运行时当前不是处于正在关闭的状态，那么Heap类的成员函数ConcurrentGC就会检查当前是否正在执行GC。如果是的话，那么就等待它执行完成，然后再调用Heap类的成员函数CollectGarbageInternal触发一个原因为kGcCauseBackground的GC。否则的话，就直接调用Heap类的成员函数CollectGarbageInternal触发一个原因为kGcCauseBackground的GC。

        从这里就可以看到，无论是触发GC的原因是kGcCauseForAlloc，还是kGcCauseBackground，最终都是通过调用Heap类的成员函数CollectGarbageInternal来执行GC的。此外，还有第三种情况会触发GC，如下所示：

[cpp]  view plain copy
  1. void Heap::CollectGarbage(bool clear_soft_references) {  
  2.   // Even if we waited for a GC we still need to do another GC since weaks allocated during the  
  3.   // last GC will not have necessarily been cleared.  
  4.   Thread* self = Thread::Current();  
  5.   WaitForConcurrentGcToComplete(self);  
  6.   CollectGarbageInternal(collector::kGcTypeFull, kGcCauseExplicit, clear_soft_references);  
  7. }  
        这个函数定义在文件art/runtime/gc/heap.cc。

        当我们调用Java层的java.lang.System的静态成员函数gc时，如果ART运行时支持显式GC，那么就它就会通过JNI调用Heap类的成员函数CollectGarbageInternal来触发一个原因为kGcCauseExplicit的GC。ART运行时默认是支持显式GC的，但是可以通过启动选项-XX:+DisableExplicitGC来关闭。

        从上面的分析就可以看出，ART运行时在三种情况下会触发GC，这三种情况通过三个枚举kGcCauseForAlloc、kGcCauseBackground和kGcCauseExplicitk来描述。这三人枚举的定义如下所示：

[cpp]  view plain copy
  1. // What caused the GC?  
  2. enum GcCause {  
  3.   // GC triggered by a failed allocation. Thread doing allocation is blocked waiting for GC before  
  4.   // retrying allocation.  
  5.   kGcCauseForAlloc,  
  6.   // A background GC trying to ensure there is free memory ahead of allocations.  
  7.   kGcCauseBackground,  
  8.   // An explicit System.gc() call.  
  9.   kGcCauseExplicit,  
  10. };  
       这三个枚举定义在文件art/runtime/gc/heap.h中。

       从上面的分析还可以看出，ART运行时的所有GC都是以Heap类的成员函数CollectGarbageInternal为入口，它的实现如下所示：

[cpp]  view plain copy
  1. collector::GcType Heap::CollectGarbageInternal(collector::GcType gc_type, GcCause gc_cause,  
  2.                                                bool clear_soft_references) {  
  3.   Thread* self = Thread::Current();  
  4.   ......  
  5.   
  6.   // Ensure there is only one GC at a time.  
  7.   bool start_collect = false;  
  8.   while (!start_collect) {  
  9.     {  
  10.       MutexLock mu(self, *gc_complete_lock_);  
  11.       if (!is_gc_running_) {  
  12.         is_gc_running_ = true;  
  13.         start_collect = true;  
  14.       }  
  15.     }  
  16.     if (!start_collect) {  
  17.       // TODO: timinglog this.  
  18.       WaitForConcurrentGcToComplete(self);  
  19.       ......  
  20.     }  
  21.   }  
  22.   
  23.   ......  
  24.   
  25.   if (gc_type == collector::kGcTypeSticky &&  
  26.       alloc_space_->Size() < min_alloc_space_size_for_sticky_gc_) {  
  27.     gc_type = collector::kGcTypePartial;  
  28.   }  
  29.   
  30.   ......  
  31.   
  32.   collector::MarkSweep* collector = NULL;  
  33.   for (const auto& cur_collector : mark_sweep_collectors_) {  
  34.     if (cur_collector->IsConcurrent() == concurrent_gc_ && cur_collector->GetGcType() == gc_type) {  
  35.       collector = cur_collector;  
  36.       break;  
  37.     }  
  38.   }  
  39.   ......  
  40.   
  41.   collector->clear_soft_references_ = clear_soft_references;  
  42.   collector->Run();  
  43.   ......  
  44.   
  45.   {  
  46.       MutexLock mu(self, *gc_complete_lock_);  
  47.       is_gc_running_ = false;  
  48.       last_gc_type_ = gc_type;  
  49.       // Wake anyone who may have been waiting for the GC to complete.  
  50.       gc_complete_cond_->Broadcast(self);  
  51.   }  
  52.   
  53.   ......  
  54.   
  55.   return gc_type;  
  56. }  
        这个函数定义在文件art/runtime/gc/heap.cc。

        参数gc_type和gc_cause分别用来描述要执行的GC的类型和原因，而参数clear_soft_references用来描述是否要回收被软引用对象引用的对象。

        Heap类的成员函数CollectGarbageInternal的执行逻辑如下所示：

        1. 通过一个while循环不断地检查Heap类的成员变量is_gc_running_，直到它的值等于false为止，这表示当前没有其它线程正在执行GC。当它的值等于true时，就表示在其它线程正在执行GC，这时候就要调用Heap类的成员函数WaitForConcurrentGcToComplete等待其执行完成。注意，在当前GC执行之前，Heap类的成员变量is_gc_running_会被设置为true。

        2. 如果当前请求执行的GC的类型为kGcTypeSticky，但是当前Allocation Space的大小小于Heap类的成员变量min_alloc_space_size_for_sticky_gc_指定的阀值，那么就改为执行类型为kGcTypePartial。关于类型为kGcTypeSticky的GC的执行限制，可以参数前面ART运行时为新创建对象分配内存的过程分析一文。

        3. 从Heap类的成员变量mark_sweep_collectors_指向的一个垃圾收集器列表找到一个合适的垃圾收集器来执行GC。从前面ART运行时Java堆创建过程分析一文可以知道，ART运行时在内部创建了六个垃圾收集器。这六个垃圾收集器分为两组，一组支持并行GC，另一组不支持。每一组都是由三个类型分别为kGcTypeSticky、kGcTypePartial和kGcTypeFull的垃垃圾收集器组成。这里说的合适的垃圾收集器，是指并行性与Heap类的成员变量concurrent_gc_一致，并且类型也与参数gc_type一致的垃圾收集器。

        4. 找到合适的垃圾收集器之后，就将参数clear_soft_references的值保存它的成员变量clear_soft_references_中，以便可以告诉它要不要回收被软引用对象引用的对象，然后再调用它的成员函数Run来执行GC。

        5. GC执行完毕，将Heap类的成员变量is_gc_running_设置为false，以表示当前GC已经执行完毕，下一次请求的GC可以执行了。此外，也会将Heap类的成员变量last_gc_type_设置为当前执行的GC的类型。这样下一次执行GC时，就可以执行另外一个不同类型的GC。例如，如果上一次执行的GC的类型为kGcTypeSticky，那么接下来的两次GC的类型就可以设置为kGcTypePartial和kGcTypeFull，这样可以使得每次都能执行有效的GC。

        6. 通过Heap类的成员变量gc_complete_cond_唤醒那些正在等待GC执行完成的线程。

        在上面的六个步骤中，最重要的就是第四步了。从前面ART运行时垃圾收集机制简要介绍和学习计划一文可以知道，所有的垃圾收集器都是从GarbageCollector类继承下来的，因此上面的第四步实际上执行的是GarbageCollector类的成员函数Run，它的实现如下所示：

[cpp]  view plain copy
  1. void GarbageCollector::Run() {  
  2.   ThreadList* thread_list = Runtime::Current()->GetThreadList();  
  3.   uint64_t start_time = NanoTime();  
  4.   pause_times_.clear();  
  5.   duration_ns_ = 0;  
  6.   
  7.   InitializePhase();  
  8.   
  9.   if (!IsConcurrent()) {  
  10.     // Pause is the entire length of the GC.  
  11.     uint64_t pause_start = NanoTime();  
  12.     ATRACE_BEGIN("Application threads suspended");  
  13.     thread_list->SuspendAll();  
  14.     MarkingPhase();  
  15.     ReclaimPhase();  
  16.     thread_list->ResumeAll();  
  17.     ATRACE_END();  
  18.     uint64_t pause_end = NanoTime();  
  19.     pause_times_.push_back(pause_end - pause_start);  
  20.   } else {  
  21.     Thread* self = Thread::Current();  
  22.     {  
  23.       ReaderMutexLock mu(self, *Locks::mutator_lock_);  
  24.       MarkingPhase();  
  25.     }  
  26.     bool done = false;  
  27.     while (!done) {  
  28.       uint64_t pause_start = NanoTime();  
  29.       ATRACE_BEGIN("Suspending mutator threads");  
  30.       thread_list->SuspendAll();  
  31.       ATRACE_END();  
  32.       ATRACE_BEGIN("All mutator threads suspended");  
  33.       done = HandleDirtyObjectsPhase();  
  34.       ATRACE_END();  
  35.       uint64_t pause_end = NanoTime();  
  36.       ATRACE_BEGIN("Resuming mutator threads");  
  37.       thread_list->ResumeAll();  
  38.       ATRACE_END();  
  39.       pause_times_.push_back(pause_end - pause_start);  
  40.     }  
  41.     {  
  42.       ReaderMutexLock mu(self, *Locks::mutator_lock_);  
  43.       ReclaimPhase();  
  44.     }  
  45.   }  
  46.   
  47.   uint64_t end_time = NanoTime();  
  48.   duration_ns_ = end_time - start_time;  
  49.   
  50.   FinishPhase();  
  51. }  
        这个函数定义在文件art/runtime/gc/collector/garbage_collector.cc中。

        GarbageCollector类的成员函数Run的实现就对应于图1所示的左边和右边的两个流程。

        图1所示的左边流程是用来执行非并行GC的，过程如下所示：

        1. 调用子类实现的成员函数InitializePhase执行GC初始化阶段。

        2. 挂起所有的ART运行时线程。

        3. 调用子类实现的成员函数MarkingPhase执行GC标记阶段。

        4. 调用子类实现的成员函数ReclaimPhase执行GC回收阶段。

        5. 恢复第2步挂起的ART运行时线程。

        6. 调用子类实现的成员函数FinishPhase执行GC结束阶段。

        图1所示的右边流程是用来执行并行GC的，过程如下所示：

        1. 调用子类实现的成员函数InitializePhase执行GC初始化阶段。

        2. 获取用于访问Java堆的锁。

        3. 调用子类实现的成员函数MarkingPhase执行GC并行标记阶段。

        4. 释放用于访问Java堆的锁。

        5. 挂起所有的ART运行时线程。

        6. 调用子类实现的成员函数HandleDirtyObjectsPhase处理在GC并行标记阶段被修改的对象。。

        7. 恢复第4步挂起的ART运行时线程。

        8. 重复第5到第7步，直到所有在GC并行阶段被修改的对象都处理完成。

        9. 获取用于访问Java堆的锁。

        10. 调用子类实现的成员函数ReclaimPhase执行GC回收阶段。

        11. 释放用于访问Java堆的锁。

        12. 调用子类实现的成员函数FinishPhase执行GC结束阶段。

        从上面的分析就可以看出，并行GC和非并行GC的区别在于：

        1. 非并行GC的标记阶段和回收阶段是在挂住所有的ART运行时线程的前提下进行的，因此，只需要执行一次标记即可。

        2. 并行GC的标记阶段只锁住了Java堆，因此它不能阻止那些不是正在分配对象的ART运行时线程同时运行，而这些同进运行的ART运行时线程可能会引用了一些在之前的标记阶段没有被标记的对象。如果不对这些对象进行重新标记的话，那么就会导致它们被GC回收，造成错误。因此，与非并行GC相比，并行GC多了一个处理脏对象的阶段。所谓的脏对象就是我们前面说的在GC标记阶段同时运行的ART运行时线程访问或者修改过的对象。

        3. 并行GC并不是自始至终都是并行的，例如，处理脏对象的阶段就是需要挂起除GC线程以外的其它ART运行时线程，这样才可以保证标记阶段可以结束。

        从前面ART运行时垃圾收集机制简要介绍和学习计划一文可以知道，GarbageCollector类有三个直接或者间接的子类MarkSweep、PartialMarkSweep和StickyMarkSweep都可以用来执行垃圾回收，其中，PartialMarkSweep类又是从MarkSweep类直接继承下来的，而StickyMarkSweep类是从PartialMarkSweep类直接继承下来的。MarkSweep类用来回收Zygote Space和Allocation Space的垃圾，PartialMarkSweep类用来回收Allocation Space的垃圾，StickyMarkSweep类用来回收上次GC以来在Allcation Space上分配的最终又没有被引用的垃圾。

        接下来，我们就主要分析ART运行时线程的挂起和恢复过程，以及MarkSweep、PartialMarkSweep和StickyMarkSweep这三个类是执行InitializePhase、MarkingPhase、HandleDirtyObjectsPhase、ReclaimPhase和FinishPhase的五个GC阶段的过程。

       1. ART运行时线程的挂起

       从上面的分析可以知道，ART运行时线程的挂起是通过调用ThreadList类的成员函数SuspendAll实现的，如下所示：

[cpp]  view plain copy
  1. void ThreadList::SuspendAll() {  
  2.   Thread* self = Thread::Current();  
  3.   ......  
  4.   
  5.   {  
  6.     MutexLock mu(self, *Locks::thread_list_lock_);  
  7.     {  
  8.       MutexLock mu2(self, *Locks::thread_suspend_count_lock_);  
  9.       // Update global suspend all state for attaching threads.  
  10.       ++suspend_all_count_;  
  11.       // Increment everybody's suspend count (except our own).  
  12.       for (const auto& thread : list_) {  
  13.         if (thread == self) {  
  14.           continue;  
  15.         }  
  16.         ......  
  17.         thread->ModifySuspendCount(self, +1, false);  
  18.       }  
  19.     }  
  20.   }  
  21.   
  22.   // Block on the mutator lock until all Runnable threads release their share of access.  
  23. #if HAVE_TIMED_RWLOCK  
  24.   // Timeout if we wait more than 30 seconds.  
  25.   if (UNLIKELY(!Locks::mutator_lock_->ExclusiveLockWithTimeout(self, 30 * 1000, 0))) {  
  26.     UnsafeLogFatalForThreadSuspendAllTimeout(self);  
  27.   }  
  28. #else  
  29.   Locks::mutator_lock_->ExclusiveLock(self);  
  30. #endif  
  31.   
  32.   ......  
  33. }  
       这个函数定义在文件art/runtime/thread_list.cc中。

       所有的ART运行时线程都保存在ThreadList类的成员变量list_描述的一个列表，遍历这个列表时，需要获取Lock类的成员变量thread_list_lock_描述的一个互斥锁。

       ThreadList类有一个成员变量suspend_all_count_，用来描述全局的线程挂起计数器。在所有的ART运行时线程挂起期间，如果有新的线程将自己注册为ART运行时线程，那么它也会将自己挂起来，而判断所有的ART运行时线程是不是处于挂起期间，就是通过ThreadList类的成员变量suspend_all_count_的值是否大于0进行的。因此，ThreadList类的成员函数SuspendAll在挂起所有的ART运行时线程之前，会将ThreadList类的成员变量suspend_all_count_的值增加1。

       接下来，ThreadList类的成员函数SuspendAll遍历所有的ART运行时线程，并且调用Thread类的成员函数ModifySuspendCount将它内部的线程计算数器增加1，如下所示：

[cpp]  view plain copy
  1. void Thread::AtomicSetFlag(ThreadFlag flag) {  
  2.   android_atomic_or(flag, &state_and_flags_.as_int);  
  3. }  
  4.   
  5. void Thread::AtomicClearFlag(ThreadFlag flag) {  
  6.   android_atomic_and(-1 ^ flag, &state_and_flags_.as_int);  
  7. }  
  8.   
  9. ......  
  10.   
  11. void Thread::ModifySuspendCount(Thread* self, int delta, bool for_debugger) {  
  12.   ......  
  13.   
  14.   suspend_count_ += delta;  
  15.   ......  
  16.   
  17.   if (suspend_count_ == 0) {  
  18.     AtomicClearFlag(kSuspendRequest);  
  19.   } else {  
  20.     AtomicSetFlag(kSuspendRequest);  
  21.   }  
  22. }  
       这三个函数定义在文件art/runtime/thread.cc中。

       Thread类的成员函数ModifySuspendCount的实现很简单，它主要就是将成员变量suspend_count_的值增加delta，并且判断增加后的值是否等于0。如果等于0，就调用成员函数AtomicClearFlag将另外一个成员变量state_and_flags_的int值的kSuspendRequest位清0，表示线程没有挂起请求。否则的话，就调用成员函数AtomicSetFlag将成员变量state_and_flags_的int值的kSuspendRequest位置1，表示线程有挂起请求。

       回到前面ThreadList类的成员函数SuspendAll中，全局ART运行时线程挂起计数器和每一个ART运行时线程内部的线程挂起计数器的操作都是需要在获取Locks类的静态成员变量thread_suspend_count_lock_描述的一个互斥锁的前提下进行的。

       最后，ThreadList类的成员函数SuspendAll通过获取Locks类的静态成员变量mutator_lock_描述的一个读写锁的写访问来等待所有的ART运行时线程挂起的。这是如何做到的呢？在前面Android运行时ART执行类方法的过程分析一文中，我们提到，ART运行时提供给由DEX字节码翻译而来的本地机器代码使用的一个函数表中，包含了一个pCheckSuspend函数指针，该函数指针指向了函数CheckSuspendFromCode。于是，每一个ART运行时线程在执行本地机器代码的过程中，就会周期性地通过调用函数CheckSuspendFromCode来检查自己是否需要挂起。这一点与前面Dalvik虚拟机垃圾收集（GC）过程分析一文分析的Dalvik虚拟机线程挂起的过程是类似的。

       函数CheckSuspendFromCode的实现如下所示：

[cpp]  view plain copy
  1. void CheckSuspendFromCode(Thread* thread)  
  2.     SHARED_LOCKS_REQUIRED(Locks::mutator_lock_) {  
  3.   ......  
  4.   CheckSuspend(thread);  
  5. }  
       这个函数定义在文件art/runtime/entrypoints/quick/quick_thread_entrypoints.cc中。

       函数CheckSuspendFromCode调用另外一个函数CheckSuspend检查当前线程是否需要挂起，后者的实现如下所示：

[cpp]  view plain copy
  1. static inline void CheckSuspend(Thread* thread) SHARED_LOCKS_REQUIRED(Locks::mutator_lock_) {  
  2.   for (;;) {  
  3.     if (thread->ReadFlag(kCheckpointRequest)) {  
  4.       thread->RunCheckpointFunction();  
  5.       thread->AtomicClearFlag(kCheckpointRequest);  
  6.     } else if (thread->ReadFlag(kSuspendRequest)) {  
  7.       thread->FullSuspendCheck();  
  8.     } else {  
  9.       break;  
  10.     }  
  11.   }  
  12. }  
       这个函数定义在文件art/runtime/entrypoints/entrypoint_utils.h中。

       从上面的分析可以知道，如果当前线程的线程挂起计数器不等于0，那么它内部的一个标记位kSuspendRequest被设置为1。这时候函数CheckSuspend就会调用Thread类的成员函数FullSuspendCheck来将自己挂起。此外，函数CheckSuspend还会检查线程内部的另外一个标记位kCheckpointRequest是否被设置为1。如果被设置为1的话，那么就说明线程有一个Check Point需要执行，这时候就会先调用Thread类的成员函数RunCheckpointFunction运行该Check Point，接着再将线程内部的标记位kCheckpointRequest清0。关于线程的Check Point，我们后面再分析。

       Thread类的成员函数FullSuspendCheck的实现如下所示：

[cpp]  view plain copy
  1. void Thread::FullSuspendCheck() {  
  2.   ......  
  3.   // Make thread appear suspended to other threads, release mutator_lock_.  
  4.   TransitionFromRunnableToSuspended(kSuspended);  
  5.   // Transition back to runnable noting requests to suspend, re-acquire share on mutator_lock_.  
  6.   TransitionFromSuspendedToRunnable();  
  7.   ......  
  8. }  
       这个函数定义在文件art/runtime/thread.cc中。

       Thread类的成员函数FullSuspendCheck首先是调用成员函数TransitionFromRunnableToSuspended将自己从运行状态修改为挂起状态，接着再调用成员函数TransitionFromSuspendedToRunnable将自己从挂起状态修改为运行状态。通过Thread类的这两个神奇的成员函数，就实现了将当前线程挂起的功能。接下来我们就继续分析它们是怎么实现的。

       Thread类的成员函数TransitionFromRunnableToSuspended的实现如下所示：

[cpp]  view plain copy
  1. inline void Thread::TransitionFromRunnableToSuspended(ThreadState new_state) {  
  2.   ......  
  3.   union StateAndFlags old_state_and_flags;  
  4.   union StateAndFlags new_state_and_flags;  
  5.   do {  
  6.     old_state_and_flags = state_and_flags_;  
  7.     // Copy over flags and try to clear the checkpoint bit if it is set.  
  8.     new_state_and_flags.as_struct.flags = old_state_and_flags.as_struct.flags & ~kCheckpointRequest;  
  9.     new_state_and_flags.as_struct.state = new_state;  
  10.     // CAS the value without a memory barrier, that will occur in the unlock below.  
  11.   } while (UNLIKELY(android_atomic_cas(old_state_and_flags.as_int, new_state_and_flags.as_int,  
  12.                                        &state_and_flags_.as_int) != 0));  
  13.   // If we toggled the checkpoint flag we must have cleared it.  
  14.   uint16_t flag_change = new_state_and_flags.as_struct.flags ^ old_state_and_flags.as_struct.flags;  
  15.   if (UNLIKELY((flag_change & kCheckpointRequest) != 0)) {  
  16.     RunCheckpointFunction();  
  17.   }  
  18.   // Release share on mutator_lock_.  
  19.   Locks::mutator_lock_->SharedUnlock(this);  
  20. }  
       这个函数定义在文件art/runtime/thread-inl.h中。

       线程的状态和标记位均保存在Thread类的成员变量state_and_flags_描述的一个Union结构体中。Thread类的成员函数TransitionFromRunnableToSuspended首先是将线程旧的状态和标志位保存起来，然后再清空它的kCheckpointRequest标志位，以及将它的状态设置为参数new_state描述的状态，即kSuspended状态。

       设置好线程新的标记位和状态之后，Thread类的成员函数TransitionFromRunnableToSuspended再检查线程原来的标记位kCheckpointRequest是否等于1。如果等于1的话，那么在释放Locks类的静态成员变量mutator_lock_描述的一个读写锁的读访问之前，先调用Thread类的成员函数RunCheckpointFunction来执行线程的Check Point。

        Thread类的成员函数TransitionFromSuspendedToRunnable的实现如下所示：

[cpp]  view plain copy
  1. inline ThreadState Thread::TransitionFromSuspendedToRunnable() {  
  2.   bool done = false;  
  3.   union StateAndFlags old_state_and_flags = state_and_flags_;  
  4.   int16_t old_state = old_state_and_flags.as_struct.state;  
  5.   ......  
  6.   do {  
  7.     ......  
  8.     old_state_and_flags = state_and_flags_;  
  9.     ......  
  10.     if (UNLIKELY((old_state_and_flags.as_struct.flags & kSuspendRequest) != 0)) {  
  11.       // Wait while our suspend count is non-zero.  
  12.       MutexLock mu(this, *Locks::thread_suspend_count_lock_);  
  13.       old_state_and_flags = state_and_flags_;  
  14.       ......  
  15.       while ((old_state_and_flags.as_struct.flags & kSuspendRequest) != 0) {  
  16.         // Re-check when Thread::resume_cond_ is notified.  
  17.         Thread::resume_cond_->Wait(this);  
  18.         old_state_and_flags = state_and_flags_;  
  19.         ......  
  20.       }  
  21.       ......  
  22.     }  
  23.     // Re-acquire shared mutator_lock_ access.  
  24.     Locks::mutator_lock_->SharedLock(this);  
  25.     // Atomically change from suspended to runnable if no suspend request pending.  
  26.     old_state_and_flags = state_and_flags_;  
  27.     ......  
  28.     if (LIKELY((old_state_and_flags.as_struct.flags & kSuspendRequest) == 0)) {  
  29.       union StateAndFlags new_state_and_flags = old_state_and_flags;  
  30.       new_state_and_flags.as_struct.state = kRunnable;  
  31.       // CAS the value without a memory barrier, that occurred in the lock above.  
  32.       done = android_atomic_cas(old_state_and_flags.as_int, new_state_and_flags.as_int,  
  33.                                 &state_and_flags_.as_int) == 0;  
  34.     }  
  35.     if (UNLIKELY(!done)) {  
  36.       // Failed to transition to Runnable. Release shared mutator_lock_ access and try again.  
  37.       Locks::mutator_lock_->SharedUnlock(this);  
  38.     }  
  39.   } while (UNLIKELY(!done));  
  40.   return static_cast(old_state);  
  41. }  
       这个函数定义在文件art/runtime/thread-inl.h中。

       Thread类的成员函数TransitionFromSuspendedToRunnable的实现很简单，它通过一个do...while循环不断地判断自己是否有一个挂起请求。如果有的话，就在Thread类的静态成员变量resume_cond_描述的一个条件变量上进行等待，直到被其它线程唤醒为止。被唤醒之后，又在获取Locks类的静态成员变量mutator_lock_描述的一个读写锁的读访问的前提下，将自己的状态设置为运行状态，即kRunnable。如果设置成功，就结束执行do...while循环。否则的话，就说明又可能有其它线程请求将自己挂起，因此Thread类的成员函数TransitionFromSuspendedToRunnable又需要释放之前获得的读写锁的读访问，然后再重新执行一遍do...while循环。

       Thread类的成员函数TransitionFromRunnableToSuspended和TransitionFromSuspendedToRunnable均是在获得Locks类的静态成员变量mutator_lock_描述的读写锁的读访问的前提下执行的。假设执行GC的线程在调用ThreadList类的成员函数SuspendAll获得Locks类的静态成员变量mutator_lock_描述的读写锁的写访问之前，当前线程还没有获得该读写锁的读访问，那么很明显当它要获得读访问时，就会进入等待状态，因为读写锁的读访问和写访问是互斥的。

       另一方面，如果执行GC的线程在调用ThreadList类的成员函数SuspendAll获得Locks类的静态成员变量mutator_lock_描述的读写锁的写访问之前，当前线程已经获得了该读写锁的读访问，那么随后它就会调用Thread类的成员函数TransitionFromRunnableToSuspended释放对该读写锁的读访问，因此GC线程就可以获得该读写锁的写访问。等到当前线程再调用Thread类的成员函数TransitionFromSuspendedToRunnable获得该读写锁的读访问时，就会进入等待状态了。

       2. ART运行时线程的恢复

       理解了ART运行时线程的挂起过程之后，再理解它们的恢复状态就容易多了，这是通过调用ThreadList类的成员函数ResumeAll实现的，如下所示：

[cpp]  view plain copy
  1. void ThreadList::ResumeAll() {  
  2.   Thread* self = Thread::Current();  
  3.   ......  
  4.   
  5.   Locks::mutator_lock_->ExclusiveUnlock(self);  
  6.   {  
  7.     MutexLock mu(self, *Locks::thread_list_lock_);  
  8.     MutexLock mu2(self, *Locks::thread_suspend_count_lock_);  
  9.     // Update global suspend all state for attaching threads.  
  10.     --suspend_all_count_;  
  11.     // Decrement the suspend counts for all threads.  
  12.     for (const auto& thread : list_) {  
  13.       if (thread == self) {  
  14.         continue;  
  15.       }  
  16.       thread->ModifySuspendCount(self, -1, false);  
  17.     }  
  18.   
  19.     // Broadcast a notification to all suspended threads, some or all of  
  20.     // which may choose to wake up.  No need to wait for them.  
  21.     ......  
  22.     Thread::resume_cond_->Broadcast(self);  
  23.   }  
  24.   ......  
  25. }  
       这个函数定义在文件art/runtime/thread_list.cc中。

       ThreadList类的成员函数ResumeAll所做的事情刚好与成员函数SuspendAll相反，它首先是释放Locks类的静态成员函数mutator_lock_描述的读写锁的写访问，接着再减少ART运行时线程全局挂起计数器以及每一个ART运行时线程内部的挂起计数器，最再唤醒等待在Thread类的静态成员变量resume_cond_描述的一个条件变量上的其它ART运行时线程。

       3. InitializePhase

       MarkSweep、PartialMarkSweep和StickyMarkSweep三个类的初始化阶段都是相同的，都是由MarkSweep类的成员函数InitializePhase来实现，如下所示：

[cpp]  view plain copy
  1. void MarkSweep::InitializePhase() {  
  2.   timings_.Reset();  
  3.   base::TimingLogger::ScopedSplit split("InitializePhase", &timings_);  
  4.   mark_stack_ = heap_->mark_stack_.get();  
  5.   DCHECK(mark_stack_ != nullptr);  
  6.   SetImmuneRange(nullptr, nullptr);  
  7.   soft_reference_list_ = nullptr;  
  8.   weak_reference_list_ = nullptr;  
  9.   finalizer_reference_list_ = nullptr;  
  10.   phantom_reference_list_ = nullptr;  
  11.   cleared_reference_list_ = nullptr;  
  12.   freed_bytes_ = 0;  
  13.   freed_large_object_bytes_ = 0;  
  14.   freed_objects_ = 0;  
  15.   freed_large_objects_ = 0;  
  16.   class_count_ = 0;  
  17.   array_count_ = 0;  
  18.   other_count_ = 0;  
  19.   large_object_test_ = 0;  
  20.   large_object_mark_ = 0;  
  21.   classes_marked_ = 0;  
  22.   overhead_time_ = 0;  
  23.   work_chunks_created_ = 0;  
  24.   work_chunks_deleted_ = 0;  
  25.   reference_count_ = 0;  
  26.   java_lang_Class_ = Class::GetJavaLangClass();  
  27.   CHECK(java_lang_Class_ != nullptr);  
  28.   
  29.   FindDefaultMarkBitmap();  
  30.   
  31.   // Do any pre GC verification.  
  32.   timings_.NewSplit("PreGcVerification");  
  33.   heap_->PreGcVerification(this);  
  34. }  
       这个函数定义在文件art/runtime/gc/collector/mark_sweep.cc中。

       MarkSweep类的成员函数InitializePhase主要就是重置一下接下来GC要用到的一些成员变量，其中，比较重要的就是调用另外一个成员函数FindDefaultMarkBitmap获取一个Default Mark Bitmap，它的实现如下所示：

[cpp]  view plain copy
  1. void MarkSweep::FindDefaultMarkBitmap() {  
  2.   base::TimingLogger::ScopedSplit split("FindDefaultMarkBitmap", &timings_);  
  3.   for (const auto& space : GetHeap()->GetContinuousSpaces()) {  
  4.     if (space->GetGcRetentionPolicy() == space::kGcRetentionPolicyAlwaysCollect) {  
  5.       current_mark_bitmap_ = space->GetMarkBitmap();  
  6.       CHECK(current_mark_bitmap_ != NULL);  
  7.       return;  
  8.     }  
  9.   }  
  10.   ......  
  11. }  
       这个函数定义在文件art/runtime/gc/collector/mark_sweep.cc中。

       从这里的就可以看出，Default Mark Bitmap就是回收策略为kGcRetentionPolicyAlwaysCollect的Space对应的Mark Bitmap。从前面ART运行时Java堆创建过程分析一文可以知道，这个Space就是Allocation Space（如果Allocation Space还没有从Zygote Space划分出来，那就是Zygote Space）。

       获得的Default Mark Bitmap保存在MarkSweep类的成员变量current_mark_bitmap_中。

       4. MarkingPhase

       MarkSweep、PartialMarkSweep和StickyMarkSweep三个类的标记阶段都是以MarkSweep类的成员函数MarkingPhase为入口，它的实现如下所示：

[cpp]  view plain copy
  1. void MarkSweep::MarkingPhase() {  
  2.   base::TimingLogger::ScopedSplit split("MarkingPhase", &timings_);  
  3.   Thread* self = Thread::Current();  
  4.   
  5.   BindBitmaps();  
  6.   FindDefaultMarkBitmap();  
  7.   
  8.   // Process dirty cards and add dirty cards to mod union tables.  
  9.   heap_->ProcessCards(timings_);  
  10.   
  11.   // Need to do this before the checkpoint since we don't want any threads to add references to  
  12.   // the live stack during the recursive mark.  
  13.   timings_.NewSplit("SwapStacks");  
  14.   heap_->SwapStacks();  
  15.   
  16.   WriterMutexLock mu(self, *Locks::heap_bitmap_lock_);  
  17.   if (Locks::mutator_lock_->IsExclusiveHeld(self)) {  
  18.     // If we exclusively hold the mutator lock, all threads must be suspended.  
  19.     MarkRoots();  
  20.   } else {  
  21.     MarkThreadRoots(self);  
  22.     // At this point the live stack should no longer have any mutators which push into it.  
  23.     MarkNonThreadRoots();  
  24.   }  
  25.   live_stack_freeze_size_ = heap_->GetLiveStack()->Size();  
  26.   MarkConcurrentRoots();  
  27.   
  28.   heap_->UpdateAndMarkModUnion(this, timings_, GetGcType());  
  29.   MarkReachableObjects();  
  30. }  
        这个函数定义在文件art/runtime/gc/collector/mark_sweep.cc中。

        MarkSweep类的成员函数MarkingPhase标记对象的过程如下所示：

        A. 调用成员函数BindBitmap设置回收范围。

        B. 调用成员函数FindDefaultMarkBitmap找到回收策略为kGcRetentionPolicyAlwaysCollect的Space对应的Mark Bitmap，并且保存在成员变量current_mark_bitmap_中。这个函数我们在前面已经分析过了。

        C. 调用Heap类的成员函数ProcessCards处理Card Table中的Dirty Card，以及这些Dirty Card添加到对应的Mod Union Table中去。

        D. 调用Heap类的成员函数SwapStacks交换ART运行时的Allocation Stack和Live Stack。

        E. 对于非并行GC，当前线程在挂起其它ART运行时线程的过程中，已经获得Locks类的静态成员变量mutator_lock_描述的读写锁的写访问，因此这时候就调用成员函数MarkRoots来标记那些不可以在没有获得Locks类的静态成员变量mutator_lock_描述的读写锁的情况下访问的根集对象。注意，MarkSweep类的成员函数MarkRoots只通过当前线程来标记根集对象。

        F. 对于并行GC，由于标记阶段并没有挂起其它的ART运行时线程，因此这时候就调用成员函数MarkThreadRoots来并发标记那些不可以在没有获得Locks类的静态成员变量mutator_lock_描述的读写锁的情况下访问的位于线程调用栈中的根集对象，接着再在当前线程中调用成员函数MarkNonThreadRoots标记那些不可以在没有获得Locks类的静态成员变量mutator_lock_描述的读写锁的情况下访问的其它根集对象。

        G. 获得Live Stack的大小，保存成员变量live_stack_freeze_size_中。注意，这时候Live Stack的大小即为交换Allocation Stack和Live Stack之前Allocation Stack的大小，即从上次GC以来新分配的对象的个数。

        H. 调用成员函数MarkConcurrentRoots标记那些可以在没有获得Locks类的静态成员变量mutator_lock_描述的读写锁的情况下访问的根集对象。

        I. 调用Heap类的成员函数UpdateAndMarkModUnion处理Mod Union Table中的Dirty Card。

        J. 调用成员函数MarkReachableObjects递归标记那些可以从根集对象到达的其它对象。

       上述就是GC的标记阶段，它是一个很复杂的过程，涉及到的关键函数有MarkSweep类的成员函数BindBitmap、MarkRoots、MarkThreadRoots、MarkNonThreadRoots、MarkConcurrentRoots和MarkReachableObjects，以及Heap类的成员函数ProcessCards、SwapStacks和UpdateAndMarkModUnion。接下来我们就详细分析这些函数的实现，以及这些函数涉及到的概念。

        在前面ART运行时垃圾收集机制简要介绍和学习计划一文中，我们提到，Mark Sweep、Partial Mark Sweep和Sticky Mark Sweep的回收范围是不同的，它们分别通过实现的自己的成员函数BindBitmap来限定回收范围，因此，接下来我们就分别分析MarkSweep、PartialMarkSweep和StickyMarkSweep三个类的成员函数BindBitmap的实现。

        MarkSweep类的成员函数BindBitmap的实现如下所示：

[cpp]  view plain copy
  1. void MarkSweep::BindBitmaps() {  
  2.   timings_.StartSplit("BindBitmaps");  
  3.   WriterMutexLock mu(Thread::Current(), *Locks::heap_bitmap_lock_);  
  4.   // Mark all of the spaces we never collect as immune.  
  5.   for (const auto& space : GetHeap()->GetContinuousSpaces()) {  
  6.     if (space->GetGcRetentionPolicy() == space::kGcRetentionPolicyNeverCollect) {  
  7.       ImmuneSpace(space);  
  8.     }  
  9.   }  
  10.   timings_.EndSplit();  
  11. }  

        这个函数定义在文件art/runtime/gc/collector/mark_sweep.cc中。

        MarkSweep类的成员函数BindBitmap调用另外一个成员函数ImmuneSpace将回收策略为kGcRetentionPolicyNeverCollect的Space的Live Bitmap和Mark Bitmap进行交换，这样做的效果就相当于不对该Space进行GC。从前面ART运行时Java堆创建过程分析一文可以知道，回收策略为kGcRetentionPolicyNeverCollect的Space就是Image Space，因此，MarkSweep类就只对Zygote Space和Allocation Space进行GC。

        MarkSweep类的成员函数ImmuneSpace的实现如下所示：

[cpp]  view plain copy
  1. void MarkSweep::ImmuneSpace(space::ContinuousSpace* space) {  
  2.   // Bind live to mark bitmap if necessary.  
  3.   if (space->GetLiveBitmap() != space->GetMarkBitmap()) {  
  4.     BindLiveToMarkBitmap(space);  
  5.   }  
  6.   
  7.   // Add the space to the immune region.  
  8.   if (immune_begin_ == NULL) {  
  9.     DCHECK(immune_end_ == NULL);  
  10.     SetImmuneRange(reinterpret_cast(space->Begin()),  
  11.                    reinterpret_cast(space->End()));  
  12.   } else {  
  13.     const space::ContinuousSpace* prev_space = nullptr;  
  14.     // Find out if the previous space is immune.  
  15.     for (space::ContinuousSpace* cur_space : GetHeap()->GetContinuousSpaces()) {  
  16.       if (cur_space == space) {  
  17.         break;  
  18.       }  
  19.       prev_space = cur_space;  
  20.     }  
  21.     // If previous space was immune, then extend the immune region. Relies on continuous spaces  
  22.     // being sorted by Heap::AddContinuousSpace.  
  23.     if (prev_space != NULL &&  
  24.         immune_begin_ <= reinterpret_cast(prev_space->Begin()) &&  
  25.         immune_end_ >= reinterpret_cast(prev_space->End())) {  
  26.       immune_begin_ = std::min(reinterpret_cast(space->Begin()), immune_begin_);  
  27.       immune_end_ = std::max(reinterpret_cast(space->End()), immune_end_);  
  28.     }  
  29.   }  
  30. }  
        这个函数定义在文件art/runtime/gc/collector/mark_sweep.cc中。

        MarkSweep类的成员函数ImmuneSpace首先是判断参数space描述的Space的Live Bitmap和Mark Bitmap是否是同一个Bitmap。如果是的话，那么就不需要调用成员函数BindLiveToMarkBitmap对它们进行交换了。一般来说，一个Space的Live Bitmap和Mark Bitmap指向的是不同的Bitmap的，但是Image Space比较特殊，它们指向的是同一个Bitmap。这一点在前面ART运行时Java堆创建过程分析一文中有提到。

        如果之前有Space也被设置为不进行回收，那么除了调用成员函数BindLiveToMarkBitmap交换参数space描述的Space的Live Bitmap和Mark Bitmap之外，MarkSweep类的成员函数ImmuneSpace还会参数space描述的Space占用的内存区域与之前也被设置为不进行回收的Space占用的内存区域进行合并，最后将得到的不会被回收的内存总区域的开始位置和结束位置记录在MarkSweep类的成员变量immune_begin_ 和immune_end_中。 

        另一方面，如果之前没有Space也被设置过不进行回收，那么MarkSweep类的成员函数ImmuneSpace就会将参数space描述的Space占用的内存区域的开始位置和结束位置记录在MarkSweep类的成员变量immune_begin_ 和immune_end_中，以便 后面可以调用MarkSweep类的成员函数IsImmune判断一个对象是否位于非回收Space中。

        MarkSweep类的成员函数IsImmune的实现如下所示：

[cpp]  view plain copy
  1. class MarkSweep : public GarbageCollector {  
  2.  public:  
  3.   ......  
  4.   
  5.  protected:  
  6.   ......  
  7.   
  8.   // Returns true if an object is inside of the immune region (assumed to be marked).  
  9.   bool IsImmune(const mirror::Object* obj) const {  
  10.     return obj >= immune_begin_ && obj < immune_end_;  
  11.   }  
  12.   
  13.   ......  
  14. };  
        这个函数定义在文件art/runtime/gc/collector/mark_sweep.cc中。

        MarkSweep类的成员函数IsImmune只需要将参数obj描述的对象地址与MarkSweep类的成员变量immune_begin_和immune_end_进行比较，就可以知道该对象是否位于非回收Space中了。        

        PartialMarkSweep类重写了父类MarkSweep的成员函数BindBitmap，它的实现如下所示：

[cpp]  view plain copy
  1. void PartialMarkSweep::BindBitmaps() {  
  2.   MarkSweep::BindBitmaps();  
  3.   
  4.   WriterMutexLock mu(Thread::Current(), *Locks::heap_bitmap_lock_);  
  5.   // For partial GCs we need to bind the bitmap of the zygote space so that all objects in the  
  6.   // zygote space are viewed as marked.  
  7.   for (const auto& space : GetHeap()->GetContinuousSpaces()) {  
  8.     if (space->GetGcRetentionPolicy() == space::kGcRetentionPolicyFullCollect) {  
  9.       CHECK(space->IsZygoteSpace());  
  10.       ImmuneSpace(space);  
  11.     }  
  12.   }  
  13. }  
       这个函数定义在文件art/runtime/gc/collector/partial_mark_sweep.cc中。

       PartialMarkSweep类的成员函数BindBitmap除了调用父类MarkSweep类的成员函数BindBitmap将Image Space标记为不回收之外，还会将回收策略为kGcRetentionPolicyFullCollect的Space标记为不回收。从前面ART运行时Java堆创建过程分析一文可以知道，回收策略为kGcRetentionPolicyFullCollect的Space就是Zygote Space，因此，MarkSweep类就只对Allocation Space进行GC。

       StickyMarkSweep类重写了父类PartialMarkSweep的成员函数BindBitmap，它的实现如下所示：

[cpp]  view plain copy
  1. void StickyMarkSweep::BindBitmaps() {  
  2.   PartialMarkSweep::BindBitmaps();  
  3.   
  4.   WriterMutexLock mu(Thread::Current(), *Locks::heap_bitmap_lock_);  
  5.   // For sticky GC, we want to bind the bitmaps of all spaces as the allocation stack lets us  
  6.   // know what was allocated since the last GC. A side-effect of binding the allocation space mark  
  7.   // and live bitmap is that marking the objects will place them in the live bitmap.  
  8.   for (const auto& space : GetHeap()->GetContinuousSpaces()) {  
  9.     if (space->GetGcRetentionPolicy() == space::kGcRetentionPolicyAlwaysCollect) {  
  10.       BindLiveToMarkBitmap(space);  
  11.     }  
  12.   }  
  13.   
  14.   GetHeap()->GetLargeObjectsSpace()->CopyLiveToMarked();  
  15. }  
       这个函数定义在文件art/runtime/gc/collector/sticky_mark_sweep.cc中。

       StickyMarkSweep类的成员函数BindBitmap除了调用父类PartialMarkSweep类的成员函数BindBitmap将Image Space和Zygote Space标记为不回收之外，还会将回收策略为kGcRetentionPolicyAlwaysCollect的Continuous Space的Live Bitmap和Mark Bitmap进行交换，执行同样操作的还有Large Object Space。从前面ART运行时Java堆创建过程分析一文可以知道，回收策略为kGcRetentionPolicyAlwaysCollect的Space就是Allocation Space，因此，StickyMarkSweep类就只对Allocation Stack进行GC。

        这里有一点需要注意的是，在交换Live Bitmap和Mark Bitmap之前，Allocation Space和Large Object Space的Live Bitmap都是没有标记那些上次GC以来分配的对象的，而是记录在Allocation Stack中，因此，虽然上次GC以来分配的对象都是位于Allocation Space或者Large Object Space上的，但是这里交换它们的Live Bitmap和Mark Bitmap并不意味着它们不会被回收。

        Heap类的成员函数ProcessCards的实现如下所示：

[cpp]  view plain copy
  1. void Heap::ProcessCards(base::TimingLogger& timings) {  
  2.   // Clear cards and keep track of cards cleared in the mod-union table.  
  3.   for (const auto& space : continuous_spaces_) {  
  4.     if (space->IsImageSpace()) {  
  5.       base::TimingLogger::ScopedSplit split("ImageModUnionClearCards", &timings);  
  6.       image_mod_union_table_->ClearCards(space);  
  7.     } else if (space->IsZygoteSpace()) {  
  8.       base::TimingLogger::ScopedSplit split("ZygoteModUnionClearCards", &timings);  
  9.       zygote_mod_union_table_->ClearCards(space);  
  10.     } else {  
  11.       base::TimingLogger::ScopedSplit split("AllocSpaceClearCards", &timings);  
  12.       // No mod union table for the AllocSpace. Age the cards so that the GC knows that these cards  
  13.       // were dirty before the GC started.  
  14.       card_table_->ModifyCardsAtomic(space->Begin(), space->End(), AgeCardVisitor(), VoidFunctor());  
  15.     }  
  16.   }  
  17. }  
        这个函数定义在文件art/runtime/gc/heap.cc中。 

        Heap类的成员函数ProcessCards用来处理Card Table里面的Dirty Card，它是在Marking阶段被调用的。回忆前面Dalvik虚拟机垃圾收集（GC）过程分析一文，在Dalvik虚拟机的垃圾收集过程中，Dirty Card是在Handle Dirty Object阶段才处理的，那为什么ART运行时会放在Marking阶段就进行处理呢？实际上，ART运行时在Handle Dirty阶段也会对Dirty Card进行处理。也就是说，在ART运行时的垃圾收集过程中，Dirty Card一共被处理两次，一次在Marking阶段，另一次在Handle Dirty Object阶段。这样做有两个原因。

        第一个原因是在ART运行时中，Card Table在并行和非并行GC中都会用到，因此就不能只在Handle Dirty Object阶段才处理。ART运行时中的Card Table在运行期间一直都是用来记录那些修改了引用类型的成员变量的对象的，即这些对象对应的Card都会设置为DIRTY。这些Dirty Card在每次GC时都会进行老化处理。老化处理是通过一个叫AgeCardVisitor的类进行的。每一个Card只有三个可能的值，分别是DIRTY、(DIRTY - 1)和0。当一个对象的引用类型的成员变量被修改之后，它对应的Card的值就会被设置为DIRTY。在接下来的一次GC中，值为DIRTY的Card就会老化为(DIRTY - 1)。在又接下来的GC中，值为(DIRTY-1)的Card就会老化为0。对于值等于DIRTY和(DIRTY - 1)的Card对应的对象，它们在Marking阶段都会被标记。这些对象被标记就意味着它们不会被回收，即使它们不在根集中，并且也不被根集对象引用。尽管这样会造成一些垃圾对象没有及时回收，不过这不会引起程序错误，并且这些对象在再接下来的一次GC中，如果仍然不在根集中，或者不被根集对象引用，那么它们就一定会被回收，因为它们对应的Card已经老化为0了。

        第二个原因是与并行GC相关的。我们知道，Handle Dirty Object阶段是在挂起ART运行时线程的前提下进行的，因此，如果把所有的Dirty Card都放在Handle Dirty Object阶段处理，那么就会可能会造成应用程序停顿时间过长。于是，ART运行时就在并行Marking阶段也帮忙着处理Dirty Card，通过这种方式尽量减少在Handle Dirty Object阶段需要处理的Dirty Card，以达到减少应用程序因为GC造成的停顿时间。不过这样就会有一个问题，在Handle Dirty Object阶段，如何知道哪些Dirty Card是在并行Marking阶段已经被处理过的？这就要借助Mod Union Table了。在Marking阶段，当一个Dirty Card被处理过后，它的值就会由DIRTY变成(DIRTY - 1)，并且被它引用的对象都会被记录在Mod Union Table中。这样我们就可以在Marking阶段和Handle Dirty Object阶段做到共用同一个Card Table，而且又能够区分不同的阶段出现的Dirty Card。

        有了上面的背景知识之后，我们就可以继续分析在Marking阶段与Card Table和Mod Union Table处理相关的逻辑了，即Heap类的成员函数ProcessCards和UpdateAndMarkModUnion的实现。

        从前面ART运行时Java堆创建过程分析一文可以知道，Heap类的成员变量image_mod_union_table_指向的是一个ModUnionTableToZygoteAllocspace对象，用来记录在Image Space上分配的对象对在Zygote Space和Allocation Space上分配的对象的引用，另外一个成员变量zygote_mod_union_table_则指向一个ModUnionTableCardCache，用来记录在Zygote Space上分配的对象对在Allocation Space上分配的对象的引用。因此，对于与Image Space和Zygote Space对应的Dirty Card的处理，是分别通过调用ModUnionTableToZygoteAllocspace类和ModUnionTableCardCache类的成员函数ClearCards来进行的。对于Allocation Space，它没有对应的Mod Union Table，因此，与它对应的Dirty Card的处理，就直接在Card Table进行处理，即调用CardTable类的成员函数ModifyCardsAtomic来进行。

       我们首先分析与Image Space对应的Dirty Card在标记阶段的处理过程之一，即ModUnionTableToZygoteAllocspace类的成员函数ClearCards的实现，它是从父类ModUnionTableReferenceCache继承下来的，用来将Dirty Card的值从DIRTY减为(DIRTY - 1)，如下所示：

[cpp]  view plain copy
  1. void ModUnionTableReferenceCache::ClearCards(space::ContinuousSpace* space) {  
  2.   CardTable* card_table = GetHeap()->GetCardTable();  
  3.   ModUnionClearCardSetVisitor visitor(&cleared_cards_);  
  4.   // Clear dirty cards in the this space and update the corresponding mod-union bits.  
  5.   card_table->ModifyCardsAtomic(space->Begin(), space->End(), AgeCardVisitor(), visitor);  
  6. }  
        这个函数定义在文件art/runtime/gc/accounting/mod_union_table.cc中。 

        参数space指向的是Image Space，ModUnionTableReferenceCache类的成员函数首先找到用来描述ART运行时堆的Card Table，然后再调用它的成员函数ModifyCardsAtomic修改与Image Space对应的那部分Dirty Card的值，具体的修改操作是由第三个参数指定的AgeCardVisitor执行的，第四个参数是一个ModUnionClearCardSetVisitor对象，用来收集缓存那些被修改了的Dirty Card。

        CardTable类的成员函数ModifyCardsAtomic的实现如下所示：

[cpp]  view plain copy
  1. /* 
  2.  * Visitor is expected to take in a card and return the new value. When a value is modified, the 
  3.  * modify visitor is called. 
  4.  * visitor: The visitor which modifies the cards. Returns the new value for a card given an old 
  5.  * value. 
  6.  * modified: Whenever the visitor modifies a card, this visitor is called on the card. Enables 
  7.  * us to know which cards got cleared. 
  8.  */  
  9. template <typename Visitor, typename ModifiedVisitor>  
  10. inline void CardTable::ModifyCardsAtomic(byte* scan_begin, byte* scan_end, const Visitor& visitor,  
  11.                                          const ModifiedVisitor& modified) {  
  12.   byte* card_cur = CardFromAddr(scan_begin);  
  13.   byte* card_end = CardFromAddr(scan_end);  
  14.   CheckCardValid(card_cur);  
  15.   CheckCardValid(card_end);  
  16.   
  17.   // Handle any unaligned cards at the start.  
  18.   while (!IsAligned<sizeof(word)>(card_cur) && card_cur < card_end) {  
  19.     byte expected, new_value;  
  20.     do {  
  21.       expected = *card_cur;  
  22.       new_value = visitor(expected);  
  23.     } while (expected != new_value && UNLIKELY(!byte_cas(expected, new_value, card_cur)));  
  24.     if (expected != new_value) {  
  25.       modified(card_cur, expected, new_value);  
  26.     }  
  27.     ++card_cur;  
  28.   }  
  29.   
  30.   // Handle unaligned cards at the end.  
  31.   while (!IsAligned<sizeof(word)>(card_end) && card_end > card_cur) {  
  32.     --card_end;  
  33.     byte expected, new_value;  
  34.     do {  
  35.       expected = *card_end;  
  36.       new_value = visitor(expected);  
  37.     } while (expected != new_value && UNLIKELY(!byte_cas(expected, new_value, card_end)));  
  38.     if (expected != new_value) {  
  39.       modified(card_cur, expected, new_value);  
  40.     }  
  41.   }  
  42.   
  43.   // Now we have the words, we can process words in parallel.  
  44.   uintptr_t* word_cur = reinterpret_cast<uintptr_t*>(card_cur);  
  45.   uintptr_t* word_end = reinterpret_cast<uintptr_t*>(card_end);  
  46.   uintptr_t expected_word;  
  47.   uintptr_t new_word;  
  48.   
  49.   // TODO: Parallelize.  
  50.   while (word_cur < word_end) {  
  51.     while ((expected_word = *word_cur) != 0) {  
  52.       new_word =  
  53.           (visitor((expected_word >> 0) & 0xFF) << 0) |  
  54.           (visitor((expected_word >> 8) & 0xFF) << 8) |  
  55.           (visitor((expected_word >> 16) & 0xFF) << 16) |  
  56.           (visitor((expected_word >> 24) & 0xFF) << 24);  
  57.       if (new_word == expected_word) {  
  58.         // No need to do a cas.  
  59.         break;  
  60.       }  
  61.       if (LIKELY(android_atomic_cas(expected_word, new_word,  
  62.                                     reinterpret_cast(word_cur)) == 0)) {  
  63.         for (size_t i = 0; i < sizeof(uintptr_t); ++i) {  
  64.           const byte expected_byte = (expected_word >> (8 * i)) & 0xFF;  
  65.           const byte new_byte = (new_word >> (8 * i)) & 0xFF;  
  66.           if (expected_byte != new_byte) {  
  67.             modified(reinterpret_cast(word_cur) + i, expected_byte, new_byte);  
  68.           }  
  69.         }  
  70.         break;  
  71.       }  
  72.     }  
  73.     ++word_cur;  
  74.   }  
  75. }  
        这个函数定义在文件art/runtime/gc/accounting/card_table-inl.h中。

        CardTable类的成员函数ModifyCardsAtomic看起来代码不少，但其实它的逻辑是很简单的。对于参数scan_begin和scan_end描述的Card Table范围内的每一个Card（占一个字节），都通过参数visitor描述的一个AgeCardVisitor进行修改。如果修改后的值与原来的值不相等，则将对应的Card交给参数modified描述的一个ModUnionClearCardSetVisitor进行处理。

       不过，CardTable类的成员函数ModifyCardsAtomic不是简单的遍历参数scan_begin和scan_end描述的Card Table范围内的每一个Card，它会对去掉指定的Card Table范围的头部和尾部不是4字节对齐的部分，得到中间开始地址是以4字节为边界、并且长度也是4的倍数的部分。对于不是4字节对齐的头部和尾部，在当前线程逐个Card的遍历，而对于中间4字节对齐的部分，则是充分利用编译器和CPU指令的并发执行特性，以4个字节，即4个Card为单位进行遍历。通过这种方式，就可以大大地提高对Card Table的处理过程。

       接下来，我们就继续分析AgeCardVisitor和ModUnionClearCardSetVisitor对传递给它们的每一个Card的处理，它们都是通过操作符重载成员函数()来进行处理的。

       AgeCardVisitor类的操作符号重载成员函数()的实现如下所示：

[cpp]  view plain copy
  1. class AgeCardVisitor {  
  2.  public:  
  3.   byte operator()(byte card) const {  
  4.     if (card == accounting::CardTable::kCardDirty) {  
  5.       return card - 1;  
  6.     } else {  
  7.       return 0;  
  8.     }  
  9.   }  
  10. };  
       这个函数定义在文件art/runtime/gc/heap.h中。

       AgeCardVisitor类的操作符号成员函数()主要就是将原来值等于kCardDirty的Card设置为(kCardDirty - 1)，而其它值都会被设置为0。

       ModUnionClearCardSetVisitor类的操作符重载成员函数()的实现如下所示：

[cpp]  view plain copy
  1. class ModUnionClearCardSetVisitor {  
  2.  public:  
  3.   explicit ModUnionClearCardSetVisitor(ModUnionTable::CardSet* const cleared_cards)  
  4.     : cleared_cards_(cleared_cards) {  
  5.   }  
  6.   
  7.   inline void operator()(byte* card, byte expected_value, byte new_value) const {  
  8.     if (expected_value == CardTable::kCardDirty) {  
  9.       cleared_cards_->insert(card);  
  10.     }  
  11.   }  
  12.   
  13.  private:  
  14.   ModUnionTable::CardSet* const cleared_cards_;  
  15. };  
       这个函数定义在文件art/runtime/gc/accounting/mod_union_table.cc中。

        ModUnionClearCardSetVisitor类的操作符重载成员函数()主要就是将原来值等于kCardDirty的Card保存在成员变量cleared_cards_指向的一个CardSet中。注意，这个CardSet实际上就是前面提到的ModUnionTableReferenceCache类的成员变量cleared_cards_指向的CardSet。

        这样，等到ModUnionTableReferenceCache类的成员函数ClearCards执行完毕，所有与Image Space对应的Dirty Card的值都被减少了1，并且保存在成员变量cleared_cards_指向的CardSet了。

        ModUnionTableCardCache类的成员函数ClearCards用来处理与Zygote Space对应的Card Table，它的实现如下所示：

[cpp]  view plain copy
  1. void ModUnionTableCardCache::ClearCards(space::ContinuousSpace* space) {  
  2.   CardTable* card_table = GetHeap()->GetCardTable();  
  3.   ModUnionClearCardSetVisitor visitor(&cleared_cards_);  
  4.   // Clear dirty cards in the this space and update the corresponding mod-union bits.  
  5.   card_table->ModifyCardsAtomic(space->Begin(), space->End(), AgeCardVisitor(), visitor);  
  6. }  
        这个函数定义在文件art/runtime/gc/accounting/mod_union_table.cc中。

        从这里就可以看出，ModUnionTableCardCache类的成员函数ClearCards的实现与我们前面分析的ModUnionTableReferenceCache类的成员函数ClearCards是一样的，只不过它处理的是与Zygote Space对应的Card Table。

        这样，等到ModUnionTableCardCache类的成员函数ClearCards执行完毕，所有与Zygote Space对应的Dirty Card的值都被减少了1，并且保存在成员变量cleared_cards_指向的CardSet了。

        回到前面的Heap类的成员函数ProcessCards中，与Allocation Space对应的Card Table直接通过前面分析过的CardTable类的成员函数ModifyCardsAtomic直接处理。并且在调用CardTable类的成员函数ModifyCardsAtomic的时候，指定的第三个参数同样是AgeCardVisitor，而第四个参数是一个什么也不做的VoidFunctor。这意味着与与Allocation Space对应的Dirty Card除了值减少1之外，基它什么也没有发生。

       上面对Card Table的处理都是在Marking阶段开始的时候进行的，在Marking阶段结束之前，还会再次调用Heap类的成员函数UpdateAndMarkModUnion对Card Table中的Dirty Card进行处理。

       Heap类的成员函数UpdateAndMarkModUnion的实现如下所示：

[cpp]  view plain copy
  1. void Heap::UpdateAndMarkModUnion(collector::MarkSweep* mark_sweep, base::TimingLogger& timings,  
  2.                                  collector::GcType gc_type) {  
  3.   if (gc_type == collector::kGcTypeSticky) {  
  4.     // Don't need to do anything for mod union table in this case since we are only scanning dirty  
  5.     // cards.  
  6.     return;  
  7.   }  
  8.   
  9.   base::TimingLogger::ScopedSplit split("UpdateModUnionTable", &timings);  
  10.   // Update zygote mod union table.  
  11.   if (gc_type == collector::kGcTypePartial) {  
  12.     base::TimingLogger::ScopedSplit split("UpdateZygoteModUnionTable", &timings);  
  13.     zygote_mod_union_table_->Update();  
  14.   
  15.     timings.NewSplit("ZygoteMarkReferences");  
  16.     zygote_mod_union_table_->MarkReferences(mark_sweep);  
  17.   }  
  18.   
  19.   // Processes the cards we cleared earlier and adds their objects into the mod-union table.  
  20.   timings.NewSplit("UpdateModUnionTable");  
  21.   image_mod_union_table_->Update();  
  22.   
  23.   // Scans all objects in the mod-union table.  
  24.   timings.NewSplit("MarkImageToAllocSpaceReferences");  
  25.   image_mod_union_table_->MarkReferences(mark_sweep);  
  26. }  
        这个函数定义在文件art/runtime/gc/heap.cc中。

        对于Sticky Mark Sweep，Card Table里面的Dirty Card不是在Heap类的成员函数UpdateAndMarkModUnion处理的，而是在Marking阶段的最后Marking Reachable Objects过程中处理的。

        对于Partial Mark Sweep，需要处理的Card Table包括Image Space和Zygote Space对应的Card Table，而对于Full Mark Sweep，需要处理的Card Table只有Image Space对应的Card Table。

        由于Image Space和Zygote Space对应的Card Table中的Dirty Card在前面都已经处理过了，并且它们都已经分别缓存在ModUnionTableToZygoteAllocspace类和ModUnionTableCardCache类的成员变量cleared_cards_指向的CardSet中了，因此，这时候主要对这两个CardSet中的Dirty Card进行处理就行了。

        我们先回顾一下，Dirty Card记录的是在不需要进行回收的Space上分配的并且在GC过程中类型为引用的成员变量被修改过的对象，这些被修改的引用类型的成员变量有可能指向了一个在需要进行回收的Space上分配的对象，而这些对象可能不在根集中，因此就需要将将它们当作根集对象一样进行标记。为了方便下面的描述，我们将这些需要像根集对象一样进行标记的对象称为被Dirty Card引用的对象。

        对于被与Image Space对应的Dirty Card引用的对象，是通过调用ModUnionTableToZygoteAllocspace类的成员函数Update和MarkReferences进行的，它们均是从父类ModUnionTableReferenceCache继承下来的，因此接下来我们就分析ModUnionTableReferenceCache类的成员函数Update和MarkReferences的实现。

        ModUnionTableReferenceCache类的成员函数Update的实现如下所示：

[cpp]  view plain copy
  1. void ModUnionTableReferenceCache::Update() {  
  2.   Heap* heap = GetHeap();  
  3.   CardTable* card_table = heap->GetCardTable();  
  4.   
  5.   std::vector<const Object*> cards_references;  
  6.   ModUnionReferenceVisitor visitor(this, &cards_references);  
  7.   
  8.   for (const auto& card : cleared_cards_) {  
  9.     // Clear and re-compute alloc space references associated with this card.  
  10.     cards_references.clear();  
  11.     uintptr_t start = reinterpret_cast<uintptr_t>(card_table->AddrFromCard(card));  
  12.     uintptr_t end = start + CardTable::kCardSize;  
  13.     auto* space = heap->FindContinuousSpaceFromObject(reinterpret_cast(start), false);  
  14.     DCHECK(space != nullptr);  
  15.     SpaceBitmap* live_bitmap = space->GetLiveBitmap();  
  16.     live_bitmap->VisitMarkedRange(start, end, visitor);  
  17.   
  18.     // Update the corresponding references for the card.  
  19.     auto found = references_.find(card);  
  20.     if (found == references_.end()) {  
  21.       if (cards_references.empty()) {  
  22.         // No reason to add empty array.  
  23.         continue;  
  24.       }  
  25.       references_.Put(card, cards_references);  
  26.     } else {  
  27.       found->second = cards_references;  
  28.     }  
  29.   }  
  30.   cleared_cards_.clear();  
  31. }  
        这个函数定义在文件art/runtime/gc/accounting/mod_union_table.cc中。

        ModUnionTableReferenceCache类的成员函数Update主要就是对前面保存在成员变量cleared_cards_描述的一个CardSet中的每一个Dirty Card进行遍历，并且找到这些Dirty Card对应的对象，然后再通过ModUnionReferenceVisitor的操作符重载成员函数()对这些对象的引用类型的成员变量引用的对象进行收集，并且保存在另外一个成员变量references_描述的一个SafeMap中。

        ModUnionReferenceVisitor类的操作符重载成员函数()的实现如下所示：

[cpp]  view plain copy
  1. class ModUnionReferenceVisitor {  
  2.  public:  
  3.   explicit ModUnionReferenceVisitor(ModUnionTableReferenceCache* const mod_union_table,  
  4.                                     std::vector<const Object*>* references)  
  5.     : mod_union_table_(mod_union_table),  
  6.       references_(references) {  
  7.   }  
  8.   
  9.   void operator()(const Object* obj) const  
  10.       SHARED_LOCKS_REQUIRED(Locks::heap_bitmap_lock_, Locks::mutator_lock_) {  
  11.     DCHECK(obj != NULL);  
  12.     // We don't have an early exit since we use the visitor pattern, an early  
  13.     // exit should significantly speed this up.  
  14.     AddToReferenceArrayVisitor visitor(mod_union_table_, references_);  
  15.     collector::MarkSweep::VisitObjectReferences(obj, visitor);  
  16.   }  
  17.  private:  
  18.   ModUnionTableReferenceCache* const mod_union_table_;  
  19.   std::vector<const Object*>* const references_;  
  20. };  
       这个函数定义在文件art/runtime/gc/accounting/mod_union_table.cc中。

       参数obj描述的是便是与Dirty Card对应的对象，现在需要通过MarkSweep类的成员函数VisitObjectReferences遍历它那些引用类型的成员变量，这些成员变量将被AddToReferenceArrayVisitor类的操作符重载成员函数()进行处理。

       AddToReferenceArrayVisitor类的操作符重载成员函数()的实现如下所示：

[cpp]  view plain copy
  1. class AddToReferenceArrayVisitor {  
  2.  public:  
  3.   explicit AddToReferenceArrayVisitor(ModUnionTableReferenceCache* mod_union_table,  
  4.                                       std::vector<const Object*>* references)  
  5.     : mod_union_table_(mod_union_table),  
  6.       references_(references) {  
  7.   }  
  8.   
  9.   // Extra parameters are required since we use this same visitor signature for checking objects.  
  10.   void operator()(const Object* obj, const Object* ref, const MemberOffset& /* offset */,  
  11.                   bool /* is_static */) const {  
  12.     // Only add the reference if it is non null and fits our criteria.  
  13.     if (ref != NULL && mod_union_table_->AddReference(obj, ref)) {  
  14.       references_->push_back(ref);  
  15.     }  
  16.   }  
  17.   
  18.  private:  
  19.   ModUnionTableReferenceCache* const mod_union_table_;  
  20.   std::vector<const Object*>* const references_;  
  21. };  
       这个函数定义在文件art/runtime/gc/accounting/mod_union_table.cc中。

       参数obj是一个与Dirty Card对应的对象，而参数ref是对象obj的一个引用类型的成员变量指向的对象。AddToReferenceArrayVisitor类的操作符重载成员函数()通过调用成员变量mod_union_table_指向的是一个ModUnionTableToZygoteAllocspace对象的成员函数AddReference来判断是否需要将参数ref指向的对象添加到成员变量references_指向的一个vector中。如果ModUnionTableToZygoteAllocspace类的成员函数AddReference的返回值等于true，那么就将参数ref指向的对象添加到成员变量references_指向的一个vector中。

       ModUnionTableToZygoteAllocspace类的成员函数AddReference的实现如下所示：

[cpp]  view plain copy
  1. class ModUnionTableToZygoteAllocspace : public ModUnionTableReferenceCache {  
  2.  public:  
  3.   explicit ModUnionTableToZygoteAllocspace(Heap* heap) : ModUnionTableReferenceCache(heap) {}  
  4.   
  5.   bool AddReference(const mirror::Object* /* obj */, const mirror::Object* ref) {  
  6.     const std::vector& spaces = GetHeap()->GetContinuousSpaces();  
  7.     typedef std::vector::const_iterator It;  
  8.     for (It it = spaces.begin(); it != spaces.end(); ++it) {  
  9.       if ((*it)->Contains(ref)) {  
  10.         return (*it)->IsDlMallocSpace();  
  11.       }  
  12.     }  
  13.     // Assume it points to a large object.  
  14.     // TODO: Check.  
  15.     return true;  
  16.   }  
  17. };  
        这个函数定义在文件art/runtime/gc/accounting/mod_union_table-inl.h中。

        ModUnionTableToZygoteAllocspace类的成员函数AddReference检查参数ref指向的对象，如果它位于一个Continous Space中，并且这个Continuous Space是一个DlMallocSpace，那么就返回true，以表示参数ref指向的对象是一个在Zygote Space和Allocation Space上分配的对象。注意，Zygote Space和Allocation Space都是属于DlMallocSpace。

        另一方面，如果参数ref指向的对象不是位于Continous Space，那么它就肯定是位于Large Object Space中，这时候也需要ModUnionTableToZygoteAllocspace类的成员函数AddReference也是返回true，以表示该对象也需要进行处理。

        这样，等到ModUnionTableToZygoteAllocspace类的成员函数Update执行完毕，那些直接被Dirty Card引用的对象就记录在其成员变量references_描述的一个Safe Map中了，接下来还需要继续调用ModUnionTableToZygoteAllocspace类的成员函数MarkReferences对保存在上述Safe Map中的对象进行递归标记。

        ModUnionTableToZygoteAllocspace类的成员函数MarkReferences是从父类ModUnionTableReferenceCache继承下来的，它的实现如下所示：

[cpp]  view plain copy
  1. void ModUnionTableReferenceCache::MarkReferences(collector::MarkSweep* mark_sweep) {  
  2.   ......  
  3.   
  4.   for (const auto& ref : references_) {  
  5.     for (const auto& obj : ref.second) {  
  6.       mark_sweep->MarkRoot(obj);  
  7.       ......  
  8.     }  
  9.   }  
  10.   ......  
  11. }  
       这个函数定义在文件art/runtime/gc/accounting/mod_union_table.cc中。

       ModUnionTableReferenceCache类的成员函数MarkReferences主要就是对保存在成员变量references_描述的一个Safe Map中的对象通过调用参数mark_sweep描述的一个Mark Sweep进行递归标记。

       这样，等ModUnionTableReferenceCache类的成员函数MarkReferences执行完毕，所有被与Image Space对应的Dirty Card引用的对象都被递归标记完毕了。

       接下来我们再来分析被与Zygote Space对应的Dirty Card引用的对象递归标记的过程。如前所述，这是通过调用ModUnionTableCardCache类的成员函数Update和MarkReferences来实现的。

       ModUnionTableCardCache类的成员函数Update是一个空实现，它也什么也不做，因此我们主要就是分析ModUnionTableCardCache类的成员函数MarkReferences的实现，如下所示：

[cpp]  view plain copy
  1. // Mark all references to the alloc space(s).  
  2. void ModUnionTableCardCache::MarkReferences(collector::MarkSweep* mark_sweep) {  
  3.   CardTable* card_table = heap_->GetCardTable();  
  4.   ModUnionScanImageRootVisitor visitor(mark_sweep);  
  5.   space::ContinuousSpace* space = nullptr;  
  6.   SpaceBitmap* bitmap = nullptr;  
  7.   for (const byte* card_addr : cleared_cards_) {  
  8.     auto start = reinterpret_cast<uintptr_t>(card_table->AddrFromCard(card_addr));  
  9.     auto end = start + CardTable::kCardSize;  
  10.     auto obj_start = reinterpret_cast(start);  
  11.     if (UNLIKELY(space == nullptr || !space->Contains(obj_start))) {  
  12.       space = heap_->FindContinuousSpaceFromObject(obj_start, false);  
  13.       DCHECK(space != nullptr);  
  14.       bitmap = space->GetLiveBitmap();  
  15.       DCHECK(bitmap != nullptr);  
  16.     }  
  17.     bitmap->VisitMarkedRange(start, end, visitor);  
  18.   }  
  19. }  
        这个函数定义在文件art/runtime/gc/accounting/mod_union_table.cc中。

        ModUnionTableCardCache类的成员变量cleared_cards描述的是一具CarSet，这个CardSet保存了与Zygote Space对应的Card Table中的Dirty Card。ModUnionTableCardCache类的成员函数MarkReferences遍历与这些Dirty Card对应的每一个对象，并且调用ModUnionScanImageRootVisitor类的操作符重载成员函数()对这些对象进行处理。

        ModUnionScanImageRootVisitor类的操作符重载成员函数()的实现如下所示：

[cpp]  view plain copy
  1. class ModUnionScanImageRootVisitor {  
  2.  public:  
  3.   explicit ModUnionScanImageRootVisitor(collector::MarkSweep* const mark_sweep)  
  4.       : mark_sweep_(mark_sweep) {}  
  5.   
  6.   void operator()(const Object* root) const  
  7.       EXCLUSIVE_LOCKS_REQUIRED(Locks::heap_bitmap_lock_)  
  8.       SHARED_LOCKS_REQUIRED(Locks::mutator_lock_) {  
  9.     DCHECK(root != NULL);  
  10.     mark_sweep_->ScanRoot(root);  
  11.   }  
  12.   
  13.  private:  
  14.   collector::MarkSweep* const mark_sweep_;  
  15. };  
        这个函数定义在文件art/runtime/gc/accounting/mod_union_table.cc中。

        参数root描述的便是与Zygote Space对应的Dirty Card的对象，ModUnionScanImageRootVisitor类的操作符重载成员函数()通过调用成员变量mark_sweep_描述的一个Mark Sweep对象的成员函数ScanRoot对它进行递归标记。

        从这里就可以看出，虽然我们说Heap类的成员变量zygote_mod_union_table_描述的ModUnionTableCardCache是用来描述在Zygote Space上分配的对象对在Allocation Space上分配的对象的引用，但是ModUnionTableCardCache类并没有像ModUnionTableToZygoteAllocspace一样对被引用对象所在的Space进行判断，而是不管在什么Space都进行标记，这样虽然不会造成逻辑错误，但是也会多做一些无用功。例如，如果被引用对象是位于Image Space上，由于Image Space在这种情况下是不进行回收的，那么对它们进行标记就没有意义。ART运行时实现了一个ModUnionTableToAllocspace类，它的实现就类似于ModUnionTableToZygoteAllocspace，不过只会对被引用对象是在Allocation Space上分配的才会进行递归标记。

        这样，等ModUnionTableCardCache类的成员函数MarkReferences执行完毕，所有被与Zygote Space对应的Dirty Card引用的对象都被递归标记完毕了。

        至此，Marking阶段对Card Table中的Dirty Card的处理就暂告一段落了，回到前面的MarkSweep类的成员函数MarkingPhase中，接下它还需要做的事情包括调用Heap类的成员函数SwapStacks交换Allocation Stack和Live Stack，以及调用MarkSweep类的成员函数MarkRoots、MarkThreadRoots、MarkNonThreadRoots、MarkConcurrentRoots和MarkReachableObjects来递归标记根集对象。

        Heap类的成员函数SwapStacks的实现如下所示：

[cpp]  view plain copy
  1. void Heap::SwapStacks() {  
  2.   allocation_stack_.swap(live_stack_);  
  3. }  
        这个函数定义在文件art/runtime/gc/heap.cc中。

        Heap类的成员变量allocation_stack_和live_stack_指向的分别是ART运行时的Allocation Stack和Live Stack，Heap类的成员函数SwapStacks对它们进交换，以便后面Sticky Mark Sweep可以进行进一步处理。

        接下来，我们再分用来标记根集对象的MarkSweep类的成员函数MarkRoots、MarkThreadRoots、MarkNonThreadRoots、MarkConcurrentRoots。

        ART运行时的根集对象按照是否能够并行访问划分为两类进行标记，一类是可以需要在获取Locks类的静态成员变量mutator_lock_描述的一个读写锁下进行标记，而另一类不需要。Runtime类提供了两个成员函数VisitConcurrentRoots和VisitNonConcurrentRoots来完成这两个操作。

       Runtime类的成员函数VisitConcurrentRoots的实现如下所示：

[cpp]  view plain copy
  1. void Runtime::VisitConcurrentRoots(RootVisitor* visitor, void* arg, bool only_dirty,  
  2.                                    bool clean_dirty) {  
  3.   intern_table_->VisitRoots(visitor, arg, only_dirty, clean_dirty);  
  4.   class_linker_->VisitRoots(visitor, arg, only_dirty, clean_dirty);  
  5. }  
        这个函数定义在文件art/runtime/runtime.cc中。

        Runtime类的成员变量intern_table_指向的是一个InternTable对象，里面保存有ART运行时使用的字符串常量，另外一个成员变量class_linker_指向的是一个ClassLinker对象，里面保存有ART运行时加载的类对象以及内部使用的Dex Cache。关于Dex Cache，可以参考前面Android运行时ART执行类方法的过程分析一文。

        Runtime类的成员函数VisitConcurrentRoots所做的事情就是将ART运行时使用的字符串常量、已经加载的类对象以及Dex Cache对象标记为根集对象。

        Runtime类的成员函数VisitNonConcurrentRoots的实现如下所示：

[cpp]  view plain copy
  1. void Runtime::VisitNonConcurrentRoots(RootVisitor* visitor, void* arg) {  
  2.   thread_list_->VisitRoots(visitor, arg);  
  3.   VisitNonThreadRoots(visitor, arg);  
  4. }  
        这个函数定义在文件art/runtime/runtime.cc中。

        Runtime类的成员变量thread_list_指向的是一个ThreadList对象，里面保存了所有的ART运行时线程，Runtime类的成员函数VisitNonConcurrentRoots通过调用这个ThreadList对象的成员函数VisitRoots来标记所有位于ART运行时线程的调用栈上的根集对象。对于调用栈上的根集对象的标记，可以参考前面Dalvik虚拟机垃圾收集（GC）过程分析一文，ART运行时和Dalivk虚拟机的实现原理都是差不多的，这里不再详述。

        Runtime类的成员函数VisitNonConcurrentRoots还会调用另外一个成员函数VisitNonConcurrentRoots来标记那些不是位于ART运行时线程的调用栈上的根集对象，它的实现如下所示：

[cpp]  view plain copy
  1. void Runtime::VisitNonThreadRoots(RootVisitor* visitor, void* arg) {  
  2.   java_vm_->VisitRoots(visitor, arg);  
  3.   if (pre_allocated_OutOfMemoryError_ != NULL) {  
  4.     visitor(pre_allocated_OutOfMemoryError_, arg);  
  5.   }  
  6.   visitor(resolution_method_, arg);  
  7.   for (int i = 0; i < Runtime::kLastCalleeSaveType; i++) {  
  8.     visitor(callee_save_methods_[i], arg);  
  9.   }  
  10. }  
       这个函数定义在文件art/runtime/runtime.cc中。

       不是位于ART运行时线程的调用栈上的根集对象包括：

        A. 在JNI方法里面通过JNI接口创建的全局引用对象以及被PIN住的数组对象，这些对象保存在Runtime类的成员变量java_vm_描述的一个JavaVMExt对象中，通过调用它的成员函数VisitRoots即可将它们标记为根集对象。

        B. Runtime类的成员pre_allocated_OutOfMemoryError_指向的一个OOM异常对象，直接通过参数visitor描述的一个RootVisitor将它标记为根集对象。

        C. Runtime类内部使用的运行时方法对象，它们分别保存在成员变量resolution_method_和callee_save_methods_中，它们也是接通过参数visitor描述的一个RootVisitor将它标记为根集对象。。关于ART运行时的运行时方法，可以参考前面Android运行时ART执行类方法的过程分析一文。

        此外，Runtime类还提供了另外一个成员函数VisitRoots，用来一次性标记所有的根集对象，如下所示：

[cpp]  view plain copy
  1. void Runtime::VisitRoots(RootVisitor* visitor, void* arg, bool only_dirty, bool clean_dirty) {  
  2.   VisitConcurrentRoots(visitor, arg, only_dirty, clean_dirty);  
  3.   VisitNonConcurrentRoots(visitor, arg);  
  4. }  
       这个函数定义在文件art/runtime/runtime.cc中。

       Runtime类的成员函数VisitRoots通过调用前面分析过的两个成员函数VisitConcurrentRoots和VisitNonConcurrentRoots来遍历当前ART运行时的所有根集对象。

       回到MarkSweep类的成员函数MarkingPhase中，它先标记那些需要获取Locks类的静态成员变量mutator_lock_描述的一个读写锁的根集对象，然后再标记那些不需要获取该读写锁的根集对象，后者通过调用MarkSweep类的成员函数MarkConcurrentRoots来实现，如下所示：

[cpp]  view plain copy
  1. void MarkSweep::MarkConcurrentRoots() {  
  2.   timings_.StartSplit("MarkConcurrentRoots");  
  3.   // Visit all runtime roots and clear dirty flags.  
  4.   Runtime::Current()->VisitConcurrentRoots(MarkObjectCallback, this, false, true);  
  5.   timings_.EndSplit();  
  6. }  
        这个函数定义在文件art/runtime/gc/collector/mark_sweep.cc中。

        MarkSweep类的成员函数MarkConcurrentRoots调用的就是前面分析Runtime类的成员函数VisitConcurrentRoots来标记相应的根集对象，并且指定的标记函数为MarkSweep类的静态成员函数MarkObjectCallback。

        MarkSweep类的静态成员函数MarkObjectCallback的实现如下所示：

[cpp]  view plain copy
  1. void MarkSweep::MarkObjectCallback(const Object* root, void* arg) {  
  2.   ......  
  3.   MarkSweep* mark_sweep = reinterpret_cast(arg);  
  4.   mark_sweep->MarkObjectNonNull(root);  
  5. }  
       这个函数定义在文件art/runtime/gc/collector/mark_sweep.cc中。

       MarkSweep类的静态成员函数MarkObjectCallback又是通过调用另外一个成员函数MarkObjectNonNull来对参数root描述的根集对象进行标记的。

       MarkSweep类的成员函数MarkObjectNonNull的实现如下所示：

[cpp]  view plain copy
  1. inline void MarkSweep::MarkObjectNonNull(const Object* obj) {  
  2.   DCHECK(obj != NULL);  
  3.   
  4.   if (IsImmune(obj)) {  
  5.     DCHECK(IsMarked(obj));  
  6.     return;  
  7.   }  
  8.   
  9.   // Try to take advantage of locality of references within a space, failing this find the space  
  10.   // the hard way.  
  11.   accounting::SpaceBitmap* object_bitmap = current_mark_bitmap_;  
  12.   if (UNLIKELY(!object_bitmap->HasAddress(obj))) {  
  13.     accounting::SpaceBitmap* new_bitmap = heap_->GetMarkBitmap()->GetContinuousSpaceBitmap(obj);  
  14.     if (LIKELY(new_bitmap != NULL)) {  
  15.       object_bitmap = new_bitmap;  
  16.     } else {  
  17.       MarkLargeObject(obj, true);  
  18.       return;  
  19.     }  
  20.   }  
  21.   
  22.   // This object was not previously marked.  
  23.   if (!object_bitmap->Test(obj)) {  
  24.     object_bitmap->Set(obj);  
  25.     if (UNLIKELY(mark_stack_->Size() >= mark_stack_->Capacity())) {  
  26.       // Lock is not needed but is here anyways to please annotalysis.  
  27.       MutexLock mu(Thread::Current(), mark_stack_lock_);  
  28.       ExpandMarkStack();  
  29.     }  
  30.     // The object must be pushed on to the mark stack.  
  31.     mark_stack_->PushBack(const_cast(obj));  
  32.   }  
  33. }  
        这个函数定义在文件art/runtime/gc/collector/mark_sweep.cc中。

        MarkSweep类的成员函数MarkObjectNonNull首先是判断参数obj指定的对象是否在不回收范围内，这是通过调用MarkSweep类的成员函数IsImmune来判断的。GC的不回收范围，是前面通过调用MarkSweep类的成员函数BindBitmap来设置的。一旦参数obj指定的对象在不回收范围内，MarkSweep类的成员函数MarkObjectNonNull什么也不用做就返回了。

        MarkSweep类的成员变量current_mark_bitmap_缓存的是Allocation Space对应的Mark Bitmap，这是通过前面分析的MarkSweep类的成员函数FindDefaultMarkBitmap来实现的。这个缓存的Mark Bitmap是为了避免每次标记对象时，都要去查找它对应的Mark Bitmap而设计的，这样可以提高标记对象的效率，因为大部分对象都是位于Allocation Space上的。

        MarkSweep类的成员函数MarkObjectNonNull接下来就是判断成员变量current_mark_bitmap_指向的Mark Bitmap是否可以用来标记对象obj。如果不可以，就先在Continuous Space的Mark Bitmap中找到可以用来标记对象obj的Mark Bitmap。如果找不到，就说明该对象是在Large Object Space上分配的，因此就调用另外一个成员函数MarkLargeObject对它进行标记。

        找到了可以用来标记对象obj的Mark Bitmap之后，就可以对对象obj进行处理了。如果对象obj之前已经被标记过了，那么就什么也不用做。否则的话，就调用SpaceBitmap类的成员函数Set对它进行标记，并且将它压入到MarkSweep类的成员变量mark_stack_描述的一个Mark Stack中，以表后面可以执行递归标记。

        回到MarkSweep类的成员函数MarkingPhase中，对于那些需要获取Locks类的静态成员变量mutator_lock_描述的一个读写锁的根集对象的标记，分为非并行GC和并行GC两种情况考虑。

        对于非并行GC，此时除了当前执行GC的线程之外，其它的ART运行时线程都已经被挂起，因此，这时候根集对象就只可以在当前执行GC的线程中进行标记。这是通过调用MarkSweep类的成员函数MarkRoots来实现的，如下所示：

[cpp]  view plain copy
  1. void MarkSweep::MarkRoots() {  
  2.   timings_.StartSplit("MarkRoots");  
  3.   Runtime::Current()->VisitNonConcurrentRoots(MarkObjectCallback, this);  
  4.   timings_.EndSplit();  
  5. }  
        这个函数定义在文件art/runtime/gc/collector/mark_sweep.cc中。

        MarkSweep类的成员函数MarkRoots通过调用前面分析过的Runtime类的成员函数VisitNonConcurrentRoots来遍历那些需要获取Locks类的静态成员变量mutator_lock_描述的一个读写锁的根集对象，并且也是通过调用前面分析过的MarkSweep类的静态成员函数MarkObjectCallback,对它们进行标记。

        对并行GC。我们可以将那些需要获取Locks类的静态成员变量mutator_lock_描述的一个读写锁的根集对象划分为两类，一类是位于线程调用栈的，另一类是不位于线程调用栈的。对于不是位于线程调用栈的根集对象，在当前执行GC的线程中调用MarkSweep类的成员函数MarkNonThreadRoots来进行标记。

        MarkSweep类的成员函数MarkNonThreadRoots的实现如下所示：

[cpp]  view plain copy
  1. void MarkSweep::MarkNonThreadRoots() {  
  2.   timings_.StartSplit("MarkNonThreadRoots");  
  3.   Runtime::Current()->VisitNonThreadRoots(MarkObjectCallback, this);  
  4.   timings_.EndSplit();  
  5. }  
       这个函数定义在文件art/runtime/gc/collector/mark_sweep.cc中。

       MarkSweep类的成员函数MarkRoots通过调用前面分析过的Runtime类的成员函数VisitNonThreadRoots来遍历那些不是在线程调用栈的根集对象，并且也是通过调用前面分析过的MarkSweep类的静态成员函数MarkObjectCallback,对它们进行标记。

      对于位于线程调用栈的根集对象的标记，可以做利用CPU的多核特性做一些并发优化。注意，这时候除了当前执行GC的线程可以运行之外，其它的ART运行时线程也是可以运行的。这样就可以让正在运行的ART运行时线程来并发标记各自那些位于调用栈上的根集对象。这个工作是通过调用MarkSweep类的成员函数MarkThreadRoots来实现的，如下所示：

[cpp]  view plain copy
  1. void MarkSweep::MarkThreadRoots(Thread* self) {  
  2.   MarkRootsCheckpoint(self);  
  3. }  
       这个函数定义在文件art/runtime/gc/collector/mark_sweep.cc中。

       MarkSweep类的成员函数MarkThreadRoots又是通过调用另外一个成员函数MarkRootsCheckpoint对调用栈上的根集对象进行并行标记的，后者的实现如下所示：

[cpp]  view plain copy
  1. void MarkSweep::MarkRootsCheckpoint(Thread* self) {  
  2.   CheckpointMarkThreadRoots check_point(this);  
  3.   timings_.StartSplit("MarkRootsCheckpoint");  
  4.   ThreadList* thread_list = Runtime::Current()->GetThreadList();  
  5.   // Request the check point is run on all threads returning a count of the threads that must  
  6.   // run through the barrier including self.  
  7.   size_t barrier_count = thread_list->RunCheckpoint(&check_point);  
  8.   // Release locks then wait for all mutator threads to pass the barrier.  
  9.   // TODO: optimize to not release locks when there are no threads to wait for.  
  10.   Locks::heap_bitmap_lock_->ExclusiveUnlock(self);  
  11.   Locks::mutator_lock_->SharedUnlock(self);  
  12.   ThreadState old_state = self->SetState(kWaitingForCheckPointsToRun);  
  13.   CHECK_EQ(old_state, kWaitingPerformingGc);  
  14.   gc_barrier_->Increment(self, barrier_count);  
  15.   self->SetState(kWaitingPerformingGc);  
  16.   Locks::mutator_lock_->SharedLock(self);  
  17.   Locks::heap_bitmap_lock_->ExclusiveLock(self);  
  18.   timings_.EndSplit();  
  19. }  
       这个函数定义在文件art/runtime/gc/collector/mark_sweep.cc中。

       MarkSweep类的成员函数MarkThreadRoots首先是创建一个类型为CheckpointMarkThreadRoots的Check Point，然后通过调用ThreadList类的成员函数RunCheckpoint将该Check Point提交给当前运行的ART运行时线程执行。

       ThreadList类的成员函数RunCheckpoint返回时，只表示Check Point已经提交了，但是可能还没有全部执行。它的返回值barrier_count描述的是执行Check Point的ART运行时线程的个数。MarkSweep类的成员函数MarkThreadRoots接下来就需要调用成员变量gc_barrier_描述的一个Barrier对象的成员函数Increment来等待上述的barrier_count个ART运行时线程执行完毕刚才提交的Check Point。

       在等待其它ART运行时线程执行Check Point之前，MarkSweep类的成员函数MarkThreadRoots会先释放当前线程之前获得的Locks类的静态成员变量heap_bitmap_lock_描述的一个读写锁的写访问，以及Locks类的静态成员变量mutator_lock_描述的一个读写锁的读访问。等到Check Point都执先完成之后，再重新获得上述的两个锁。

       ThreadList类的成员函数RunCheckpoint的实现如下所示：

[cpp]  view plain copy
  1. size_t ThreadList::RunCheckpoint(Closure* checkpoint_function) {  
  2.   Thread* self = Thread::Current();  
  3.   ......  
  4.   
  5.   std::vector suspended_count_modified_threads;  
  6.   size_t count = 0;  
  7.   {  
  8.     // Call a checkpoint function for each thread, threads which are suspend get their checkpoint  
  9.     // manually called.  
  10.     MutexLock mu(self, *Locks::thread_list_lock_);  
  11.     for (const auto& thread : list_) {  
  12.       if (thread != self) {  
  13.         for (;;) {  
  14.           if (thread->RequestCheckpoint(checkpoint_function)) {  
  15.             // This thread will run it's checkpoint some time in the near future.  
  16.             count++;  
  17.             break;  
  18.           } else {  
  19.             // We are probably suspended, try to make sure that we stay suspended.  
  20.             MutexLock mu2(self, *Locks::thread_suspend_count_lock_);  
  21.             // The thread switched back to runnable.  
  22.             if (thread->GetState() == kRunnable) {  
  23.               continue;  
  24.             }  
  25.             thread->ModifySuspendCount(self, +1, false);  
  26.             suspended_count_modified_threads.push_back(thread);  
  27.             break;  
  28.           }  
  29.         }  
  30.       }  
  31.     }  
  32.   }  
  33.   
  34.   // Run the checkpoint on ourself while we wait for threads to suspend.  
  35.   checkpoint_function->Run(self);  
  36.   
  37.   // Run the checkpoint on the suspended threads.  
  38.   for (const auto& thread : suspended_count_modified_threads) {  
  39.     if (!thread->IsSuspended()) {  
  40.       // Wait until the thread is suspended.  
  41.       uint64_t start = NanoTime();  
  42.       do {  
  43.         // Sleep for 100us.  
  44.         usleep(100);  
  45.       } while (!thread->IsSuspended());  
  46.       uint64_t end = NanoTime();  
  47.       // Shouldn't need to wait for longer than 1 millisecond.  
  48.       const uint64_t threshold = 1;  
  49.       if (NsToMs(end - start) > threshold) {  
  50.         LOG(INFO) << "Warning: waited longer than " << threshold  
  51.                   << " ms for thread suspend\n";  
  52.       }  
  53.     }  
  54.     // We know for sure that the thread is suspended at this point.  
  55.     thread->RunCheckpointFunction();  
  56.     {  
  57.       MutexLock mu2(self, *Locks::thread_suspend_count_lock_);  
  58.       thread->ModifySuspendCount(self, -1, false);  
  59.     }  
  60.   }  
  61.   
  62.   {  
  63.     // Imitate ResumeAll, threads may be waiting on Thread::resume_cond_ since we raised their  
  64.     // suspend count. Now the suspend_count_ is lowered so we must do the broadcast.  
  65.     MutexLock mu2(self, *Locks::thread_suspend_count_lock_);  
  66.     Thread::resume_cond_->Broadcast(self);  
  67.   }  
  68.   
  69.   // Add one for self.  
  70.   return count + suspended_count_modified_threads.size() + 1;  
  71. }  
       这个函数定义在文件art/runtime/gc/collector/mark_sweep.cc中。

       ThreadList类的成员函数RunCheckpoint的执行逻辑如下所示：

        A. 遍历成员变量list_中的每一个ART运行时线程，并且通过调用它们的成员函数RequestCheckpoint分别向它们提交参数checkpoint_function的一个Check Point。如果能够成功提交，那么Thread类的成员函数RequestCheckpoint就返回true。如果不能成功提交，那么就可能是线程正处于挂起状态，这时候就要将线程的挂起计数器增加1，确保继续挂起，并且将该线程保存在变量suspended_count_modified_threads描述的一个向量中。不过，在增加线程的挂起计数器之前，线程有可能又切换为运行状态了，这时候就需要重新调用它的成员函数RequestCheckpoint向它重新提交数checkpoint_function的一个Check Point。

        B. 当前线程是执行GC的线程，它也需要执行参数checkpoint_function的Check Point，直接调用它的成员函数Run来执行即可。

        C. 接下来需要在当前线程代替那些处于挂起状态的线程执行提交给它们的、但是它们不能执行的Check Point，这是通过在当前线程调用Thread类的成员函数RunCheckpointFunction来完成的。执行完成之后，需要将这些线程的挂起计数器减少1。注意，必须要确保当前线程是在刚才保存在变量suspended_count_modified_threads描述的一个向量中的线程是在挂起状态下代替执行参数checkpoint_function的Check Point的，否则就会造成竞争条件。

        D. 前面分析恢复ART运行时线程执行的时候提到，在增加了ART运行时线程的挂数计数器之后，需要通过Thread类的静态成员变量resume_cond_描述的一个条件变量唤醒被挂起的线程。这里由于也有同样的操作，因此也需要通过Thread类的静态成员变量resume_cond_描述的一个条件变量唤醒被挂起的线程。

        E. 返回总共用来执行Check Point的ART运行时线程的个数。

       注意，这时候那些成功接收了Check Point的ART运行时线程可能还没有执行Checkp Point。因此，ThreadList类的成员函数RunCheckpoint的调用方需要有一个等待的过程。

       接下来，我们继续分析Thread类的成员函数RequestCheckpoint的实现，以便可以了解给一个线程提交Check Point的过程，它的实现如下所示：

[cpp]  view plain copy
  1. bool Thread::RequestCheckpoint(Closure* function) {  
  2.   CHECK(!ReadFlag(kCheckpointRequest)) << "Already have a pending checkpoint request";  
  3.   checkpoint_function_ = function;  
  4.   union StateAndFlags old_state_and_flags = state_and_flags_;  
  5.   // We must be runnable to request a checkpoint.  
  6.   old_state_and_flags.as_struct.state = kRunnable;  
  7.   union StateAndFlags new_state_and_flags = old_state_and_flags;  
  8.   new_state_and_flags.as_struct.flags |= kCheckpointRequest;  
  9.   int succeeded = android_atomic_cmpxchg(old_state_and_flags.as_int, new_state_and_flags.as_int,  
  10.                                          &state_and_flags_.as_int);  
  11.   return succeeded == 0;  
  12. }  
       这个函数定义在文件art/runtime/thread.cc中。

       Thread类的成员函数RequestCheckpoint首先将参数function描述的一个Check Point保存在成员变量checkpoint_function_，然后尝试将线程的状态设置为kRunnable，并且将其标记位kCheckpointRequest设置为1。如果能成功修改线程的状态和标记位，那么就可以保证线程接下来可以执行保存在成员变量checkpoint_function_的Check Point。

       前面分析ART运行时线程的挂起过程时提到，ART运行时线程在运行的过程中，会周期性地检查自己的挂起计数器和标志位，如果发现自己的kCheckpointRequest标记位被设置为1，那么它就知道自己有一个Check Point需要等待执行，于是就会调用Thread类的成员函数RunCheckpointFunction来执行该Check Point。

       Thread类的成员函数RunCheckpointFunction的实现如下所示：

[cpp]  view plain copy
  1. void Thread::RunCheckpointFunction() {  
  2.   ......  
  3.   checkpoint_function_->Run(this);  
  4.   ......  
  5. }  
       这个函数定义在文件art/runtime/thread.cc中。     

       Thread类的成员函数RunCheckpointFunction通过调用成员变量checkpoint_function_指向的一个Check Point的成员函数Run来执行对应的Check Point。在我们这个情景中，Thread类的成员变量checkpoint_function_指向的是一个CheckpointMarkThreadRoots对象，它的成员函数Run的实现如下所示：

[cpp]  view plain copy
  1. class CheckpointMarkThreadRoots : public Closure {  
  2.  public:  
  3.   explicit CheckpointMarkThreadRoots(MarkSweep* mark_sweep) : mark_sweep_(mark_sweep) {}  
  4.   
  5.   virtual void Run(Thread* thread) NO_THREAD_SAFETY_ANALYSIS {  
  6.     ......  
  7.     Thread* self = Thread::Current();  
  8.     ......  
  9.     thread->VisitRoots(MarkSweep::MarkRootParallelCallback, mark_sweep_);  
  10.     ......  
  11.     mark_sweep_->GetBarrier().Pass(self);  
  12.   }  
  13.   
  14.  private:  
  15.   MarkSweep* mark_sweep_;  
  16. };  
       这个函数定义在文件art/runtime/gc/collector/mark_sweep.cc中。

       当前线程通过调用Thread类的成员函数VisitRoots来遍历调用栈上的根集对象，并且通过MarkSweep类的静态成员函数MarkRootParallelCallback对它们进行标记。标记完成后，再调用在前面分析MarkSweep类的成员函数MarkRootsCheckpoint时提到的Barrier对象的成员Pass，以便可以通知有一个线程执行完成自己的Check Point了，这样就可以使得正在等待所有ART运行时线程都执行完成自己的Check Point的GC线程可以被唤醒继续往前执行。

       MarkSweep类的静态成员函数MarkRootParallelCallback的实现如下所示：

[cpp]  view plain copy
  1. void MarkSweep::MarkRootParallelCallback(const Object* root, void* arg) {  
  2.   ......  
  3.   reinterpret_cast(arg)->MarkObjectNonNullParallel(root);  
  4. }  
       这个函数定义在文件art/runtime/gc/collector/mark_sweep.cc中。

       MarkSweep类的静态成员函数MarkRootParallelCallback通过调用另外一个成员函数MarkObjectNonNullParallel来标记参数root描述的根集对象，后者的实现如下所示：

[cpp]  view plain copy
  1. inline void MarkSweep::MarkObjectNonNullParallel(const Object* obj) {  
  2.   ......  
  3.   if (MarkObjectParallel(obj)) {  
  4.     MutexLock mu(Thread::Current(), mark_stack_lock_);  
  5.     if (UNLIKELY(mark_stack_->Size() >= mark_stack_->Capacity())) {  
  6.       ExpandMarkStack();  
  7.     }  
  8.     // The object must be pushed on to the mark stack.  
  9.     mark_stack_->PushBack(const_cast(obj));  
  10.   }  
  11. }  
       这个函数定义在文件art/runtime/gc/collector/mark_sweep.cc中。

       MarkSweep类的成员函数MarkObjectNonNullParallel又调用另外一个成员函数MarkObjectParallel来标记参数obj描述的根集对象。如果标记成功，那么就将它压入到成员变量mark_stack_描述的一个Mark Stack中，以便后面可以执行递归标记。

       MarkSweep类的成员函数MarkObjectParallel的实现如下所示：

[cpp]  view plain copy
  1. inline bool MarkSweep::MarkObjectParallel(const Object* obj) {  
  2.   DCHECK(obj != NULL);  
  3.   
  4.   if (IsImmune(obj)) {  
  5.     DCHECK(IsMarked(obj));  
  6.     return false;  
  7.   }  
  8.   
  9.   // Try to take advantage of locality of references within a space, failing this find the space  
  10.   // the hard way.  
  11.   accounting::SpaceBitmap* object_bitmap = current_mark_bitmap_;  
  12.   if (UNLIKELY(!object_bitmap->HasAddress(obj))) {  
  13.     accounting::SpaceBitmap* new_bitmap = heap_->GetMarkBitmap()->GetContinuousSpaceBitmap(obj);  
  14.     if (new_bitmap != NULL) {  
  15.       object_bitmap = new_bitmap;  
  16.     } else {  
  17.       // TODO: Remove the Thread::Current here?  
  18.       // TODO: Convert this to some kind of atomic marking?  
  19.       MutexLock mu(Thread::Current(), large_object_lock_);  
  20.       return MarkLargeObject(obj, true);  
  21.     }  
  22.   }  
  23.   
  24.   // Return true if the object was not previously marked.  
  25.   return !object_bitmap->AtomicTestAndSet(obj);  
  26. }  
       这个函数定义在文件art/runtime/gc/collector/mark_sweep.cc中。

       MarkSweep类的成员函数MarkObjectParallel的实现与前面分析的另外一个成员函数MarkObjectNonNull是差不多的，因此这里不再详述。

       现在，所有的根集对象终于都标记完成了。回到前面的MarkSweep类的成员函数MarkingPhase中，最后需要做的事情是递归标记那些根集对象递归引用的其它对象，这是通过调用MarkSweep类的成员函数MarkReachableObjects来实现的，如下所示：

[cpp]  view plain copy
  1. void MarkSweep::MarkReachableObjects() {  
  2.   // Mark everything allocated since the last as GC live so that we can sweep concurrently,  
  3.   // knowing that new allocations won't be marked as live.  
  4.   timings_.StartSplit("MarkStackAsLive");  
  5.   accounting::ObjectStack* live_stack = heap_->GetLiveStack();  
  6.   heap_->MarkAllocStack(heap_->alloc_space_->GetLiveBitmap(),  
  7.                         heap_->large_object_space_->GetLiveObjects(), live_stack);  
  8.   live_stack->Reset();  
  9.   timings_.EndSplit();  
  10.   // Recursively mark all the non-image bits set in the mark bitmap.  
  11.   RecursiveMark();  
  12. }  

       这个函数定义在文件art/runtime/gc/collector/mark_sweep.cc中。

       MarkSweep类的成员函数MarkReachableObjects首先会将Live Stack的对象全部进行标记。这里的Live Stack其实就是之前的Allocation Stack，也就是说，Mark Sweep不会对上次GC以后分配的对象进行垃圾回收。Partial Mark Sweep也是通过父类MarkSweep类的成员函数MarkReachableObjects来递归标记根集对象引用的对象的，也就是说，Mark Sweep也不会对上次GC以后分配的对象进行垃圾回收。由于Sticky Mark Sweep刚好相反，它要对上次GC以后分配的对象进行垃圾回收，因此，它就必须要重写MarkSweep类的成员函数MarkReachableObjects。

       MarkSweep类的成员函数MarkReachableObjects接着再调用MarkSweep类的成员函数RecursiveMark对根集对象引用的其它对象进行递归标记，它的实现如下所示：

[cpp]  view plain copy
  1. // Populates the mark stack based on the set of marked objects and  
  2. // recursively marks until the mark stack is emptied.  
  3. void MarkSweep::RecursiveMark() {  
  4.   base::TimingLogger::ScopedSplit split("RecursiveMark", &timings_);  
  5.   ......  
  6.   
  7.   if (kUseRecursiveMark) {  
  8.     const bool partial = GetGcType() == kGcTypePartial;  
  9.     ScanObjectVisitor scan_visitor(this);  
  10.     auto* self = Thread::Current();  
  11.     ThreadPool* thread_pool = heap_->GetThreadPool();  
  12.     size_t thread_count = GetThreadCount(false);  
  13.     const bool parallel = kParallelRecursiveMark && thread_count > 1;  
  14.     mark_stack_->Reset();  
  15.     for (const auto& space : GetHeap()->GetContinuousSpaces()) {  
  16.       if ((space->GetGcRetentionPolicy() == space::kGcRetentionPolicyAlwaysCollect) ||  
  17.           (!partial && space->GetGcRetentionPolicy() == space::kGcRetentionPolicyFullCollect)) {  
  18.         current_mark_bitmap_ = space->GetMarkBitmap();  
  19.         ......  
  20.         if (parallel) {  
  21.           // We will use the mark stack the future.  
  22.           // CHECK(mark_stack_->IsEmpty());  
  23.           // This function does not handle heap end increasing, so we must use the space end.  
  24.           uintptr_t begin = reinterpret_cast<uintptr_t>(space->Begin());  
  25.           uintptr_t end = reinterpret_cast<uintptr_t>(space->End());  
  26.           atomic_finger_ = static_cast(0xFFFFFFFF);  
  27.   
  28.           // Create a few worker tasks.  
  29.           const size_t n = thread_count * 2;  
  30.           while (begin != end) {  
  31.             uintptr_t start = begin;  
  32.             uintptr_t delta = (end - begin) / n;  
  33.             delta = RoundUp(delta, KB);  
  34.             if (delta < 16 * KB) delta = end - begin;  
  35.             begin += delta;  
  36.             auto* task = new RecursiveMarkTask(thread_pool, this, current_mark_bitmap_, start,  
  37.                                                begin);  
  38.             thread_pool->AddTask(self, task);  
  39.           }  
  40.           thread_pool->SetMaxActiveWorkers(thread_count - 1);  
  41.           thread_pool->StartWorkers(self);  
  42.           thread_pool->Wait(self, true, true);  
  43.           thread_pool->StopWorkers(self);  
  44.         } else {  
  45.           // This function does not handle heap end increasing, so we must use the space end.  
  46.           uintptr_t begin = reinterpret_cast<uintptr_t>(space->Begin());  
  47.           uintptr_t end = reinterpret_cast<uintptr_t>(space->End());  
  48.           current_mark_bitmap_->VisitMarkedRange(begin, end, scan_visitor);  
  49.         }  
  50.       }  
  51.     }  
  52.   }  
  53.   ProcessMarkStack(false);  
  54. }  
        这个函数定义在文件art/runtime/gc/collector/mark_sweep.cc中。

        如果常量kUseRecursiveMark和kParallelRecursiveMark的值均设置为true，并且ART运行时在启动时创建的用于执行并发GC的线程个数thread_count大于1，那么对于Allocation Space以及不是kGcTypePartial类型的GC下的Zygote Space，将采用多线程并发递归标记那些被根集对象直接或者间接引用的其它对象。

        假设一个Space的大小为(end - begin)，用来执行并发标记的线程的个数为thread_count，那么就将整个Space的标记任务划分为(end - begin) / (thread_count * 2)个子任务。每一个子任务都封装成一个RecursiveMarkTask对象，通过调用ThreadPool类的成员函数AddTask添加到线程池中去。

        接着再通过ThreadPool类的成员函数SetMaxActiveWorkers将线程池用于执行任务的线程个数设置(thread_count - 1)。为什么不是设置为thread_count呢？这是因为当前线程也是属于执行GC任务的线程之一，因此就只需要从线程池中抽取(thread_count - 1)个线程出来就行了。另外，调用MarkSweep类的成员函数GetThreadCount获得线程池的线程个数，如果指定的参数为false，表示要获取的是在GC并发阶段可以用来执行GC任务的线程的个数，对应于ART运运时启动选项-XX:ConcGCThreads指定的线程个数。如果指定的参数为true，则表示要获取的是在GC暂停阶段可以用来执行GC任务的线程的个数，对应于ART运运时启动选项-XX:ParallelGCThreads指定的线程个数。

        最后就调用ThreadPool类的成员函数StartWorkers启动线程池执行任务，并且通过调用ThreadPool类的另外一个成员函数Wait来让当前线程去执行线程池的任务，并且等待其它线程执行完成任务。

        如果一个Space不能满足上述的并发标记条件，那么就只能在当前线程中递归标记根集对象，这是通过调用SpaceBitmap类的成员函数VisitMarkedRange来完成的，并且通过变量scan_visitor描述的一个ScanObjectVisitor对象来执行具体的标记任务。

        由于在前面的标记过程中，可能又会有新的对象被压入到Mark Stack中，因此，MarkSweep类的成员函数RecursiveMark最后还需要调用另外一个成员函数ProcessMarkStack来检查Mark Stack是否不为空。如果不为空，那么就需要递归标记下去。

        这样，当常量kUseRecursive等于true，MarkMarkSweep类的成员函数RecursiveMark实际上既需要通过线程池来并发执行RecursiveMarkTask，也需要通过调用MarkSweep类的成员函数ProcessMarkStack来执行在单线程中执行递归标记根集的任务，而当kUseRecursive等于false，就只会调用MarkSweep类的成员函数ProcessMarkStack来执行在单线程中执行递归标记根集的任务。接下来我们就这两种递归标记根集对象的过程。

        并发递归标记根集对象的过程是通过在线程池中执行RecursiveMarkTask来完成的，也就是调用RecursiveMarkTask类的成员函数Run来完成的，它的实现如下所示：

[cpp]  view plain copy
  1. class RecursiveMarkTask : public MarkStackTask<false> {  
  2.  ......  
  3.   
  4.   // Scans all of the objects  
  5.   virtual void Run(Thread* self) NO_THREAD_SAFETY_ANALYSIS {  
  6.     ScanObjectParallelVisitor visitor(this);  
  7.     bitmap_->VisitMarkedRange(begin_, end_, visitor);  
  8.     // Finish by emptying our local mark stack.  
  9.     MarkStackTask::Run(self);  
  10.   }  
  11. };  
        这个函数定义在文件art/runtime/gc/collector/mark_sweep.cc中。

        RecursiveMarkTask类的成员函数Run首先是通过调用成员变量bitmap_指向的一个SpaceBitmap对象的成员函数VisitMarkedRange来遍历成员变量begin_和end_限定范围的被标记对象，即根集对象，并且通过调用ScanObjectParallelVisitor类的操作符重载函数()对它们进行处理，接着再调用父类MarkStackTask的成员函数Run来递归标记上述的根集对象。

        ScanObjectParallelVisitor类的操作符重载函数()的实现如下所示：

[cpp]  view plain copy
  1. template <bool kUseFinger = false>  
  2. class MarkStackTask : public Task {  
  3.  ......  
  4.   
  5.  protected:  
  6.   class ScanObjectParallelVisitor {  
  7.    public:  
  8.     explicit ScanObjectParallelVisitor(MarkStackTask* chunk_task) ALWAYS_INLINE  
  9.         : chunk_task_(chunk_task) {}  
  10.   
  11.     void operator()(const Object* obj) const {  
  12.       MarkSweep* mark_sweep = chunk_task_->mark_sweep_;  
  13.       mark_sweep->ScanObjectVisit(obj,  
  14.           [mark_sweep, this](const Object* /* obj */, const Object* ref,  
  15.               const MemberOffset& /* offset */, bool /* is_static */) ALWAYS_INLINE {  
  16.         if (ref != nullptr && mark_sweep->MarkObjectParallel(ref)) {  
  17.           ......  
  18.           chunk_task_->MarkStackPush(ref);  
  19.         }  
  20.       });  
  21.     }  
  22.   
  23.    private:  
  24.     MarkStackTask* const chunk_task_;  
  25.   };  
  26.   
  27.  .....  
  28.   
  29.   void MarkStackPush(const Object* obj) ALWAYS_INLINE {  
  30.     if (UNLIKELY(mark_stack_pos_ == kMaxSize)) {  
  31.       // Mark stack overflow, give 1/2 the stack to the thread pool as a new work task.  
  32.       mark_stack_pos_ /= 2;  
  33.       auto* task = new MarkStackTask(thread_pool_, mark_sweep_, kMaxSize - mark_stack_pos_,  
  34.                                      mark_stack_ + mark_stack_pos_);  
  35.       thread_pool_->AddTask(Thread::Current(), task);  
  36.     }  
  37.     ......  
  38.     mark_stack_[mark_stack_pos_++] = obj;  
  39.   }  
  40.   
  41.  ......  
  42. };  
        这个函数定义在文件art/runtime/gc/collector/mark_sweep.cc中。

        ScanObjectParallelVisitor类的操作符重载函数()调用MarkSweep类的成员函数ScanObjectVisit遍历参数obj指向的一个对象的引用类型的成员变量引用的对象，并且通过一个闭包函数来处理这些引用对象。闭包函数又是通过调用我们前面分析过的MarkSweep类的成员函数MarkObjectParallel来对对象obj的引用类型的成员变量引用的对象。如果这些引用对象之前没有被标记过，那么MarkSweep类的成员函数MarkObjectParallel就会返回true，这时候闭包函数将会调用MarkStackTask类的成员函数MarkStack将引用对象压入到其成员变量mark_stack_描述的一个Mark Stack去。注意，这个Mark Stack是MarkStackTask类在内部使用的一个Stack，它与ART运行时在启动时创建的Mark Stack是不一样的。

        此外，在将一个对象压入到MarkStackTask类的成员变量mark_stack_描述的一个Mark Stack去之前，如果这个Mark Stack已经满了，那么就会将这个Mark Stack的后半部分还未来得及递归标记的对象封装成一个MarkStackTask添加到线程池去执行递归标记。这样就可以将Mark Stack的大小减半，从而得以将参数obj指向的对象压入到Mark Stack中。

        回到RecursiveMarkTask类的成员函数Run中，它最后通过调过调用父类MarkStackTask的成员函数Run来递归标记保存其成员变量mark_stack_描述的Mark Stack中的对象，它的实现如下所示：

[cpp]  view plain copy
  1. template <bool kUseFinger = false>  
  2. class MarkStackTask : public Task {  
  3.  ......  
  4.   
  5.   // Scans all of the objects  
  6.   virtual void Run(Thread* self) {  
  7.     ScanObjectParallelVisitor visitor(this);  
  8.     // TODO: Tune this.  
  9.     static const size_t kFifoSize = 4;  
  10.     BoundedFifoPowerOfTwo<const Object*, kFifoSize> prefetch_fifo;  
  11.     for (;;) {  
  12.       const Object* obj = NULL;  

你可能感兴趣的:(老罗的Android之旅)

  • 斤斤计较的婚姻到底有多难？ 白心之岂必有为
    很多人私聊我会问到在哪个人群当中斤斤计较的人最多？我都会回答他，一般婚姻出现问题的斤斤计较的人士会非常多，以我多年经验，在婚姻落的一塌糊涂的人当中，斤斤计较的人数占比在20～30%以上，也就是说10个婚姻出现问题的斤斤计较的人有2-3个有多不减。在婚姻出问题当中，有大量的心理不平衡的、尖酸刻薄的怨妇。在婚姻中仅斤斤计较有两种类型：第一种是物质上的，另一种是精神上的。在物质与精神上抠门已经严重的影响
  • 情绪觉察日记第37天 露露_e800
    今天是家庭关系规划师的第二阶最后一天，慧萍老师帮我做了个案，帮我处理了埋在心底好多年的一份恐惧，并给了我深深的力量！这几天出来学习，爸妈过来婆家帮我带小孩，妈妈出于爱帮我收拾东西，并跟我先生和婆婆产生矛盾，妈妈觉得他们没有照顾好我…。今晚回家见到妈妈，我很欣赏她并赞扬她，妈妈说今晚要跟我睡我说好，当我们俩躺在床上准备睡觉的时候，我握着妈妈的手对她说:妈妈这几天辛苦你了，你看你多利害把我们的家收拾得
  • 芦花鞋一四 许叶晗
    又是在一个寒冷的夏日里，青铜和葵花决定今天一起去卖芦花鞋，奶奶亲手给他们做了一碗热乎乎的粥对他们说:“就靠你们两挣生活费了这碗粥赶紧趁热喝了吧！”于是青铜和葵花喝完了奶奶给她们做的粥，就准备去镇上卖卢花鞋，这回青铜和葵花穿着新的芦花鞋来到了镇上。青铜这回看到了很多人都在卖，用手势表达对葵花说:“这回有好多人在抢我们生意呢！我们必须得吆喝起来。”葵花点了点头。可是谁知他们也大声的叫，卖芦花喽！卖芦花
  • QQ群采集助手，精准引流必备神器 2401_87347160 其他经验分享
    功能概述微信群查找与筛选工具是一款专为微信用户设计的辅助工具，它通过关键词搜索功能，帮助用户快速找到相关的微信群，并提供筛选是否需要验证的群组的功能。主要功能关键词搜索：用户可以输入关键词，工具将自动查找包含该关键词的微信群。筛选功能：工具提供筛选机制，用户可以选择是否只显示需要验证或不需要验证的群组。精准引流：通过上述功能，用户可以更精准地找到目标群组，进行有效的引流操作。3.设备需求该工具可以
  • 关于沟通这件事，项目经理不需要每次都面对面进行 流程大师兄
    很多项目经理都会遇到这样的问题，项目中由于事情太多，根本没有足够的时间去召开会议，那在这种情况下如何去有效地管理项目中的利益相关者？当然，不建议电子邮件也不需要开会的话，建议可以采取下面几种方式来形成有效的沟通，这几种方式可以帮助你努力的通过各种办法来保持和各方面的联系。项目经理首先要问自己几个问题，项目中哪些利益相关者是必须要进行沟通的？可以列出项目中所有的利益相关者清单，同时也整理出项目中哪些
  • 机器学习与深度学习间关系与区别 ℒℴѵℯ心·动ꦿ໊ོ꫞ 人工智能学习深度学习python
    一、机器学习概述定义机器学习（MachineLearning,ML）是一种通过数据驱动的方法，利用统计学和计算算法来训练模型，使计算机能够从数据中学习并自动进行预测或决策。机器学习通过分析大量数据样本，识别其中的模式和规律，从而对新的数据进行判断。其核心在于通过训练过程，让模型不断优化和提升其预测准确性。主要类型1.监督学习（SupervisedLearning）监督学习是指在训练数据集中包含输入
  • android系统selinux中添加新属性property 辉色投像
    1.定位/android/system/sepolicy/private/property_contexts声明属性开头：persist.charge声明属性类型：u:object_r:system_prop:s0图12.定位到android/system/sepolicy/public/domain.te删除neverallow{domain-init}default_prop:property
  • 铭刻于星（四十二） 随风至
    69夜晚，绍敏同学做完功课后，看了眼房外，没听到动静才敢从书包的夹层里拿出那个心形纸团。折痕压得很深，都有些旧了，想来是已经写好很久了。绍敏同学慢慢地、轻轻地捏开折叠处，待到全部拆开后，又反复抚平纸张，然后仔细地一字字默看。只是开头的三个字是第一次看到，让她心漏跳了几拍。“亲爱的绍敏：从四年级的时候，我就喜欢你了，但是我一直不敢说，怕影响你学习。六年级的时候听说有人跟你表白，你接受了，我很难过，但
  • 底层逆袭到底有多难，不甘平凡的你准备好了吗？让吴起给你说说 造命者说
    底层逆袭到底有多难，不甘平凡的你准备好了吗？让吴起给你说说我叫吴起，生于公元前440年的战国初期，正是群雄并起、天下纷争不断的时候。后人说我是军事家、政治家、改革家，是兵家代表人物。评价我一生历仕鲁、魏、楚三国，通晓兵家、法家、儒家三家思想，在内政军事上都有极高的成就。周安王二十一年（公元前381年），因变法得罪守旧贵族，被人乱箭射死。我出生在卫国一个“家累万金”的富有家庭，从年轻时候起就不甘平凡
  • 2020-01-25 晴岚85
    郑海燕坚持分享590天2020.1.24在生活中只存在两个问题。一个问题是：你知道想要达成的目标是什么，但却不知道如何才能达成；另一个问题是：你不知道你的目标是什么。前一个是行动的问题，后一个是结果的问题。通过制定具体的下一步行动，可以解决不知道如何开始行动的问题。而通过去想象结果，对结果做预估，可以解决找不着目标的问题。对于所有吸引我们注意力，想要完成的任务，你可以先想象一下，预期的结果究竟是什
  • 随笔 | 仙一般的灵气 海思沧海
    仙岛今天，我看了你全部，似乎已经进入你的世界我不知道，这是否是梦幻，还是你仙一般的灵气吸引了我也许每一个人都要有一份属于自己的追求，这样才能够符合人生的梦想，生活才能够充满着阳光与快乐我不知道，我为什么会这样的感叹，是在感叹自己的人生，还是感叹自己一直没有孜孜不倦的追求只感觉虚度了光阴，每天活在自己的梦中，活在一个不真实的世界是在逃避自己，还是在逃避周围的一切有时候我嘲笑自己，嘲笑自己如此的虚无，
  • 想家 爆米花机
    也许不同于大家对家乡的思念，我对家乡甚至是疯狂的不舍。还未踏出车站就感觉到幸福，我享受这里的夕阳、这里的浓烈柴火味、这里每一口家常菜。我是宅女，我贪恋家的安逸。刚刚踏出大学校门，初出茅庐，无法适应每年只能国庆和春节回家。我焦虑、失眠、无端发脾气，是无法适应工作的节奏，是无法接受我将一步步离开家乡的事实。我不想承认自己胸无大志，选择再次踏上征程。图片发自App
  • 【iOS】MVC设计模式 Magnetic_h iosmvc设计模式objective-c学习ui
    MVC前言如何设计一个程序的结构，这是一门专门的学问，叫做"架构模式"（architecturalpattern），属于编程的方法论。MVC模式就是架构模式的一种。它是Apple官方推荐的App开发架构，也是一般开发者最先遇到、最经典的架构。MVC各层controller层Controller/ViewController/VC（控制器）负责协调Model和View，处理大部分逻辑它将数据从Mod
  • OC语言多界面传值五大方式 Magnetic_h iosui学习objective-c开发语言
    前言在完成暑假仿写项目时，遇到了许多需要用到多界面传值的地方，这篇博客来总结一下比较常用的五种多界面传值的方式。属性传值属性传值一般用前一个界面向后一个界面传值，简单地说就是通过访问后一个视图控制器的属性来为它赋值，通过这个属性来做到从前一个界面向后一个界面传值。首先在后一个界面中定义属性@interfaceBViewController:UIViewController@propertyNSSt
  • 一百九十四章. 自相矛盾 巨木擎天
    唉！就这么一夜，林子感觉就像过了很多天似的，先是回了阳间家里，遇到了那么多不可思议的事情儿。特别是小伙伴们，第二次与自己见面时，僵硬的表情和恐怖的气氛，让自己如坐针毡，打从心眼里难受！还有东子，他现在还好吗？有没有被人欺负？护城河里的小鱼小虾们，还都在吗？水不会真的干枯了吧？那对相亲相爱漂亮的太平鸟儿，还好吧！春天了，到了做窝、下蛋、喂养小鸟宝宝的时候了，希望它们都能够平安啊！虽然没有看见家人，也
  • UI学习——cell的复用和自定义cell Magnetic_h ui学习
    目录cell的复用手动（非注册）自动（注册）自定义cellcell的复用在iOS开发中，单元格复用是一种提高表格（UITableView）和集合视图（UICollectionView）滚动性能的技术。当一个UITableViewCell或UICollectionViewCell首次需要显示时，如果没有可复用的单元格，则视图会创建一个新的单元格。一旦这个单元格滚动出屏幕，它就不会被销毁。相反，它被添
  • element实现动态路由+面包屑 软件技术NINI vue案例vue.js前端
    el-breadcrumb是ElementUI组件库中的一个面包屑导航组件，它用于显示当前页面的路径，帮助用户快速理解和导航到应用的各个部分。在Vue.js项目中，如果你已经安装了ElementUI，就可以很方便地使用el-breadcrumb组件。以下是一个基本的使用示例：安装ElementUI（如果你还没有安装的话）:你可以通过npm或yarn来安装ElementUI。bash复制代码npmi
  • 10月|愿你的青春不负梦想-读书笔记-01 Tracy的小书斋
    本书的作者是俞敏洪，大家都很熟悉他了吧。俞敏洪老师是我行业的领头羊吧，也是我事业上的偶像。本日摘录他书中第一章中的金句：『一个人如果什么目标都没有，就会浑浑噩噩，感觉生命中缺少能量。能给我们能量的，是对未来的期待。第一件事，我始终为了进步而努力。与其追寻全世界的骏马，不如种植丰美的草原，到时骏马自然会来。第二件事，我始终有阶段性的目标。什么东西能给我能量？答案是对未来的期待。』读到这里的时候，我便
  • C语言宏函数 南林yan C语言c语言
    一、什么是宏函数？通过宏定义的函数是宏函数。如下，编译器在预处理阶段会将Add(x,y)替换为((x)*(y))#defineAdd(x,y)((x)*(y))#defineAdd(x,y)((x)*(y))intmain(){inta=10;intb=20;intd=10;intc=Add(a+d,b)*2;cout<
  • 地推话术，如何应对地推过程中家长的拒绝 校师学
    相信校长们在做地推的时候经常遇到这种情况：市场专员反馈家长不接单，咨询师反馈难以邀约这些家长上门，校区地推疲软，招生难。为什么？仅从地推层面分析，一方面因为家长受到的信息轰炸越来越多，对信息越来越“免疫”；而另一方面地推人员的专业能力和营销话术没有提高，无法应对家长的拒绝，对有意向的家长也不知如何跟进，眼睁睁看着家长走远；对于家长的疑问，更不知道如何有技巧地回答，机会白白流失。由于回答没技巧和专业
  • 谢谢你们，爱你们！ 鹿游儿
    昨天家人去泡温泉，二个孩子也带着去，出发前一晚，匆匆下班，赶回家和孩子一起收拾。饭后，我拿出笔和本子（上次去澳门时做手帐的本子）写下了1\2\3\4\5\6\7\8\9,让后让小壹去思考，带什么出发去旅游呢？她在对应的数字旁边画上了，泳衣、泳圈、肖恩、内衣内裤、tapuy、拖鞋……画完后，就让她自己对着这个本子，将要带的，一一带上，没想到这次带的书还是这本《便便工厂》(晚上姑婆发照片过来，妹妹累得
  • C语言如何定义宏函数？ 小九格物 c语言
    在C语言中，宏函数是通过预处理器定义的，它在编译之前替换代码中的宏调用。宏函数可以模拟函数的行为，但它们不是真正的函数，因为它们在编译时不会进行类型检查，也不会分配存储空间。宏函数的定义通常使用#define指令，后面跟着宏的名称和参数列表，以及宏展开后的代码。宏函数的定义方式：1.基本宏函数：这是最简单的宏函数形式，它直接定义一个表达式。#defineSQUARE(x)((x)*(x))2.带参
  • 微服务下功能权限与数据权限的设计与实现 nbsaas-boot 微服务java架构
    在微服务架构下，系统的功能权限和数据权限控制显得尤为重要。随着系统规模的扩大和微服务数量的增加，如何保证不同用户和服务之间的访问权限准确、细粒度地控制，成为设计安全策略的关键。本文将讨论如何在微服务体系中设计和实现功能权限与数据权限控制。1.功能权限与数据权限的定义功能权限：指用户或系统角色对特定功能的访问权限。通常是某个用户角色能否执行某个操作，比如查看订单、创建订单、修改用户资料等。数据权限：
  • 理解Gunicorn：Python WSGI服务器的基石 范范0825 ipythonlinux运维
    理解Gunicorn：PythonWSGI服务器的基石介绍Gunicorn，全称GreenUnicorn，是一个为PythonWSGI（WebServerGatewayInterface）应用设计的高效、轻量级HTTP服务器。作为PythonWeb应用部署的常用工具，Gunicorn以其高性能和易用性著称。本文将介绍Gunicorn的基本概念、安装和配置，帮助初学者快速上手。1.什么是Gunico
  • 小丽成长记（四十三） 玲玲54321
    小丽发现，即使她好不容易调整好自己的心态下一秒总会有不确定的伤脑筋的事出现，一个接一个的问题，人生就没有停下的时候，小问题不断出现。不过她今天看的书，她接受了人生就是不确定的，厉害的人就是不断创造确定性，在Ta的领域比别人多的确定性就能让自己脱颖而出，显示价值从而获得的比别人多的利益。正是这样的原因，因为从前修炼自己太少，使得她现在在人生道路上打怪起来困难重重，她似乎永远摆脱不了那种无力感，有种习
  • 学点心理知识，呵护孩子健康 静候花开_7090
    昨天听了华中师范大学教育管理学系副教授张玲老师的《哪里才是学生心理健康的最后庇护所，超越教育与技术的思考》的讲座。今天又重新学习了一遍，收获匪浅。张玲博士也注意到了当今社会上的孩子由于心理问题导致的自残、自杀及伤害他人等恶性事件。她向我们普及了一个重要的命题，她说心理健康的一些基本命题，我们与我们通常的一些教育命题是不同的，她还举了几个例子，让我们明白我们原来以为的健康并非心理学上的健康。比如如果
  • 2021年12月19日，春蕾教育集团团建活动感受——黄晓丹 黄错错加油
    感受:1.从陌生到熟悉的过程。游戏环节让我们在轻松的氛围中得到了锻炼，也增长了不少知识。2.游戏过程中，我们贡献的是个人力量，展现的是团队的力量。它磨合的往往不止是工作的熟悉，更是观念上契合度的贴近。3.这和工作是一样的道理。在各自的岗位上，每个人摆正自己的位置、各司其职充分发挥才能，并团结一致劲往一处使，才能实现最大的成功。新知:1.团队精神需要不断地创新。过去，人们把创新看作是冒风险，现在人们
  • Cell Insight | 单细胞测序技术又一新发现，可用于HIV-1和Mtb共感染个体诊断 尐尐呅
    结核病是艾滋病合并其他疾病中导致患者死亡的主要原因。其中结核病由结核分枝杆菌（Mycobacteriumtuberculosis,Mtb）感染引起，获得性免疫缺陷综合症（艾滋病）由人免疫缺陷病毒（Humanimmunodeficiencyvirustype1,HIV-1）感染引起。国家感染性疾病临床医学研究中心/深圳市第三人民医院张国良团队携手深圳华大生命科学研究院吴靓团队，共同研究得出单细胞测序
  • c++ 的iostream 和 c++的stdio的区别和联系 黄卷青灯77 c++算法开发语言iostreamstdio
    在C++中，iostream和C语言的stdio.h都是用于处理输入输出的库，但它们在设计、用法和功能上有许多不同。以下是两者的区别和联系：区别1.编程风格iostream（C++风格）：C++标准库中的输入输出流类库，支持面向对象的输入输出操作。典型用法是cin（输入）和cout（输出），使用>操作符来处理数据。更加类型安全，支持用户自定义类型的输入输出。#includeintmain(){in
  • 瑶池防线 谜影梦蝶
    冥华虽然逃过了影梦的军队，但他是一个忠臣，他选择上报战况。败给影梦后成逃兵，高层亡尔还活着，七重天失守......随便一条，即可处死冥华。冥华自然是知道以仙界高层的习性此信一发自己必死无疑，但他还选择上报实情，因为责任。同样此信送到仙宫后，知道此事的人，大多数人都认定冥华要完了，所以上到仙界高层，下到扫大街的，包括冥华自己，全都准备好迎接冥华之死。如果仙界现在还属于两方之争的话，冥华必死无疑。然而
  • LeetCode[位运算] - #137 Single Number II Cwind javaAlgorithmLeetCode题解位运算
    原题链接：#137 Single Number II  要求： 给定一个整型数组，其中除了一个元素之外，每个元素都出现三次。找出这个元素 注意：算法的时间复杂度应为O(n)，最好不使用额外的内存空间   难度：中等   分析： 与#136类似，都是考察位运算。不过出现两次的可以使用异或运算的特性 n XOR n = 0, n XOR 0 = n，即某一
  • 《JavaScript语言精粹》笔记 aijuans JavaScript
    0、JavaScript的简单数据类型包括数字、字符创、布尔值（true/false）、null和undefined值，其它值都是对象。 1、JavaScript只有一个数字类型，它在内部被表示为64位的浮点数。没有分离出整数，所以1和1.0的值相同。 2、NaN是一个数值，表示一个不能产生正常结果的运算结果。NaN不等于任何值，包括它本身。可以用函数isNaN(number)检测NaN,但是
  • 你应该更新的Java知识之常用程序库 Kai_Ge java
    在很多人眼中，Java 已经是一门垂垂老矣的语言，但并不妨碍 Java 世界依然在前进。如果你曾离开 Java，云游于其它世界，或是每日只在遗留代码中挣扎，或许是时候抬起头，看看老 Java 中的新东西。 Guava Guava[gwɑ:və]，一句话，只要你做Java项目，就应该用Guava（Github）。 guava 是 Google 出品的一套 Java 核心库，在我看来，它甚至应该
  • HttpClient 120153216 httpclient
    /** * 可以传对象的请求转发，对象已流形式放入HTTP中 */ public static Object doPost(Map<String,Object> parmMap,String url) { Object object = null; HttpClient hc = new HttpClient(); String fullURL
  • Django model字段类型清单 2002wmj django
    Django 通过 models 实现数据库的创建、修改、删除等操作，本文为模型中一般常用的类型的清单，便于查询和使用： AutoField：一个自动递增的整型字段，添加记录时它会自动增长。你通常不需要直接使用这个字段；如果你不指定主键的话，系统会自动添加一个主键字段到你的model。(参阅自动主键字段) BooleanField：布尔字段,管理工具里会自动将其描述为checkbox。 Cha
  • 在SQLSERVER中查找消耗CPU最多的SQL 357029540 SQL Server
    返回消耗CPU数目最多的10条语句 SELECT TOP 10    total_worker_time/execution_count AS avg_cpu_cost, plan_handle,    execution_count,    (SELECT SUBSTRING(text, statement_start_of
  • Myeclipse项目无法部署，Undefined exploded archive location 7454103 eclipseMyEclipse
    做个备忘！ 错误信息为：       Undefined exploded archive location 原因：           在工程转移过程中，导致工程的配置文件出错； 解决方法：    
  • GMT时间格式转换 adminjun GMT时间转换
    普通的时间转换问题我这里就不再罗嗦了，我想大家应该都会那种低级的转换问题吧，现在我向大家总结一下如何转换GMT时间格式，这种格式的转换方法网上还不是很多，所以有必要总结一下，也算给有需要的朋友一个小小的帮助啦。 1、可以使用 SimpleDateFormat SimpleDateFormat    EEE-三位星期 d-天 MMM-月 yyyy-四位年
  • Oracle数据库新装连接串问题 aijuans oracle数据库
    割接新装了数据库，客户端登陆无问题，apache/cgi-bin程序有问题，sqlnet.log日志如下： Fatal NI connect error 12170.   VERSION INFORMATION:         TNS for Linux: Version 10.2.0.4.0 - Product
  • 回顾java数组复制 ayaoxinchao java数组
    在写这篇文章之前，也看了一些别人写的，基本上都是大同小异。文章是对java数组复制基础知识的回顾，算是作为学习笔记，供以后自己翻阅。首先，简单想一下这个问题：为什么要复制数组？我的个人理解：在我们在利用一个数组时，在每一次使用，我们都希望它的值是初始值。这时我们就要对数组进行复制，以达到原始数组值的安全性。java数组复制大致分为3种方式：①for循环方式 ②clone方式 ③arrayCopy方
  • java web会话监听并使用spring注入 bewithme Java Web
            在java web应用中，当你想在建立会话或移除会话时，让系统做某些事情，比如说，统计在线用户，每当有用户登录时，或退出时，那么可以用下面这个监听器来监听。        import java.util.ArrayList; import java.ut
  • NoSQL数据库之Redis数据库管理(Redis的常用命令及高级应用) bijian1013 redis数据库NoSQL
    一 .Redis常用命令         Redis提供了丰富的命令对数据库和各种数据库类型进行操作，这些命令可以在Linux终端使用。         a.键值相关命令         b.服务器相关命令 1.键值相关命令       &
  • java枚举序列化问题 bingyingao java枚举序列化
    对象在网络中传输离不开序列化和反序列化。而如果序列化的对象中有枚举值就要特别注意一些发布兼容问题: 1.加一个枚举值 新机器代码读分布式缓存中老对象，没有问题，不会抛异常。 老机器代码读分布式缓存中新对像，反序列化会中断，所以在所有机器发布完成之前要避免出现新对象，或者提前让老机器拥有新增枚举的jar。 2.删一个枚举值 新机器代码读分布式缓存中老对象，反序列
  • 【Spark七十八】Spark Kyro序列化 bit1129 spark
    当使用SparkContext的saveAsObjectFile方法将对象序列化到文件，以及通过objectFile方法将对象从文件反序列出来的时候，Spark默认使用Java的序列化以及反序列化机制，通常情况下，这种序列化机制是很低效的，Spark支持使用Kyro作为对象的序列化和反序列化机制，序列化的速度比java更快，但是使用Kyro时要注意，Kyro目前还是有些bug。 Spark
  • Hybridizing OO and Functional Design bookjovi erlanghaskell
      推荐博文： Tell Above, and Ask Below - Hybridizing OO and Functional Design 文章中把OO和FP讲的深入透彻，里面把smalltalk和haskell作为典型的两种编程范式代表语言，此点本人极为同意，smalltalk可以说是最能体现OO设计的面向对象语言，smalltalk的作者Alan kay也是OO的最早先驱，
  • Java-Collections Framework学习与总结-HashMap BrokenDreams Collections
            开发中常常会用到这样一种数据结构，根据一个关键字，找到所需的信息。这个过程有点像查字典，拿到一个key，去字典表中查找对应的value。Java1.0版本提供了这样的类java.util.Dictionary(抽象类)，基本上支持字典表的操作。后来引入了Map接口，更好的描述的这种数据结构。  &nb
  • 读《研磨设计模式》-代码笔记-职责链模式-Chain Of Responsibility bylijinnan java设计模式
    声明： 本文只为方便我个人查阅和理解，详细的分析以及源代码请移步 原作者的博客http://chjavach.iteye.com/ /** * 业务逻辑：项目经理只能处理500以下的费用申请，部门经理是1000，总经理不设限。简单起见，只同意“Tom”的申请 * bylijinnan */ abstract class Handler { /*
  • Android中启动外部程序 cherishLC android
    1、启动外部程序 引用自： http://blog.csdn.net/linxcool/article/details/7692374 //方法一 Intent intent=new Intent(); //包名 包名+类名（全路径） intent.setClassName("com.linxcool", "com.linxcool.PlaneActi
  • summary_keep_rate coollyj SUM
    BEGIN /*DECLARE minDate varchar(20) ; DECLARE maxDate varchar(20) ;*/ DECLARE stkDate varchar(20) ; DECLARE done int default -1; /* 游标中 注册服务器地址 */ DE
  • hadoop hdfs 添加数据目录出错 daizj hadoophdfs扩容
    由于原来配置的hadoop data目录快要用满了，故准备修改配置文件增加数据目录，以便扩容，但由于疏忽，把core-site.xml, hdfs-site.xml配置文件dfs.datanode.data.dir 配置项增加了配置目录，但未创建实际目录，重启datanode服务时，报如下错误： 2014-11-18 08:51:39,128 WARN org.apache.hadoop.h
  • grep 目录级联查找 dongwei_6688 grep
           在Mac或者Linux下使用grep进行文件内容查找时，如果给定的目标搜索路径是当前目录，那么它默认只搜索当前目录下的文件，而不会搜索其下面子目录中的文件内容，如果想级联搜索下级目录，需要使用一个“-r”参数： grep -n -r "GET" .   上面的命令将会找出当前目录“.”及当前目录中所有下级目录
  • yii 修改模块使用的布局文件 dcj3sjt126com yiilayouts
    方法一：yii模块默认使用系统当前的主题布局文件，如果在主配置文件中配置了主题比如: 'theme'=>'mythm', 那么yii的模块就使用 protected/themes/mythm/views/layouts 下的布局文件； 如果未配置主题，那么 yii的模块就使用  protected/views/layouts 下的布局文件， 总之默认不是使用自身目录 pr
  • 设计模式之单例模式 come_for_dream 设计模式单例模式懒汉式饿汉式双重检验锁失败无序写入
                    今天该来的面试还没来，这个店估计不会来电话了，安静下来写写博客也不错，没事翻了翻小易哥的博客甚至与大牛们之间的差距，基础知识不扎实建起来的楼再高也只能是危楼罢了，陈下心回归基础把以前学过的东西总结一下。   *********************************
  • 8、数组 豆豆咖啡 二维数组数组一维数组
      一、概念       数组是同一种类型数据的集合。其实数组就是一个容器。   二、好处       可以自动给数组中的元素从0开始编号，方便操作这些元素   三、格式   //一维数组 1,元素类型[] 变量名 = new 元素类型[元素的个数] int[] arr =
  • Decode Ways hcx2013 decode
    A message containing letters from A-Z is being encoded to numbers using the following mapping: 'A' -> 1 'B' -> 2 ... 'Z' -> 26 Given an encoded message containing digits, det
  • Spring4.1新特性——异步调度和事件机制的异常处理 jinnianshilongnian spring 4.1
    目录 Spring4.1新特性——综述 Spring4.1新特性——Spring核心部分及其他 Spring4.1新特性——Spring缓存框架增强 Spring4.1新特性——异步调用和事件机制的异常处理 Spring4.1新特性——数据库集成测试脚本初始化 Spring4.1新特性——Spring MVC增强 Spring4.1新特性——页面自动化测试框架Spring MVC T
  • squid3(高命中率)缓存服务器配置 liyonghui160com
        系统:centos 5.x   需要的软件:squid-3.0.STABLE25.tar.gz 1.下载squid wget http://www.squid-cache.org/Versions/v3/3.0/squid-3.0.STABLE25.tar.gz tar zxf squid-3.0.STABLE25.tar.gz &&
  • 避免Java应用中NullPointerException的技巧和最佳实践 pda158 java
    1) 从已知的String对象中调用equals()和equalsIgnoreCase()方法，而非未知对象。 　　总是从已知的非空String对象中调用equals()方法。因为equals()方法是对称的，调用a.equals(b)和调用b.equals(a)是完全相同的，这也是为什么程序员对于对象a和b这么不上心。如果调用者是空指针，这种调用可能导致一个空指针异常 Object unk
  • 如何在Swift语言中创建http请求 shoothao httpswift
    概述：本文通过实例从同步和异步两种方式上回答了”如何在Swift语言中创建http请求“的问题。 如果你对Objective-C比较了解的话，对于如何创建http请求你一定驾轻就熟了，而新语言Swift与其相比只有语法上的区别。但是，对才接触到这个崭新平台的初学者来说，他们仍然想知道“如何在Swift语言中创建http请求？”。 在这里,我将作出一些建议来回答上述问题。常见的
  • Spring事务的传播方式 uule spring事务
    传播方式：        新建事务       required       required_new   - 挂起当前         非事务方式运行       supports   &nbs
按字母分类： ABCDEFGHIJKLMNOPQRSTUVWXYZ其他