常见的垃圾回收器和算法

相信大家可以通过我提供的另外两个文章,学习到很多的垃圾回收器的相关知识。而我们真正需要关注,甚至可能使用到的垃圾收集器就是以下四种:

serial 串行垃圾收集器

如果是在client型的虚拟机或者在单核的服务器上,这种垃圾回收器将会成为默认的垃圾回收器。无论是Minor GC 还是 Full GC ,所有的应用线程都会暂停。在老年代当中使用的是Serial Old,同样是单线程的老年代版本。

client型虚拟机,我们前面提到过编译类型分为client和server,jvm会通过client编译器(单线程)将代码编译成jvm识别的字节码。

可以通过如下标志表示:

    -XX:+UseSerialGC
登录后复制

Parallel 多线程垃圾收集器

在server型虚拟机或多线程服务器上,jdk8默认使用的垃圾收集器类型。

无论是Minor GC还是Full GC都使用多线程的方式去回收垃圾,这两种GC都会造成应用线程的暂停。但是它具有更多的吞吐量,是对于响应时间没有过多要求情况下,最合适的垃圾回收器。

可以通过如下标志查看其状态:

年轻代:

-XX:+UseParallelGC
登录后复制

老年代:

-XX:+UseParallelOldGC
登录后复制

CMS 收集器

其设计初衷是为了减少serial和parallel收集器,在回收时造成的长时间的系统卡顿。

它在发生Minor GC时同样会暂停所有的应用线程,不同之处在于,年轻代使用的不是parallel或者serial,而是使用一款专门适用于CMS的年轻代收集器ParNew

可以通过下面的标志查看:

-XX:+UseParNewGC
登录后复制

CMS在发生Full GC时不再暂停全部应用线程,使用多线程的方式,和应用线程同时运行,清理不在使用的对象。这事得CMS垃圾收集器的停顿时间得到大大的降低。与Parellel收集器相比,极其明显。

缺点

  • CMS需要占用较多的CPU资源,确保在应用线程运行时,gc线程不断地扫描堆空间。

  • 不会对内存进行压缩整理,导致内存碎片化。

如果没有足够的CPU资源,或者内存碎片化达到极限,将会退化成serial收集器。

可以通过下面的标志查看:

-XX:+UseConcMarkSweepGC
登录后复制

G1 收集器

也可以称作垃圾优先收集器(garbage first)。

设计初衷是为了尽量减少处理超大堆(4gb)时发生的卡顿。G1仍然属于分代收集器,但是不同之处是它是逻辑分代。G1将堆空间划分成若干个区域(Region),新生代的垃圾收集依然采用暂停所有应用线程的方式,将存活对象拷贝到老年代或者Survivor空间。老年代也分成很多区域,G1收集器通过将对象从一个区域复制到另外一个区域,完成了清理工作。这样就解决了CMS中的内存碎片问题。

与CMS相同,G1也属于concurrent收集器,在老年代发生Full GC时,由后台线程完成回收工作,不需要暂停应用线程。

通过下面的标志查看:

-XX:+UseG1GC
登录后复制

其实上面的内容都是简单描述,真正的实现细节请看开篇提供的文章。

显式垃圾收集

这里说的显式的垃圾收集,其实指的是手动触发的垃圾回收,如下所示:

System.gc;
登录后复制

这是一种可以认为控制,让jvm发生强制gc的方式。无论什么时候,都是不建议使用这种方式进行垃圾回收。

当你使用这条指定,不论是何种垃圾收集器,哪怕是CMS或G1也会发生Full GC,同时停止全部的应用线程,会卡顿相当长的一段时间。

例外情况:

  • 性能分析、测试

  • 堆分析

在上述情况,调用System.gc将能更好的帮助我们分析当前应用存在的问题。

以上就是java性能优化常见的垃圾收集器有哪些的详细内容,更多请关注Work网其它相关文章!

09-14 02:09