转自 微信聊聊架构 GC...
早在三年前，Red Hat就启动了Shenandoah项目。Shenandoah是一种新的Java虚拟机GC算法，目标是利用现代多核CPU的优势，减少大堆内存在GC方面存在的停顿时间。Shenandoah后来被贡献给了OpenJDK，正式成为OpenJDK的开源项目，也就是JEP 189。
总的来说，大部分垃圾回收器要么使用古老的标记并清除算法，要么使用分代算法，再结合并发和堆压缩。垃圾回收器多种多样，但没有一种回收器能够满足所有的需求，它们总要在某些方面做出折衷，并且不可避免地存在停顿时间。而Shenandoah最大的两个特点是它伸缩性和超低停顿时间。
Shenandoah最初的目标是把GC停顿时间降到10毫秒以下，并且对内存的支持扩展到TB级别。为了降低停顿时间，回收器需要使用更多的线程来并行处理回收任务。而要在降低停顿时间的同时能够支持更大的堆空间，回收器对CPU的多核处理能力提出了更高的要求。相比于CMS和G1，Shenandoah不仅进行并行的垃圾标记，在压缩堆空间时也是并行进行的。
Shenandoah把堆空间分为很多区域，例如整个堆空间是1G，如果每个区域是1M，那么就会有1000多个区域。传统的标记并清除回收器并没有区域的概念，而拷贝回收器一般也只有两个或少数几个区域。通过更细粒度的分区，Shenandoah可以优先对包含更多垃圾的区域进行回收，同时有助于并行回收工作的进行。
Shenandoah是一个标记拷贝回收器，它的回收工作分为两个阶段。第一个阶段是标记阶段。在这个阶段，回收器会对每个区域里的对象进行标记，并计算它们的数量。第二个阶段，回收器对源区域的对象进行扫描，并把存活对象拷贝到目标区域，然后源区域的内存就可以被释放。这两个阶段看似很简单，但要让整个过程并行进行，从而降低停顿时间，事情就会变得复杂很多。
到目前为止，Shenandoah已经实现了很多特性，包括运行时、解释器、C1屏障和C2屏障、对弱引用的支持、对JNI临界区域的支持、对System.gc()的支持，等等。Shenandoah目前还算稳定，它的平均性能能够达到G1的90%，有时候会差一些，比如70%，不过有时候会超过G1，比如150%。不过Shenandoah的停顿时间比G1要短很多，不过相比之前定下的目标，还有很大距离。
目前还没有把Shenandoah用在Java 9里的计划，不过如果有人对此感兴趣，可以自己从源代码构建特别版本的JDK来体验Shenandoah。关于更多Shenandoah的细节可以在这里看到。
不过，从Shenandoah的目标来看，它更适合用在大堆上。所以，如果CPU资源有限，内存也不大，比如小于20G，那么就没有必要使用Shenandoah。
文末推荐一篇谈垃圾回收历史以及现状的文章，详细介绍了GC的发展历史，以及各个阶段的痛点，相信看完你会对GC有更多立体式的认识。