一 面向服务端应用，针对具有大内存、多处理器的机器。
在普通大小的堆里表现并不惊喜。
二 最主要的应用是需要低 GC 延迟，并具有大堆的应用程序提供解决方案。
如：在堆大小约 6GB 或更大时，可预测的暂停时间可以低于 0.5秒；（G1 通过每次只清理一部分而不是全部的 Region 的增量式清理来保证每次 GC 停顿时间不会过长）。
三 用来替换掉 JDK1.5 中的 CMS 收集器，在下面的情况时，使用 G1 可能比 CMS 好。
-
超过 50% 的 Java 堆被活动数据占用
-
对象分配频率或年代提升频率变化很大
-
GC停顿时间过长（长于0.5至1秒）
四 HotSpot 垃圾收集器里，除了 G1 以外，其他的垃圾收集器使用内置的 JVM 线程执行 GC 的多线程操作，而 G1 GC 可以采用应用线程承担后台运行的 GC 工作，即当 JVM 的 GC 线程处理速度慢时，系统会调用应用程序线程帮助加速垃圾回收过程。
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 [email protected] 举报，一经查实，本站将立刻删除。
