JVM垃圾收集器使用调查:CMS最受欢迎

标签: jvm 垃圾收集 cms | 发表时间:2013-11-28 18:32 | 作者:
出处:http://www.iteye.com
近日,Plumbr公司对特定垃圾收集器(GC)使用情况进行了一次调查研究。

本次研究的数据来自代表2670个不同使用环境的84936个案例。其中,13%的环境已经明确指定了一个垃圾收集器,其余的根据JVM而定。在指定了明确垃圾收集器的11062个案例中,根据每个垃圾收集器使用的统计次数,研究人员做出了下面的垃圾收集器饼图:



GC使用统计

名词解释
  • Serial:串行收集器,当进行垃圾收集时,会暂停所有线程
  • Parallel:并行收集器,是串行收集器的多线程版本,多CPU下
  • ParallelOld:老年代的Parallel版本
  • ConcMarkSweep:简称CMS,是并发收集器,将部分操作与用户线程并发执行
  • CMSIncrementalMode:CMS收集器变种,属增量式垃圾收集器,在并发标记和并发清理时交替运行垃圾收集器和用户线程
  • G1:面向服务器端应用的垃圾收集器,计划未来替代CMS收集器
87%的案例没有指定垃圾收集器

在解释垃圾收集器使用情况的详情之前,我们先看下其他87%的案例为什么没有出现在上面的饼图中。从研究结果来看,有2个不同的原因导致了该情况的出现:

  • JVM对于默认情况的处理十分合理,开发人员无需指定垃圾收集器
  • 对部分团队来说,程序性能可能优先级不高,致使没有指定垃圾收集器
所以,研究团队没有采用使用默认垃圾收集器的JVM案例。话又说回来,默认的垃圾收集器又是什么呢?这个问题既简单又复杂。 如果你运行在JVM的客户端模式(Client)下,JVM默认垃圾收集器是串行垃圾收集器(Serial GC,-XX:+USeSerialGC);在JVM服务器模式(Server)下默认垃圾收集器是并行垃圾收集器(Parallel GC,-XX:+UseParallelGC)。至于是运行在JVM的客户端模式还是服务器模式,取决于下面情况:


JVM客户端/服务器模式


大多数案例没有做出最佳选择

让我们回到已经明确指定垃圾收集器的13%的案例,但仅有一小部分用户的决策是按照上述表格中的建议进行的。据统计,只有31个案例根据自己的机器性能选择了最佳的串行垃圾收集器,考虑到当前服务大多运行在多核服务器上,这个可以理解。



垃圾收集器使用类型统计

我们从上图可以看出,并行(Parallel)和ParallelOld使用次数很接近。如果觉得并行模式这一新生代收集器更符合你的需求,那就选择它。从第一张表格中我们也可以看出,并行垃圾收集器(Parallel)已经是大多数平台的默认选择。 从这个方面讲,如果没有指定明确的垃圾收集器,也并不意味着默认使用的垃圾收集器不流行。

说到CMSIncrementalMode的使用情况,只有935个环境使用了该种垃圾收集器,相比而言,经典的CMS(ConcMarkSweep)则有6655个环境使用了它。这里提示下大家,在并发阶段,垃圾收集器线程会使用一个或多个处理器。 增量式垃圾收集器是通过一定的回收算法,把一个长时间的中断,划分为很多个小的中断,以减少垃圾收集器对用户程序的影响。

研究中还有一个结果就是G1的采用率,有826个环境使用了该种垃圾收集器。但同等条件来讲,G1比CMS性能表现会差一些。

以上就是本次研究的结果,希望对各位有用。

Via Plumbr

感谢 tuhaihe 投递这篇资讯

已有 0 人发表留言,猛击->> 这里<<-参与讨论


ITeye推荐



相关 [jvm 垃圾收集 cms] 推荐:

JVM垃圾收集器使用调查:CMS最受欢迎

- - ITeye资讯频道
近日,Plumbr公司对特定垃圾收集器(GC)使用情况进行了一次调查研究. 本次研究的数据来自代表2670个不同使用环境的84936个案例. 其中,13%的环境已经明确指定了一个垃圾收集器,其余的根据JVM而定. 在指定了明确垃圾收集器的11062个案例中,根据每个垃圾收集器使用的统计次数,研究人员做出了下面的垃圾收集器饼图:.

JVM初探- 内存分配、GC原理与垃圾收集器

- - IT瘾-geek
JVM初探- 内存分配、GC原理与垃圾收集器. JVM内存的分配与回收大致可分为如下4个步骤: 何时分配 -> 怎样分配 -> 何时回收 -> 怎样回收. new时分配外, 我们着重介绍后面的3个步骤:. 怎样分配- JVM内存分配策略. 对象内存主要分配在新生代 Eden区, 如果启用了本地线程分配缓冲, 则 优先在TLAB上分配, 少数情况能会直接分配在老年代, 或被拆分成标量类型在栈上分配(JIT优化).

java的垃圾收集算法和垃圾收集器

- - ITeye博客
   该算法主要分为标记和清除两个阶段,先对需要回收的对象进行标记,然后再进行清除,该算法的有点是简单,缺点有两个,一个是效率问题,标记和清除的效率都不高,另一个问题是空间问题,标记清除之后会造成大量的空间碎片,当程序需要分配一个大对象而无法找到连续的空间时就必须出发一次垃圾回收.   该算法是将内存空间分为大小相等的两块,在其中的一块进行对象的分配,需要垃圾回收时将其中一块存活的对象拷贝到另一块即可,然后把用过的内存块给清理掉,该算法的有点是:不用考虑内存碎片问题,实现简单,运行高效,缺点是:将内存缩小为了原来的一半,代价有点儿高.

CMS gc实践总结

- - 编程语言 - ITeye博客
声明:原文转自http://www.blogjava.net/killme2008/archive/2009/09/22/295931.html,该文所有合法权益归原作者所有,仅在此做技术分享使用. 首先感谢阿宝同学的帮助,我才对这个gc算法的调整有了一定的认识,而不是停留在过去仅仅了解的阶段. 在读过sun的文档和跟阿宝讨论之后,做个小小的总结.

Java虚拟机学习 - 垃圾收集器

- - ITeye博客
HotSpot JVM收集器.               上面有7中收集器,分为两块,上面为新生代收集器,下面是老年代收集器. 如果两个收集器之间存在连线,就说明它们可以搭配使用. Serial(串行GC)收集器. Serial收集器是一个新生代收集器,单线程执行,使用复制算法. 它在进行垃圾 收集时,必须暂停其他所有的工作线程(用户线程).

垃圾收集器与内存分配策略

- - Java - 编程语言 - ITeye博客
《深入理解Java虚拟机:JVM高级特性与最佳实践(第2版)》. Java与C++之间有一堵由内存动态分配和垃圾收集技术所围成的“高墙”,墙外面的人想进去,墙里面的人却想出来. 目前内存的动态分配与内存回收技术(GC(Garbage Collection))已经相当成熟;. 但是当我们需要排查各种内存溢出、内存泄漏问题时,当垃圾收集成为系统达到更高并发量的瓶颈时,我们就需要对GC的技术细节有一定了解;以便于实施必要的监控和调节.

五分钟了解Java10针对垃圾收集的改进

- - 程序猿DD
Java10 已经发布了大概有一个多月了. 我们在之前的文中介绍过10为我们带来的一些新特性: JDK10要来了:下一代 Java 有哪些新特性. 其中就提到了10 关于G1垃圾收集器的一些改进. G1在Java 9的时候已经是被作为默认的垃圾收集器了. 如果你了解G1的话,应该知道它是一个更注重低停顿的收集器.

G1,CMS及PARALLEL GC的比较

- - Java译站
这篇文章正好接上前一年我们做的一次现实环境下不同GC算法性能比较的试验. 这次我们仍然进行同样的试验,不过增加了对G1回收器的测试,并且在多个平台进行测试. 今年我们测试的垃圾回收器有如下几个:. 我们使用现成的 JIRA任务来运行这个测试. 选择它的原因非常简单——除去Minecraft(一款著名网游),愤怒的小鸟,以及Eclipse不说, JIRA应该是最著名的Java应用程序了.

一次CMS GC的调优工作

- - 舒の随想日记
某台机器的内存比较大,之前的JVM参数是4G的堆,在压测过程中发现当QPS上来以后,Full GC会开始抬头,YoungGC的频率就不用说了,比较高. 观察GC日志和jstat -gcutil,感觉是QPS在峰值的时候对象创建比较多,也有大对象产生. 于是打算加大堆的大小来延缓GC的时机,并且有一些GC参数的优化,反复调整后找到了一个适合我们的参数(没有一个best的参数,还是得按照应用的的情况去测量,最好是一遍压测一遍调整,最终找到一个best fit的参数组).

JVM研究

- - 开源软件 - ITeye博客
每天接客户的电话都是战战兢兢的,生怕再出什么幺蛾子了. 我想Java做的久一点的都有这样的经历,那这些问题的最终根结是在哪呢. JVM全称是Java Virtual Machine,Java虚拟机,也就是在计算机上再虚拟一个计算机,这和我们使用 VMWare不一样,那个虚拟的东西你是可以看到的,这个JVM你是看不到的,它存在内存中.