JVM垃圾收集器使用调查:CMS最受欢迎
程序员文章站
2022-05-17 09:43:13
...
近日,Plumbr公司对特定垃圾收集器(GC)使用情况进行了一次调查研究。
本次研究的数据来自代表2670个不同使用环境的84936个案例。其中,13%的环境已经明确指定了一个垃圾收集器,其余的根据JVM而定。在指定了明确垃圾收集器的11062个案例中,根据每个垃圾收集器使用的统计次数,研究人员做出了下面的垃圾收集器饼图:
GC使用统计
名词解释
在解释垃圾收集器使用情况的详情之前,我们先看下其他87%的案例为什么没有出现在上面的饼图中。从研究结果来看,有2个不同的原因导致了该情况的出现:
JVM客户端/服务器模式
大多数案例没有做出最佳选择
让我们回到已经明确指定垃圾收集器的13%的案例,但仅有一小部分用户的决策是按照上述表格中的建议进行的。据统计,只有31个案例根据自己的机器性能选择了最佳的串行垃圾收集器,考虑到当前服务大多运行在多核服务器上,这个可以理解。
垃圾收集器使用类型统计
我们从上图可以看出,并行(Parallel)和ParallelOld使用次数很接近。如果觉得并行模式这一新生代收集器更符合你的需求,那就选择它。从第一张表格中我们也可以看出,并行垃圾收集器(Parallel)已经是大多数平台的默认选择。从这个方面讲,如果没有指定明确的垃圾收集器,也并不意味着默认使用的垃圾收集器不流行。
说到CMSIncrementalMode的使用情况,只有935个环境使用了该种垃圾收集器,相比而言,经典的CMS(ConcMarkSweep)则有6655个环境使用了它。这里提示下大家,在并发阶段,垃圾收集器线程会使用一个或多个处理器。增量式垃圾收集器是通过一定的回收算法,把一个长时间的中断,划分为很多个小的中断,以减少垃圾收集器对用户程序的影响。
研究中还有一个结果就是G1的采用率,有826个环境使用了该种垃圾收集器。但同等条件来讲,G1比CMS性能表现会差一些。
以上就是本次研究的结果,希望对各位有用。
Via Plumbr
本次研究的数据来自代表2670个不同使用环境的84936个案例。其中,13%的环境已经明确指定了一个垃圾收集器,其余的根据JVM而定。在指定了明确垃圾收集器的11062个案例中,根据每个垃圾收集器使用的统计次数,研究人员做出了下面的垃圾收集器饼图:
GC使用统计
名词解释
- Serial:串行收集器,当进行垃圾收集时,会暂停所有线程
- Parallel:并行收集器,是串行收集器的多线程版本,多CPU下
- ParallelOld:老年代的Parallel版本
- ConcMarkSweep:简称CMS,是并发收集器,将部分操作与用户线程并发执行
- CMSIncrementalMode:CMS收集器变种,属增量式垃圾收集器,在并发标记和并发清理时交替运行垃圾收集器和用户线程
- G1:面向服务器端应用的垃圾收集器,计划未来替代CMS收集器
在解释垃圾收集器使用情况的详情之前,我们先看下其他87%的案例为什么没有出现在上面的饼图中。从研究结果来看,有2个不同的原因导致了该情况的出现:
- JVM对于默认情况的处理十分合理,开发人员无需指定垃圾收集器
- 对部分团队来说,程序性能可能优先级不高,致使没有指定垃圾收集器
JVM客户端/服务器模式
大多数案例没有做出最佳选择
让我们回到已经明确指定垃圾收集器的13%的案例,但仅有一小部分用户的决策是按照上述表格中的建议进行的。据统计,只有31个案例根据自己的机器性能选择了最佳的串行垃圾收集器,考虑到当前服务大多运行在多核服务器上,这个可以理解。
垃圾收集器使用类型统计
我们从上图可以看出,并行(Parallel)和ParallelOld使用次数很接近。如果觉得并行模式这一新生代收集器更符合你的需求,那就选择它。从第一张表格中我们也可以看出,并行垃圾收集器(Parallel)已经是大多数平台的默认选择。从这个方面讲,如果没有指定明确的垃圾收集器,也并不意味着默认使用的垃圾收集器不流行。
说到CMSIncrementalMode的使用情况,只有935个环境使用了该种垃圾收集器,相比而言,经典的CMS(ConcMarkSweep)则有6655个环境使用了它。这里提示下大家,在并发阶段,垃圾收集器线程会使用一个或多个处理器。增量式垃圾收集器是通过一定的回收算法,把一个长时间的中断,划分为很多个小的中断,以减少垃圾收集器对用户程序的影响。
研究中还有一个结果就是G1的采用率,有826个环境使用了该种垃圾收集器。但同等条件来讲,G1比CMS性能表现会差一些。
以上就是本次研究的结果,希望对各位有用。
Via Plumbr
上一篇: 春困征候群悄悄扩大
下一篇: 哈苏标大亮!一加9 Pro黑洞版开箱图赏
推荐阅读