1、测试代码实例：使用线程池不断的创建对象

2、使用的命令说明

a.测试代码执行命令，堆内存18g，使用不同的GC算法

重要参数说明:
-Xms18g -Xmx18g:
-XX:+PrintGC 打印GC日志
-XX:+PrintGCTimeStamps   打印GC发送的时间
-XX:+PrintGCApplicationStoppedTime  打印应用由于GC而产生的停顿时间
-XX:+UseG1GC 指定G1垃圾回收
-XX:+UseConcMarkSweepGC 指定CMS垃圾回收

b.GC情况查看命令,间隔10秒，观察30次

jstat -gcutil pid 10000 30

CPU:Intel(R) Xeon(R) CPU E5-2609 v4 @ 1.70GHz
内存：24G
硬盘：500G
操作系统:centos
jdk:1.8.0_121-b13
堆内存:限制18G
变量:垃圾回收算法(CMS和G1)

使用UseConcMarkSweepGC的GC情况

使用G1的GC情况

使用CMS的应用暂停时间(选取部分)

使用G1的应用暂停时间(选取部分)

4、结论

CMS垃圾回收产生的FullGC次数是121，FullGC总的时间是223.913s,平均每次FullGC的时间是1.85s,总的GC时间是263.142s

G1垃圾回收产生的FullGC次数是286，FullGC总的时间是32.271s,平均每次FullGC的时间是0.11s,总的GC时间是40.304s

显然在实验中，G1总的GC时间短,FullGC的次数是CMS的2.36倍,CMS应用暂停时间达到最大2.869s，G1最大应用暂停时间0.196s,也跟官方给FGC的最大暂停时间（200ms）接近G1算法已经称为Java8之后的默认算法，本身的需要调整的参数很少，性能&易用性方面都比CMS好。大内存的情况下，同等条件，G1算法比CMS更适合

https://www.oracle.com/cn/technical-resources/articles/java/g1gc.html
https://www.oracle.com/technetwork/tutorials/tutorials-1876574.html

以下是对oracle官方描述的翻译

G1的推荐用例

G1的首要重点是为运行需要大量GC延迟的应用程序的用户提供一个解决方案。这意味着堆大小约为6GB或更大，并且稳定且可预测的暂停时间低于0.5秒。

如果应用程序具有以下一个或多个特性，那么使用CMS或ParallelOldGC垃圾收集器运行的应用程序将有利于切换到G1。

• Full GC 持续时间太长或太频繁

• 对象分配频率高或者提升变化明显

• 不期望GC久、压缩停顿 (超过 0.5 to 1 秒)

注意：如果您使用的是CMS或parallelloldgc，并且您的应用程序没有遇到长时间的垃圾收集暂停，那么可以使用当前收集器。使用最新的JDK不需要更改为G1收集器。