介绍
Oracle JDK 7 update 4以及之后的版本已经完全支持G1垃圾收集器了。G1收集器是一个服务器式的垃圾收集器，适合用于多处理器和大内存的机器。它能很大概率上满足你所设置的GC暂停时间，同时实现高吞吐量。类似于内存垃圾标记这样的全堆操作，可以和应用程序线程同时执行。这样避免了和堆及存活数据大小成正比的中断用户线程操作。
技术说明
G1收集器通过多种技术实现了高性能和目标暂停时间。
堆被划分为一组大小相等的区域，每个区域都是连续的虚拟内存。G1通过并发的全局标记阶段来确定整个堆上对象的存活性。在标记阶段结束后，G1知道哪些区域的空闲空间是最大的。它将首先在这些区域进行进行收集，这样就能腾出大量的可用内存空间。这就是为什么这种垃圾收集方法叫Garbage-First。顾名思义，G1关注在那些充满了可回收对象（也就是内存垃圾）的堆区域进行收集和整理。G1使用暂停预测模型来满足用户定义的暂停时间目标，并根据设定的目标暂停时间来选择相应的区域。
这些被G1选中的区域被认为是成熟的可回收内存垃圾。G1把一个或多个堆区域的对象复制到另一个堆区域上，同时进行内存整理和释放。这个释放过程是在多处理器上并行执行的，以减少暂停时间并提高吞吐量。所以，每次垃圾收集时G1会在满足用户定义的暂停时间的基础上连续运行来减少内存碎片。这种方法优于之前的垃圾回收方法。CMS（并发标记扫描）垃圾收集器并不会做内存整理。ParallelOld垃圾收集器只执行全堆压缩整理，这将导致大量的暂停时间。
要注意的是G1并不是一个实时的收集器。它在很大概率上会满足设置的暂停时间但是并不绝对准确。基于之前的收集情况，G1能估计出在用户给定的时间内能回收多少个区域。因此G1对区域的收集成本有一个相对精确的模型，并使用这个模型来推算在给定的暂停时间内能回收哪几个区域。
要获取更多的G1使用配置信息请查阅命令行选项
推荐使用G1的案例
G1主要为那些运行需要大型堆并且对GC延迟时间有要求的应用提供了解决方案。这意味着可以在堆大小在6GB或更大，并且要保持稳定可预测的暂停时间在0.5秒以下的情况下使用G1。
那些现在使用CMS或者ParallelOld垃圾收集器的运行着的应用如果具备以下一个或多少特征，将在切换到G1后受益：
Java堆 的50%以上被实时数据占用
对象的分配率或者晋升变化明显
不希望有长时间的GC或压缩整理时间停顿（大于0.5到1秒）
未来
G1在长远的计划上会替代CMS。两者相比来说，G1有更好的解决方案上的差异。一个差异就是G1是一个压缩的收集器，G1的压缩完全有效地避免了细粒度空闲列表的分配，取而代之的是依赖于区域。这大大简化了大部分的收集器，并且有效消除了潜在的内存碎片问题。另一方面，相比CMS来说G1提供了更可预测的垃圾回收暂停时间，并允许用户定义期望的暂停时间。
译自：http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html