美文网首页
垃圾回收机制(下)你真的懂了吗?

垃圾回收机制(下)你真的懂了吗?

作者: 问心2018 | 来源:发表于2020-12-13 13:40 被阅读0次

    1.1 如何进行垃圾回收

    由于垃圾收集算法的实现涉及大量的程序细节,各家虚拟机厂商对其实现细节各不相同,因此本课时并不会过多的讨论算法的实现,只是介绍几种算法的思想以及优缺点。

    1.1.1 标记清除算法(Mark and Sweep GC)

    • Mark 标记阶段:找到内存中的所有 GC Root 对象,只要是和 GC Root 对象直接或者间接相连则标记为灰色(也就是存活对象),否则标记为黑色(也就是垃圾对象)。
    • Sweep 清除阶段:当遍历完所有的 GC Root 之后,则将标记为垃圾的对象直接清除。
    image
    • 优点:实现简单,不需要将对象进行移动。
    • 缺点:这个算法需要中断进程内其他组件的执行(stop the world),并且可能产生内存碎片,提高了垃圾回收的频率。

    1.1.2 复制算法(Copying)

    • 复制算法之前,内存分为 A/B 两块,并且当前只使用内存 A,内存的状况如下图所示:


      image
    • 标记完之后,所有可达对象都被按次序复制到内存 B 中,并设置 B 为当前使用中的内存。内存状况如下图所示:

    image
    • 优点:按顺序分配内存即可,实现简单、运行高效,不用考虑内存碎片。
    • 缺点:可用的内存大小缩小为原来的一半,对象存活率高时会频繁进行复制。

    1.1.3 标记-压缩算法 (Mark-Compact)

    • Mark 标记阶段:找到内存中的所有 GC Root 对象,只要是和 GC Root 对象直接或者间接相连则标记为灰色(也就是存活对象),否则标记为黑色(也就是垃圾对象)。
    • Compact 压缩阶段:将剩余存活对象按顺序压缩到内存的某一端。
    image
    • 优点:这种方法既避免了碎片的产生,又不需要两块相同的内存空间,因此,其性价比比较高。
    • 缺点:所谓压缩操作,仍需要进行局部对象移动,所以一定程度上还是降低了效率。

    1.2 JVM分代回收策略

    Java虚拟机根据对象存活的周期不同,把堆内存划分为几块,一般为新生代,老年代注意: 在 HotSpot 中除了新生代和老年代,还有永久代。

    分代回收的中心思想就是:对于新创建的对象会在新生代中分配内存,次区域对象生命周期较短,多次回收不掉的就会转移大老年代中。

    1.2.1 新生代

    新生成的对象优先存放在新生代中,新生代对象朝生夕死,存活率很低,在新生代中,常规应用进行一次垃圾收集一般可以回收 70%~95% 的空间,回收效率很高。新生代中因为要进行一些复制操作,所以一般采用的 GC 回收算法是复制算法。

    新生代又可以继续细分为 3 部分:Eden、Survivor0(简称 S0)、Survivor1(简称S1)。这 3 部分按照 8:1:1 的比例来划分新生代。这 3 块区域的内存分配过程如下:

    绝大多数刚刚被创建的对象会存放在 Eden 区。如图所示:

    image

    当 Eden 区第一次满的时候,会进行垃圾回收。首先将 Eden区的垃圾对象回收清除,并将存活的对象复制到 S0,此时 S1是空的。如图所示:

    image

    下一次 Eden 区满时,再执行一次垃圾回收。此次会将 Eden和 S0区中所有垃圾对象清除,并将存活对象复制到 S1,此时 S0变为空。如图所示:

    image

    如此反复在 S0 和 S1之间切换几次(默认 15 次)之后,如果还有存活对象。说明这些对象的生命周期较长,则将它们转移到老年代中。如图所示:

    image

    1.2.2 老年代

    一个对象如果在新生代存活了足够长的时间而没有被清理掉,则会被复制到老年代。老年代的内存大小一般比新生代大,能存放更多的对象。如果对象比较大(比如长字符串或者大数组),并且新生代的剩余空间不足,则这个大对象会直接被分配到老年代上。老年代因为对象的生命周期较长,不需要过多的复制操作,所以一般采用标记压缩的回收算法。

    注意:对于老年代可能存在这么一种情况,老年代中的对象有时候会引用到新生代对象。这时如果要执行新生代 GC,则可能需要查询整个老年代上可能存在引用新生代的情况,这显然是低效的。所以,老年代中维护了一个 512 byte 的 card table,所有老年代对象引用新生代对象的信息都记录在这里。每当新生代发生 GC 时,只需要检查这个 card table 即可,大大提高了性能

    1.3 引用

    上文中已经介绍过,判断对象是否存活我们是通过GC Roots的引用可达性来判断的。但是JVM中的引用关系并不止一种,而是有四种,根据引用强度的由强到弱,他们分别是:强引用(Strong Reference)、软引用(Soft Reference)、弱引用(Weak Reference)、虚引用(Phantom Reference)

    image

    平时项目中,尤其是Android项目,因为有大量的图像(Bitmap)对象,使用软引用的场景较多。所以重点看下软引用SoftReference的使用,不当的使用软引用有时也会导致系统异常。

    1.3.1 引用软引用常规使用

      public class SoftReferenceDemo {
    static class SoftObject {
        byte[] data = new byte[1*1200 * 1024 * 1024];//120M
    }
    
    public static void main(String[] args) throws InterruptedException{
        //将缓存数据用软引用持有
        SoftReference<SoftObject> cacheRef = new SoftReference<>(new SoftObject());
        System.out.println("第一次gc前 软引用" + cacheRef.get());
        //进行一次gc后查看对象的回收情况
        System.out.println("第一次gc后 软引用" + cacheRef.get());
    
        //再分配一个120M的对象 看看缓存对象的回收情况
        SoftObject newSo = new SoftObject();
        System.out.println("再分配120M强引用对象之后 软引用" + cacheRef.get());
    
    }
    }
    

    执行:java -Xmx200m SoftReferenceDemo

    运行结果:

    第一次gc前 软引用com.example.leetcode.SoftReferenceDemoSoftObject@66d3c617 第一次gc后 软引用com.example.leetcode.SoftReferenceDemoSoftObject@66d3c617
    再分配120M强引用对象之后 软引用
    null

    首先通过-Xmx将堆最大内存设置为200M。从日志中可以看出,当第一次GC时,内存中还有剩余可用内存,所以软引用并不会被GC回收。但是当我们再次创建一个120M的强引用时,JVM可用内存已经不够,所以会尝试将软引用给回收掉。

    1.4 总结:

    本课时着重讲解了 JVM 中有关垃圾回收的相关知识点,其中重点介绍了使用可达性分析来判断对象是否可以被回收,以及 3 种垃圾回收算法。

    虚拟机垃圾回收机制很多时候都是影响系统性能、并发能力的主要因素之一。尤其是对于从事 Android 开发的工程师来说,有时候垃圾回收会很大程度上影响 UI 线程,并造成界面卡顿现象。

    相关文章

      网友评论

          本文标题:垃圾回收机制(下)你真的懂了吗?

          本文链接:https://www.haomeiwen.com/subject/fqiugktx.html