甲骨文公司表示低暂停G1垃圾回收机制将在取代Parallel GC提高系统执行效率。
目前甲骨文正计划将G1服务器垃圾回收机制作为32位与64位Java服务器配置方案中的默认回收选项，但这种处理方式可能带来一系列后续问题。
正如于今年早些时候***发布并于本月刚刚进行了更新的JEP（即JDK增强方案）248所指出，此次回收机制变更的动机在于将暂停时间引入内存管理。“一般来讲，限制GC暂停时间要比***限度提升吞吐能力更为重要，”这份建议指出。“而选择G1这类低暂停垃圾回收方案应该能够为大多数用户带来更出色的整体使用体验——至少相较于主要面向吞吐能力的当前默认选项Parallel GC是如此。……此次变更主要基于一项假设，即限制延迟水平通常要优先于提升吞吐能力。如果这一假设并不准确，那么此次调整可能无法带来理想的效果、甚至需要重新加以审视。”
甲骨文方面的计划是将G1部署在将于明年推出的Java 9当中。在JDK（即Java开发工具）8及其后续更新版本当中，G1已经迎来了多项性能改进。而根据JEP文档的说法，其应该还会在JDK 9内得到进一步提升。
甲骨文公司的一份说明文档指出，G1的定位是专门面向拥有大容量内存及多处理器设备的服务器型垃圾收集方案。不过将其作为默认收集机制可能会暴露出G1当中某些原本不为人知的潜在问题，JEP 248指出。“如果其中出现了某些在JDK 9生命周期之内无法解决的问题，那么我们将重新将Parallel GC作为JDK 9通用版本的默认垃圾回收方案。”G1还提供多种不同资源使用方式。“当资源使用率需要被控制在***水平时，用户应该优先选择其它垃圾回收机制来取代G1，而在变更之后、后备回收机制必须得到明确指定。”
Parallel GC这套并行垃圾回收方案多年来一直在Java当中充当默认选项，而需要尽可能压缩垃圾回收暂停时间的应用程序则主要采用Concurrent Mark Sweep——后者同样属于备选方案，Java虚拟机技术供应商Azul Systems公司Scott Sellers指出。G1是一套全新实现方案，其代码更加简洁而且在维护方面上对开发人员更加友好，因此“一部分用户可能更倾向于使用G1作为演进后的处理手段，”Sellers解释称。
不过G1也有着自己的弊端，包括较并行垃圾收集机制而言数据吞吐速度较慢且性能较差，他表示。“G1的另一大短板在于，如果某款应用程序需要拥有非常严格的响应时间特性，那么经过精确调整的CMS垃圾回收机制在几乎各种情况下都能提供优于G1的响应时间指标。”
原文标题：Cleaner garbage collector wanted for Java 9
