在JavaOne 2009上，Sun发布了Java SE 6 Update 14，其中包括备受期待的Garbage First（G1）垃圾收集器版本。 G1是一个低暂停，低延迟，有时是软实时收集器，允许您通过Java VM命令行上的建议设置最大暂停时间目标和收集间隔。虽然无法保证，但G1会尝试达到您的目标，因此会尽可能减少延迟时间。这反过来也可能使VM在尝试满足您提供的暂停时间目标时更加可预测。
什么是垃圾收集？
许多动态语言（如C，C ++，Pascal等）都要求您明确管理内存。这包括内存分配，解除分配以及介于两者之间的所有记帐。在这个时间范围内，您必须确保不会丢失内存跟踪（从而无法释放内存），否则结果将是内存泄漏。同样危险的是在通过所谓的悬空指针取消分配后使用对象（或访问存储器）的尝试。这些情况中的任何一种都可能导致未定义的行为，意外覆盖其他数据，安全漏洞或突然崩溃。
自动内存管理（垃圾收集）消除了这些问题发生的可能性，因为它不再需要您考虑内存分配。在C ++中，智能指针的概念是一种解决方案，而在其他语言中，如Lisp，SmallTalk和Java，功能齐全的垃圾收集器跟踪正在运行的程序中所有对象的生命周期。垃圾收集的历史可以追溯到John McCarthy，他将这个概念发明为Lisp编程语言[McCarthy58]的一部分。
简而言之，垃圾收集器用于回收永远不会再次访问的应用程序中的内存区域。在最基本的层面上，垃圾收集涉及两个欺骗性的简单步骤：
确定应用程序无法再引用哪些对象。这可以通过对象引用计数或对象图（跟踪）来完成。回收死对象（垃圾）占用的内存。
直到最近，Java SE还带有两个主要收集器：并行收集器和并发标记扫描（CMS）收集器, 从最新的Java SE 6更新版本开始，G1收集器是另一种选择。计划是G1最终取代CMS作为低暂停，软实时收集器。我们来看看它是如何工作的。
并行和并发
在谈到垃圾收集算法时，并行性描述了收集器跨多个执行线程执行其工作的能力。 并发性描述了它在应用程序线程仍在运行时执行工作的能力。 因此，收集器可以是并行但不并发，并发但不并行，或者并行和并发。
Java并行收集器（默认）是并行的，但不是并发的，因为它会暂停应用程序线程来完成其工作。 CMS收集器是并行且部分并发的，因为它在许多点（但不是全部）暂停应用程序线程来完成其工作。 G1收集器完全并行且大部分是并发的，这意味着它会暂时暂停应用程序线程，但仅限于收集的某些阶段。
G1垃圾收集器
Garbage-First（G1）收集器是一种服务器式垃圾收集器，适用于具有大容量存储器的多处理器机器。它以高概率满足垃圾收集（GC）暂停时间目标，同时实现高吞吐量。 Oracle JDK 7 Update 4及更高版本完全支持G1垃圾收集器。 G1收集器专为以下应用而设计：
可以与CMS收集器等应用程序线程同时运行。
紧凑的自由空间，没有长时间的GC引起的暂停时间
需要更多可预测的GC暂停持续时间。
不想牺牲很多吞吐量性能。
不需要更大的Java堆。
G1计划作为Concurrent Mark-Sweep Collector（CMS）的长期替代品。将G1与CMS进行比较，存在差异，使G1成为更好的解决方案。一个区别是G1是压缩收集器。 G1足够紧凑以完全避免使用细粒度的自由列表进行分配，而是依赖于区域。这大大简化了收集器的各个部分，并且主要消除了潜在的碎片问题。此外，G1提供比CMS收集器更可预测的垃圾收集暂停，并允许用户指定所需的暂停目标。
G1运营概览
旧的垃圾收集器（串行，并行，CMS）都将堆构建为三个部分：年轻代，旧代和永久生成固定内存大小。
堆被分区为一组大小相等的堆区域，每个区域都是一个连续的虚拟内存区域。某些区域集具有与旧收集器中相同的角色（eden，survivor，old），但它们没有固定的大小。这为内存使用提供了更大的灵活性。
执行垃圾收集时，G1以类似于CMS收集器的方式运行。 G1执行并发全局标记阶段以确定整个堆中对象的活跃度。在标记阶段完成之后，G1知道哪些区域基本上是空的。它首先收集在这些区域，这通常会产生大量的自由空间。这就是为什么这种垃圾收集方法称为Garbage-First。顾名思义，G1将其收集和压缩活动集中在堆的可能充满可回收对象的区域，即垃圾。 G1使用暂停预测模型来满足用户定义的暂停时间目标，并根据指定的暂停时间目标选择要收集的区域数。
由G1确定为回收成熟的区域是使用疏散收集的垃圾。 G1将对象从堆的一个或多个区域复制到堆上的单个区域，并且在此过程中压缩并释放内存。这种疏散在多处理器上并行执行，以减少暂停时间并提高吞吐量。因此，对于每次垃圾收集，G1会持续工作以减少碎片，在用户定义的暂停时间内工作。这超出了以前两种方法的能力。 CMS（Concurrent Mark Sweep）垃圾收集器不进行压缩。 ParallelOld垃圾收集仅执行整堆压缩，这会导致相当长的暂停时间。
值得注意的是G1不是实时收集器。它以高概率但不是绝对确定性满足设定的暂停时间目标。基于先前集合的数据，G1估计可以在用户指定的目标时间内收集多少个区域。因此，收集器具有收集区域的成本的相当准确的模型，并且它使用该模型来确定在停留在暂停时间目标内时要收集哪些区域和多少区域。
注意：G1具有并发（与应用程序线程一起运行，例如，细化，标记，清理）和并行（多线程，例如，停止世界）阶段。完全垃圾收集仍然是单线程的，但如果正确调整，您的应用程序应该避免使用完整的GC。
G1足迹
如果从ParallelOldGC或CMS收集器迁移到G1，您可能会看到更大的JVM进程大小。这主要与“会计”数据结构有关，例如记忆集和集合集。
记住集或RSet跟踪对象引用到给定区域。堆中每个区域有一个RSet。 RSet支持并行和独立收集区域。 RSets的总体足迹影响小于5％。
集合设置或CSets将在GC中收集的区域集。在GC期间，CSet中的所有实时数据都被撤离（复制/移动）。区域集可以是伊甸园，幸存者和/或老一代。 CSets对JVM的大小影响不到1％。
推荐的G1用例
G1的第一个重点是为运行需要具有有限GC延迟的大堆的应用程序的用户提供解决方案。这意味着堆大小约为6GB或更大，稳定且可预测的暂停时间低于0.5秒。
如果应用程序具有以下一个或多个特征，那么今天使用CMS或ParallelOldGC垃圾收集器运行的应用程序将有利于切换到G1。
完整的GC持续时间太长或太频繁。
对象分配率或促销率差异很大。
不期望的长垃圾收集或压实暂停（超过0.5到1秒）
注意：如果您使用的是CMS或ParallelOldGC，并且您的应用程序没有经历长时间的垃圾收集暂停，那么与您当前的收集器保持联系是可以的。更改为G1收集器不是使用最新JDK的必要条件。