JVM

1.串行垃圾回收使用-XX:+UseSerialGC定义,serial 串行,优点:是单线程进行回收,无序多线程交互,所以速度较快;缺点:回收的时候需要停止其他所有线程,直到回收完成

2.并行垃圾回收使用-XX:+UseParallelGC定义,使用-XX:+UseParallelGCThreads=<N>设置用来并行回收的线程数,N通常设置为处理器相等的数,parallel 并行.

 

3.并发垃圾回收使用-XX:+UseConcMarkSweepGC定义,缩写为CMS,整个堆有两种垃圾回收形式 1 年轻代采用多个GC线程实现"复制"算法;2 老年代采用多线程实现"标记-清除"算法,这个垃圾回收需要经历初始标记,并发标记,重新标记,并发清理四个阶段,其中初始标记和重新标记需要暂停其他用户线程,并发标记和并发清理不需要暂停其他用户线程

CMS的缺点:

问题产生:应用运行和垃圾回收是同时进行,会产生浮动垃圾(floating garbage),这些浮动垃圾要等到下次垃圾回收才能被回收掉,一般预留20%空间用于这些浮动垃圾,如果这部分空间还不能及时处理完浮动垃圾,则会产生"并发模式失败(concurrent mode failure)",此时程序会停止运行进行垃圾回收.

解决办法:为了解决这个问题CMS收集器提供了一个参数 -XX:+UseCMSCompactAtFullColletion 用来开关CMS收集器顶不住要Full GC的时候开启内存碎片整理过程,默认是开启的,内存整理时候是不能并发的.产生问题二

问题二的产生:如此一来空间碎片问题解决了,但是停顿的时间变长了,

问题二的解决:为了解决停顿时间长的问题,虚拟机还提供了一个参数来控制多少次Full GC后执行压缩一次Full GC ,该参数是 -XX:CMSFullGCsBeforeCompaction,默认值是0,表示每次FullGC的时候都要进行压缩整理

并发阶段的缺点:在并发阶段,不会导致用户进程的停顿,但是会占用部分CPU资源,导致应用系统变慢,吞吐量会降低,CMS默认启动回收垃圾的线程数是(CPU个数+3)/4,也就是说当CPU个数在5个时候,会有(5+3)/4=2,会有2/5的CPU资源用来垃圾回收,这个值随CUP个数的增加而减少,所以当CPU个数少的时候不要用CMS垃圾回收方式,会导致用户程序的执行速度大幅度降低,让人不能接受

 4.G1垃圾回收收集器,有初始标记,并发标记,最终标记,筛选回收四个阶段

初始标记;并行,仅标记GC Roots能直接关联到的对象,修改TAMS的值(next top at mark start),让下一阶段用户程序运行时,能在正确可用的region(块,区域)中创建新对象,需要停顿线程,耗时较短,

并发标记:并发,从GC Root对对进行可达性分析,找出存活的对象,耗时较长

最终标记:并行,为了修正并发标记期间因用户程序继续运行导致标记产生变动的那一部分标记记录

筛选回收:并行,对各个区域的回收价值和成本进行排序,根据用户期望的GC停顿时间来定制回收计划,该阶段只回收部分region,时间是用户可控制的,停顿用户线程将大幅提高收集效率