JVM——垃圾收集器

目录

引言           

垃圾收集器

 如何判断对象已死?

 引用计数算法:

 可达性分析算法:            

 垃圾收集算法

 标记-清除算法

 标记-复制算法

 标记-整理算法

并发的可达性分析

 经典垃圾收集器

 内存分配与回收策略

1.对象优先在Eden分配

2.大对象直接进入老年代(大对象:超级长的字符串或数量超级大的数组)

3.长期存活的对象将进入老年代

4.动态对象年龄判定

5.空间分配担保

 总结:


引言           

        初始JVM我们知道了什么是JVM,以及他是做什么的、是如何管理对象和对象在内存里的分配(详情请看我上一篇博客初始JVM),然后这一篇我们聊一聊JVM的垃圾收集器(回收对象)


垃圾收集器

垃圾收集需要完成的三件事情:
  • 哪些内存需要回收?
  • 什么时候回收?
  • 如何回收?
        垃圾收集器在对堆进行回收前,第一件事情就 是要确定这些对象之中哪些还“存活 着,哪些已经 死去 (“死去 即不可能再被任何途径使用的对象)了

 如何判断对象已死?

               两种方式:引用计数算法可达性分析算法

 引用计数算法:

        在对象中添加一个引用计数器,每当有一个地方 引用它时,计数器值就加一;当引用失效时,计数器值就减一;任何时刻计数器为零的对象就是不可 能再被使用的。

         优点:原理简单,判定效率也很高

        缺点:占用额外内存空间,单纯的引用计数 就很难解决对象之间相互循环引用的问题(两个对象再无任何引用,实际上这两个对象已 经不可能再被访问,但是它们因为互相引用着对方,导致它们的引用计数都不为零,引用计数算法也 就无法回收它们。)

public class ReferenceCountingGC {

    public Object instance=null;

    private static final int _1MB=1024*1024;

    /**
     * 这个成员属性的唯一意义就是占点内存,以便能在GC日志中看清楚是否被回收过
     */
    private byte[] bigSize=new byte[2*_1MB];

    public static void testGC(){
        ReferenceCountingGC objA=new ReferenceCountingGC();
        ReferenceCountingGC objB=new ReferenceCountingGC();
        //相互引用验证虚拟机是否是根据引用计数器的方法来判断对象是否存活的
        objA.instance=objB;
        objB.instance=objA;

        objA=null;
        objB=null;

        //假设在这行发生GC,objA和objB是否能被回收?
        System.gc();
    }

    public static void main(String[] args){
        testGC();
    }

}

 结果分析:

        从运行结果中可以清楚看到内存回收日志中包含“4603K->210K” ,意味着虚拟机并没有因为这两 个对象互相引用就放弃回收它们,这也从侧面说明了Java 虚拟机并不是通过引用计数算法来判断对象 是否存活的。

 可达性分析算法:            

               通过 一系列称为“GC Roots”的根对象作为起始节点集,从这些节点开始,根据引用关系向下搜索,搜索过 程所走过的路径称为“引用链 Reference Chain ),如果某个对象到 GC Roots 间没有任何引用链相连, 或者用图论的话来说就是从GC Roots 到这个对象不可达时,则证明此对象是不可能再被使用的。如图所示:

         Java技术体系里面,固定可作为GC Roots的对象包括以下几种:

  • 在虚拟机栈(栈帧中的本地变量表)中引用的对象,譬如各个线程被调用的方法堆栈中使用到的 参数、局部变量、临时变量等。
  • 在方法区中类静态属性引用的对象,譬如Java类的引用类型静态变量。
  • 在方法区中常量引用的对象,譬如字符串常量池(String Table)里的引用。·在本地方法栈中JNI(即通常所说的Native方法)引用的对象。
  • Java虚拟机内部的引用,如基本数据类型对应的Class对象,一些常驻的异常对象(比如
  • NullPointExcepitonOutOfMemoryError)等,还有系统类加载器。
  • 所有被同步锁(synchronized关键字)持有的对象。
  • 反映Java虚拟机内部情况的JMXBeanJVMTI中注册的回调、本地代码缓存等。

        无论是通过引用计数算法判断对象的引用数量,还是通过可达性分析算法判断对象是否引用链可达,判定对象是否存活都和“引用”离不开关系。

        引用分为强引用(Strongly Re-ference)、软 引用(Soft Reference)、弱引用(Weak Reference)和虚引用(Phantom Reference) 4 种,这 4 种引用强度 依次逐渐减弱。

  • 强引用是最传统的引用的定义,是指在程序代码之中普遍存在的引用赋值,即类似“Object obj=new Object()”这种引用关系。无论任何情况下,只要强引用关系还存在,垃圾收集器就永远不会回收掉被引用的对象。
  • 软引用是用来描述一些还有用,但非必须的对象。只被软引用关联着的对象,在系统将要发生内 存溢出异常前,会把这些对象列进回收范围之中进行第二次回收,如果这次回收还没有足够的内存, 才会抛出内存溢出异常。在JDK 1.2版之后提供了SoftReference类来实现软引用。
  • 弱引用也是用来描述那些非必须对象,但是它的强度比软引用更弱一些,被弱引用关联的对象只 能生存到下一次垃圾收集发生为止。当垃圾收集器开始工作,无论当前内存是否足够,都会回收掉只 被弱引用关联的对象。在JDK 1.2版之后提供了WeakReference类来实现弱引用。
  • 虚引用也称为幽灵引用或者幻影引用,它是最弱的一种引用关系。一个对象是否有虚引用的 存在,完全不会对其生存时间构成影响,也无法通过虚引用来取得一个对象实例。为一个对象设置虚 引用关联的唯一目的只是为了能在这个对象被收集器回收时收到一个系统通知。在JDK 1.2版之后提供 了PhantomReference类来实现虚引用

 写个demo:

public class Reference {
    public static void main(String[] args) {
        //强引用
        String S = "强 引用 森";
        //软引用
        SoftReference<String> stringSoftReference = new SoftReference<>(new String("软 引用 仔"));
        System.out.println(stringSoftReference.get());
        System.gc();
        System.out.println(stringSoftReference.get());
        //弱引用
        WeakReference<String> str = new WeakReference<>("弱reference 森");
        System.out.println(str.get());
        System.gc();  //通知JVM进行内存回收
        System.out.println(str.get());
        //虚引用
        ReferenceQueue<Object> queue = new ReferenceQueue<>();
        PhantomReference<String> strs = new PhantomReference<>("虚引用 ", queue);
        System.out.println(strs.get());
        System.out.println(S);

    }
}

 真正的“死亡”:

            即使在可达性分析算法中判定为不可达的对象,也不是“非死不可 的,这时候它们暂时还处于 缓 刑” 阶段,要真正宣告一个对象死亡,至少要经历两次标记过程:如果对象在进行可达性分析后发现没 有与GC Roots 相连接的引用链,那它将会被第一次标记,随后进行一次筛选,筛选的条件是此对象是 否有必要执行finalize() 方法。假如对象没有覆盖 finalize() 方法,或者 finalize() 方法已经被虚拟机调用 过,那么虚拟机将这两种情况都视为“ 没有必要执行
因为任何一个对象的 finalize() 方法都只会被系统自动调用一次,如果对象面临
下一次回收,它的 finalize() 方法不会被再次执行

 垃圾收集算法

        

        垃圾收集器的一致的设计原则:收集器应该将Java 堆划分 出不同的区域,然后将回收对象依据其年龄(年龄即对象熬过垃圾收集过程的次数)分配到不同的区域之中存储。
                把分代收集理论具体放到现在的商用Java虚拟机里,设计者一般至少会把 Java 堆划分为 新生代 (Young Generation )和 老年代 Old Generation )两个区域
在新生代中,每次垃圾收集 时都发现有大批对象死去,而每次回收后存活的少量对象,将会逐步晋升到老年代中存放。
  • 新生代收集(Minor GC/Young GC):指目标只是新生代的垃圾收集。
  • 老年代收集(Major GC/Old GC):指目标只是老年代的垃圾收集。目前只有CMS收集器会有单独收集老年代的行为。另外请注意“Major GC”这个说法现在有点混淆,在不同资料上常有不同所指, 读者需按上下文区分到底是指老年代的收集还是整堆收集。
  • 混合收集(Mixed GC):指目标是收集整个新生代以及部分老年代的垃圾收集。目前只有G1集器会有这种行为。
  • 整堆收集(Full GC):收集整个Java堆和方法区的垃圾收集。

 标记-清除算法

        出现最早,最基础的算法;分为两个阶段:先标记需要回收的对象,标记完成后,统一回收;也可以标记存活的对象,统一回收没被标记的对象。  

 标记-复制算法

        又称复制算法,将内存按容量划分为大小相同的两块,每次只使用其中一块。当一块内存用完了,就将还存活的对象复制到另一块上,再把已使用过的内存空间一次清理掉  

 标记-整理算法

        为解决对象存活率高时进行较多的复制操作,以及浪费一半内存空间就需要有额外的空间进行分配担保;标记过程仍然与“标记-清除”算法一样,让所有存活的对象都向一端移动,然后直接清理掉端边界以外的内存。  

并发的可达性分析

·白色: 表示对象尚未被垃圾收集器访问过。显然在可达性分析刚刚开始的阶段,所有的对象都是
白色的,若在分析结束的阶段,仍然是白色的对象,即代表不可达。
· 黑色: 表示对象已经被垃圾收集器访问过,且这个对象的所有引用都已经扫描过。黑色的对象代
表已经扫描过,它是安全存活的,如果有其他对象引用指向了黑色对象,无须重新扫描一遍。黑色对 象不可能直接(不经过灰色对象)指向某个白色对象。
· 灰色: 表示对象已经被垃圾收集器访问过,但这个对象上至少存在一个引用还没有被扫描过。

 经典垃圾收集器

        

Serial收集器是最基础、历史最悠久的收集器,曾经(在JDK 1.3.1之前)是HotSpot虚拟机新生代收集器的唯一选择。大家只看名字就能够猜到,这个收集器是一个单线程工作的收集器,但它的“单线程”的意义并不仅仅是说明它只会使用一个处理器或一条收集线程去完成垃圾收集工作,更重要的是强调在它进行垃圾收集时,必须暂停其他所有工作线程,直到它收集结束。

ParNew收集器

ParNew收集器除了支持多线程并行收集之外,其他与Serial收集器相比并没有太多创新之处,但它却是不少运行在服务端模式下的HotSpot虚拟机,尤其是JDK 7之前的遗留系统中首选的新生代收集器,其中有一个与功能、性能无关但其实很重要的原因是:除了Serial收集器外,目前只有它能与CMS收集器配合工作。

ParallelScavenge收集器

Parallel Scavenge收集器的特点是它的关注点与其他收集器不同,CMS等收集器的关注点是尽可能地缩短垃圾收集时用户线程的停顿时间,而Parallel Scavenge收集器的目标则是达到一个可控制的吞吐量(Throughput)。所谓吞吐量就是处理器用于运行用户代码的时间与处理器总消耗时间的比值,

SerialOld收集器

Serial Old是Serial收集器的老年代版本,它同样是一个单线程收集器,使用标记-整理算法。这个收集器的主要意义也是供客户端模式下的HotSpot虚拟机使用。如果在服务端模式下,它也可能有两种用途:一种是在JDK 5以及之前的版本中与Parallel Scavenge收集器搭配使用[1],另外一种就是作为CMS收集器发生失败时的后备预案,在并发收集发生Concurrent Mode Failure时使用。

ParallelOld收集器

Parallel Old是Parallel Scavenge收集器的老年代版本,支持多线程并发收集,基于标记-整理算法实现。

CMS收集器

CMS(Concurrent Mark Sweep)收集器是一种以获取最短回收停顿时间为目标的收集器。CMS收集器是基于标记-清除算法实现的,它的运作过程相对于前面几种收集器来说要更复杂一些,整个过程分为四个步骤,包括:

1)初始标记(CMS initial mark)

2)并发标记(CMS concurrent mark)

3)重新标记(CMS remark)

4)并发清除(CMS concurrent sweep)

GarbageFirst收集器

Garbage First(简称G1)收集器是垃圾收集器技术发展历史上的里程碑式的成果,它开创了收集器面向局部收集的设计思路和基于Region的内存布局形式。

CMS收集器采用增量更新算法实现,而G1收集器则是通过原始快照(SATB)算法来实现的

 内存分配与回收策略

        

1.对象优先在Eden分配

2.大对象直接进入老年代(大对象:超级长的字符串或数量超级大的数组)

HotSpot虚拟机提供了-XX:PretenureSizeThreshold参数,指定大于该设置值的对象直接在老年代分配,这样做的目的就是避免在Eden区及两个Survivor区之间来回复制,产生大量的内存复制操作。

3.长期存活的对象将进入老年代

            对象通常在Eden区里诞生,如果经过第一次 Minor GC后仍然存活,并且能被 Survivor 容纳的话,该对象会被移动到 Survivor 空间中,并且将其对象 年龄设为1 岁。对象在 Survivor 区中每熬过一次 Minor GC ,年龄就增加 1 岁,当它的年龄增加到一定程 度(默认为15 ),就会被晋升到老年代中。

4.动态对象年龄判定

        为了能更好地适应不同程序的内存状况,HotSpot虚拟机并不是永远要求对象的年龄必须达到-XX:MaxTenuringThreshold才能晋升老年代,如果在Survivor空间中相同年龄所有对象大小的总和大于Survivor空间的一半,年龄大于或等于该年龄的对象就可以直接进入老年代,无须等到-XX:MaxTenuringThreshold中要求的年龄。

5.空间分配担保

        虚拟机必须先检查老年代最大可用的连续空间是否大于新生代所有对象总空间,如果这个条件成立,那这一次Minor GC可以确保是安全的。如果不成立,则虚拟机会先查看-

XX:HandlePromotionFailure参数的设置值是否允许担保失败(Handle Promotion Failure);如果允许,那会继续检查老年代最大可用的连续空间是否大于历次晋升到老年代对象的平均大小,如果大于,将尝试进行一次Minor GC,尽管这次Minor GC是有风险的;如果小于,或者-XX:HandlePromotionFailure设置不允许冒险,那这时就要改为进行一次Full GC。

 总结:

               垃圾收集器在许多场景中都是影响系统停顿时间和吞吐能力的重要因素之一,虚拟机之所以提供多种不同的收集器以及大量的调节参数,就是因为只有根据实际应用需求、实现方式选择最优的收集 方式才能获取最好的性能。没有固定收集器、参数组合,没有最优的调优方法,虚拟机也就没有什么 必然的内存回收行为。因此学习虚拟机内存知识,如果要到实践调优阶段,必须了解每个具体收集器 的行为、优势劣势、调节参数。

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值