JVM学习(4)——全面总结Java的GC算法和回收机制

  1. 云栖社区>
  2. 博客>
  3. 正文

JVM学习(4)——全面总结Java的GC算法和回收机制

ghost丶桃子 2016-05-19 16:02:28 浏览1694
展开阅读全文

  引用实例被添加在引用队列中,可以在任何时候通过查询引用队列回收对象。

  

  现在我对一个对象的生命周期进行描述:

  新建Java对象A首先处于可达的,未执行finalize方法的状态,随着程序的运行,一些引用关系会消失,或者变迁,当对A使用可达性算法判断,对象A变成了 GC Roots 不可达时,A从可达状态变迁到不可达状态,但是JVM不会就就这样把它清理了,而是在第一次GC的时候,对它首先进行一个标记(标记清除算法),之后最少还要再进行一次筛选,而对其筛选的的条件就是看该对象是否覆盖了Object的finalize方法,或者看这个对象是否执行过一次finalize方法。如果没有执行,也没有覆盖,就满足筛选条件,JVM将其放入F-Queue队列,由JVM的一个低优先级的线程执行该队列中对象的finalize方法。此时执行finalize方法优先级是很低的,且不会保证等待finalize方法执行完毕才进行第二次回收(怕发生无限等待的情景,JVM崩溃),之后不久GC对队列里的对象进行二轮回收,去判断该对象是否可达,若不可达,才进行回收,否则,对象“复活”(执行finalize的过程中,应用程序是可以让对象再次被引用,复活的)。而在可达性判断的时候,还要兼顾四种引用类型,根据不同的引用类型特点去判断是否是回收的对象。看例子:
 
 
复制代码
package wys.demo1;

public class Demo1 {
    public static Demo1 obj;
    
    @Override
    protected void finalize() throws Throwable {
        super.finalize();
        
        System.out.println("CanReliveObj finalize called");
        
        obj = this;// 把obj复活了!!!
    }
    
    @Override
    public String toString(){
        return "I am CanReliveObj";
    }
    
    public static void main(String[] args) throws InterruptedException{
        obj = new Demo1();// 强引用
        obj = null;   //不会被立即回收,是可复活的对象
        
        System.gc();// 主动建议JVM做一次GC,GC之前会调用finalize方法,而我在里面把obj复活了!!!
        Thread.sleep(1000);

        if(obj == null){
            System.out.println("obj 是 null");
        }else{
            System.out.println("obj 可用");
        }
        
        System.out.println("第二次gc");
        obj = null;    //不可复活
        System.gc();
        Thread.sleep(1000);
        
        if(obj == null){
            System.out.println("obj 是 null");
        }else{
            System.out.println("obj 可用");
        }
    }
}
复制代码

  结果:

CanReliveObj finalize called
obj 可用
第二次gc
obj 是 null

  说明JVM不管程序员手动调用finalize,JVM它就是执行一次finalize方法。执行finalize方法完毕后,GC会再次进行二轮回收,去判断该对象是否可达,若不可达,才进行回收。

  

  建议:避免使用finalize方法!

  太复杂了,还是让系统照管比较好。可以定义其它的方法来释放非内存资源。建议使用try-catch-finally来替代它执行清理操作。

  如果手动调用了finalize,很容易出错。且它执行的优先级低,何时被调用,不确定——也就是何时发生GC不确定,因为只有当内存告急时,GC才工作,即使GC工作,finalize方法也不一定得到执行,这是由于程序中的其他线程的优先级远远高于执行finalize()的线程优先级。 因此当finalize还没有被执行时,系统的其他资源,比如文件句柄、数据库连接池等已经消耗殆尽,造成系统崩溃。且垃圾回收和finalize方法的执行本身就是对系统资源的消耗,有可能造成程序的暂时停止,因此在程序中尽量避免使用finalize方法。

  上面提到了GC或者执行finalize可能造成程序暂停,这引出一个概念:Stop-The-World现象。
  这是Java中一种全局暂停的现象,全局停顿,所有Java代码停止,类似JVM挂起的状态……但是native代码可以执行,但不能和JVM交互。这多半由于GC引起,其他的引起原因比如:
  • Dump线程
  • JVM的死锁检查
  • 堆的Dump。
  这三者出现概率很低,多半是程序员手动引起的,而GC是JVM自动引起的。
  
  GC时为什么会有全局停顿?
  类比在聚会时打扫房间,聚会时很乱,又有新的垃圾产生,房间永远打扫不干净,只有让大家停止活动了,才能将房间在某一个状态下打扫干净。回程序中就是只有程序暂停了,才能全面,完整,正确的清理一次垃圾对象,否则前脚清理了,后脚还有新的,永远清理不完,对判断垃圾对象也是一个判断上干扰的问题,也永远干净不了。
 
  Stop-The-World现象危害
  长时间服务停止,没有响应,一般新生代的GC停顿时间很短,零点几秒。而老年代比较时间长,几秒甚至几十分钟……一般堆内存越大,GC时间越长,也就是Stop-The-World越久。所以,JVM的内存不是越大越好,要根据实际情况设置。
  遇到HA系统,可能引起主备切换,严重危害生产环境。比如一个系统,一个主机服务器,一个备机服务器,不会同时启动,我们会只使用一个,比如主机暂时因为GC没有响应,如果时间太长,我们会使用备机,一旦主机恢复了,主机也启动了,此时备机主机都启动了,很可能导致服务器数据不一致……
  
  前面罗嗦了一堆,那么这些算法是如何在JVM中配合使用的呢?那么就引出新的问题需要解决:JVM的垃圾回收器。
  回忆下堆的结构:还是以Java 7为例子:
  Java堆整体分两代,新生代和老年代,顾名思义,前者存放新生对象,大部分都是朝生夕死!进行GC的次数不多,后者存放的是时间比较久的对象,也就是多次GC还没死的对象。对象创建的时候,大部分都是放入新生代的eden区,除非是很大的对象,可能会直接存放到老年代,还有之前说的栈上分配(逃逸分析)。
  如果eden对象在GC时幸存,就会进入幸存区,也就是s0,s1,或者叫from和to,或者叫survivor(两个),大小一样。完全对称,功能也一样。前面说了GC有复制算法,那么就是使用在这里,GC在新生代时,eden区的存活对象被复制到未使用的幸存区,假设是to,而正在使用的是from区的年轻的对象也会一起被复制到了to区,如果to区满了,这些对象也和大对象,老年对象一样直接进入了老年代保存(担保空间)。此时,eden区剩余的对象和from区剩余的对象就是垃圾对象,能直接GC,to区存放的是新生代的此次GC活下来的对象。避免了产生内存碎片。

  先不说了,先看看JVM的垃圾回收器吧,先看一种最古老的收集器——串行收集器

  最古老,最稳定,效率高,但是串行的最大问题就是停顿时间很长!因为串行收集器只使用一个线程去回收,可能会产生较长的停顿现象。我们可以使用参数-XX:+UseSerialGC,设置新生代、老年代使用串行回收,此时新生代使用复制算法,老年代使用标记-压缩算法(标记-压缩算法首先需要从根节点开始,对所有可达对象做一次标记。但之后,它并不简单的清理未标记的对象,而是将所有的存活对象压缩到内存的一端。之后,清理边界外所有的空间。有效解决内存碎片问题)。

  因为串行收集器只使用一个线程去回收,可能会产生较长的停顿现象。

 

  还有一种收集器叫并行收集器(两种并行收集器)

  • 一种是ParNew并行收集器。使用JVM参数设置XX:+UseParNewGC,设置之后,那么新生代就是并行回收,而老年代依然是串行回收,也就是并行回收器不会影响老年代,它是Serial收集器在新生代的并行版本,新生代并行依然使用复制算法,但是是多线程,需要多核支持,我们可以使用JVM参数: XX:ParallelGCThreads 去限制线程的数量。如图:

  注意:新生代的多线程回收不一定快!看在多核还是单核,和具体环境。、

  • 还有一种是Parallel收集器,它类似ParNew,但是更加关注JVM的吞吐量!同样是在新生代复制算法,老年代使用标记压缩算法,可以使用JVM参数XX:+UseParallelGC设置使用Parallel并行收集器+ 老年代串行,或者使用XX:+UseParallelOldGC,使用Parallel并行收集器+ 并行老年代。也就是说,Parallel收集器可以同时让新生代和老年代都并行收集。如图:

  关于并行收集器还有两个参数设置:
  -XX:MaxGCPauseMills,代表最大的GC线程占用的停顿时间,单位是毫秒,GC尽力保证回收时间不超过设定值,不是100%的保证。
  -XX:GCTimeRatio,GC使用的cpu时间占总时间的百分比,理解为吞吐量,0-100的取值范围,垃圾收集时间占总时间的比,默认99,即最大允许1%时间做GC。我们肯定希望停顿时间短,且占用总时间比例少,但是这两个参数是矛盾的。因为停顿时间和吞吐量不可能同时调优。
  如果GC很频繁,那么GC的最大停顿时间变短,但吞吐量变小,如果GC次数很少,最大的停顿时间就会变长,但吞吐量增大。

  

  最后看一个很重要的收集器-CMS(并发标记清除收集器Concurrent Mark Sweep)收集器

  顾名思义,它在老年代使用的是标记清除算法,而不是标记压缩算法,也就是说CMS是老年代收集器(新生代使用ParNew),所谓并发标记清除就是CMS与用户线程一起执行。标记-清除算法与标记-压缩相比,并发阶段会降低吞吐量,使用参数-XX:+UseConcMarkSweepGC打开。

   CMS运行过程比较复杂,着重实现标记的过程,可分为:

  • 初始标记,标记GC ROOT 根可以直接关联到的对象(会产生全局停顿),但是初始标记速度快。
  • 并发标记(和用户线程一起),主要的标记过程,标记了系统的全部的对象(不论垃圾不垃圾)。
  • 重新标记,由于并发标记时,用户线程依然运行(可能产生新的对象),因此在正式清理前,再做一次修正,会产生全局停顿
  • 并发清除(和用户线程一起),基于标记结果,直接清理对象。这也是为什么使用标记清除算法的原因,因为清理对象的时候用户线程还能执行!标记压缩算法的压缩过程涉及到内存块移动,这样会有冲突。
  • 并发重置,为下一次GC做准备工作。

 

  CMS的特点
  尽可能降低了JVM的停顿时间,但是会影响系统整体吞吐量和性能,比如:
  1. 在用户线程运行过程中,分一半CPU去做GC,系统性能在GC阶段,反应速度就下降一半。
  2. 清理不彻底。因为在清理阶段,用户线程还在运行,会产生新的垃圾,无法清理。
  3. 因为和用户线程基本上是一起运行的,故不能在空间快满时再清理。

可以使用-XX:CMSInitiatingOccupancyFraction设置触发CMS GC的阈值,设置空间内存占用到多少时,去触发GC,如果不幸内存预留空间不够,就会引起concurrent mode failure。

可以使用-XX:+ UseCMSCompactAtFullCollection, Full GC后,进行一次整理,而整理过程是独占的,会引起停顿时间变长。

可以使用-XX:+CMSFullGCsBeforeCompaction,设置进行几次Full GC后,进行一次碎片整理。
还可以使用-XX:ParallelCMSThreads,设定CMS的线程数量,一般设置为cpu数量,不用太大。
 
  为减轻GC压力,我们需要注意些什么?

   从三个方面考虑:

  • 软件如何设计架构
  • 代码如何写
  • 堆空间如何分配

 

辛苦的劳动,转载请注明出处,谢谢……http://www.cnblogs.com/kubixuesheng/p/5208647.html

网友评论

登录后评论
0/500
评论
ghost丶桃子
+ 关注