25.垃圾回收相关概念

最新推荐文章于 2021-12-26 20:20:11 发布

夹毛局的程序员

最新推荐文章于 2021-12-26 20:20:11 发布

阅读量120

点赞数

分类专栏： JVM

本文链接：https://blog.csdn.net/woshiwjma956/article/details/113184704

版权

JVM 专栏收录该内容

33 篇文章 1 订阅

订阅专栏

System.gc()的理解

默认情况下,通过System.gc()或者Runtime.getRuntime().gc()调用,会显示触发FullGC,同时对新生代和老年代进行回收,尝试释放丢失对象占用的内存
System#gc有一条免责声明,无法保证对垃圾收集器的调用,不一定保证立即生效
JVM实现者可以通过System#gc调用来决定JVM的GC行为.一般情况下垃圾回收是自动进行的,无须手动触发.一些特殊情况下,如性能测试基准之前可以显示调用一下gc

public class SystemGCTest {
    public static void main(String[] args) {
        new SystemGCTest();
        // 提醒JVM进行垃圾回收
        System.gc();
        //System.runFinalization();
    }

    @Override
    protected void finalize() throws Throwable {
        super.finalize();
        System.out.println("SystemGCTest 执行了 finalize方法");
    }
}
// 每次执行不一定调用gc 表现为不一定打印finalize方法
// 调用System.runFinalization()会强制调用 失去引用对象的finalize()

手动触发GC理解

public class LocalVarGC {

    /**
     * 因为buffer变量的存在 内存中还存在引用 gc不会回收buffer
     */
    public void localvarGC1() {
        byte[] buffer = new byte[10*1024*1024];
        System.gc();
    }

    /**
     * 因为buffer已经被置空,触发GC之后会回收buffer
     */
    public void localvarGC2() {
        byte[] buffer = new byte[10*1024*1024];
        buffer = null;
        System.gc();
    }

    /**
     * 触发GC不会回收buffer,虽然看似buffer在当前作用域已经没有被使用,但他还在localvarGC3这个方法的局部变量中slot1中
     * 此时通过jclasslib查看 当前方法的Max local variables 数量是2 但局部变量表中只有slot0的this 其实buffer这个变量还存在在slot1中
     */
    public void localvarGC3() {
        {
            byte[] buffer = new byte[10*1024*1024];
        }
        System.gc();
    }

    /**
     * 会回收buffer,因为此时slot1这个位置已经被value这个变量占据,buffer已经变成了不可达状态被回收
     */
    public void localvarGC4() {
        {
            byte[] buffer = new byte[10*1024*1024];
        }
        int value = 10;
        System.gc();
    }

    /**
     * 因为localVarGC1执行完毕,虚拟机栈中的方法出栈导致buffer变量变成不可达状态被回收
     */
    public void localvarGC5() {
        localvarGC1();
        System.gc();
    }

    public static void main(String[] args) {
        LocalVarGC localVarGC = new LocalVarGC();
        localVarGC.localvarGC3();
    }
}

内存溢出

内存溢出相对于内存泄漏来说,更加容易理解,也是程序崩溃的原因之一
由于GC一直发展,一般情况下,除非应用程序占用内存增长速度非常快,造成垃圾回收已经跟不上内存消耗的速度,否则不太容易出现OOM的情况
大多数情况下,GC会进行各年龄段的垃圾回收,实在不行就触发FullGC,这时会回收大量内存
javadoc堆OOM的定义是没有空闲内存,且垃圾回收器也无法提供更多内存
没有空闲内存,说明JVM内存不够,原因有二
- JVM虚拟机堆内存-Xmx设置不够
  - 比如可能出现内存泄漏,也很可能本身就是堆大小不合理.可以通过-Xms -Xmx调整
- 代码中创建了大量大对象,并且长时间处于可达状态不能被GC回收
老版本的JDK,因为永久代大小有限,并且JVM堆永久代垃圾回收(通常如常量池,卸载不再需要的类型)非常不积极,所以当我们不断添加新类型的时候,永久代就会出现OOM也非常多见,尤其是在运行大量动态类生成的场景,类似intern字符串缓存占用太多空间,也会导致OOM,对应异常信息,也会标记与永久代相关java.lang.OutOfMemoryError:PermGen spac
随着元空间的引入,元空间独立使用本地内存,不再占用方法区类型,使得方法区更不容易出现OOM,但本地内存不存也会报OOM异常,java.lang.OutofMemoryError:Metaspace
在报OOM之前,一定会触发一次垃圾回收器尽可能的清理空间,对应HotSpot会触发FullGC
也不是任何情况下都会触发GC回收,比如分配一个超大对象,类似一个超大数组超过堆的最大值,JVM可以判断出垃圾收集并不能解决这个问题,所以直接抛出OOM

内存泄漏

也成为存储泄漏,严格来说,只要对象不会被程序用到,但是GC又不能回收他们的情况,才叫内存泄漏
实际情况很多时候一些不太好实践或疏忽会导致对象的生命周期变成很长甚至导致OOM,也可以宽泛意义上的内存泄漏
内存泄漏并不会立刻引起程序崩溃,但是一旦发生内存泄漏,程序中的可用内存就会逐步减少,直到耗尽所有内存最终导致OOM
这里的存储空间并不是物理内存,是指虚拟机内存,这个虚拟内存大小取决于磁盘交换区设定的大小
java的可达性分析算法,数据不可达,但是需要被回收.后期一些对象不用了,但是因为存在引用链没有断开导致状态为可达导致无法被回收发生了内存泄漏
举例
- 单例模式单列模式生命周期与应用程序一样长,所有单例模式中,如果持有堆外部对象的引用的话,那么这个外部对象是不能被回收的,可能会产生内存泄漏
- 一些closable资源未关闭导致内存泄漏
  - 如数据库连接,socket连接,IO连接等需要手动关闭,不然无法被回收

Stop The World

简称STW,指在GC时间发生过程中,会产生应用程序的停顿,停顿产生时整个而应用程序线程都会暂停,没有任何响应,像卡死一样,这个停顿成为STW
可达性分析算法枚举根节点GC Roots会导致java执行线程的停顿
- 分析工作必须在一个能确保一致性的快照中进行
- 一致性指整个分析期间整个执行系统看起来像被冻结在某一个时间点上
- 如果出现分析过程中对象引用关系还在不断发生变化,则无法保证分析的准确性
STW无论采用哪种GC都会存在,只是说STW的事件长短不同
G1也无法完全避免STW的发生,只能说垃圾回收器越来越优秀,回收效率越来越高,尽可能缩短STW时间
STW是JVM在后台自动发起和自动完成的.在用户不可见的情况下,把用户正常的工作线程全部挂起
开发中不要使用System.gc()会导致STW的出现

垃圾收集的并行和并发

并发Concurrent
- 操作系统中,指一个时间段中有几个程序都处于启动到运行完毕之间,且这几个程序都在同一个处理器上运行
- 并不能真正意义上的同时进行,只有CPU把一个时间段划分成几个小的片段,然后在这个时间区间之间来回切换,由于CPU处理速度非常快,只要时间间隔处理得当,即可让用户感觉多个应用程序同时在进行
并行Parallel
- 当系统有一个以上CPU时,当一个CPU执行一个进程,另外一个CPU执行另一个进程,两个进程相互不抢占CPU资源,可以同时进行,我们成为并行Parallel
- 决定并行的因素并一是CPU的个数,而是CPU的核心数,一个CPU多核也可以进行并行
- 适合科学计算,后台处理等弱交互场景
并行并发区别
- 并发: 多个事情,在同一时间段同时发生
- 并行: 多个事情,在同一时间点同时发生
- 并行多个任务相互抢占资源,并发多任务不会相互抢占资源
- 只有在多CPU或者多核才会发生并行
垃圾回收的并行和并发
- 并行 parallel: 多条垃圾收集器线程并行工作,但此时用户线程扔处于等待状态.如ParNew,Parallel Scavenage,Parallel old
- 串行 Serial
  - 相较于并行的概念,单线程执行
  - 如果内存不够,则程序暂停,启动JVM垃圾回收器进行回收,回收完之后再启动程序线程
- 并发 Concurrent: 用户线程与垃圾收集线程同时执行,但不一定是并行可能会交替执行,垃圾回收线程在执行时不会停顿用户程序运行.用户程序在继续运行,而垃圾收集线程运行在另一个CPU上如CMS G1

安全点和安全区域

安全点

程序执行时并非在所有的地方都能停顿下来GC,只能在特定的位置才能停顿下来进行GC,这些位置成为安全点 Safe Point
Safe Point的选择很重要,如果太少可能导致GC等待的时间太长,如果太频繁可能导致运行时的性能问题.大部分指令的执行时间都非常短,通常会根据是否具有让程序长时间执行的特性为标准.比如选择一些执行时间较长的指令作为Safe Point,如方法调用,循环跳转和异常跳转等
如何在GC发生时,检查所有线程都跑到了最近的安全点下停顿?
- 抢占式中断: 首先中断所有线程.如果还有线程不在安全点,就恢复线程,让线程跑到安全点.目前已经没有虚拟机采用了
- 主动式中断: 设置一个中断标志,各个线程运行到Safe Point的时候主动轮询这个标志,如果中断标志为真,则将自己进行中断挂起

安全区域

SafePoint机制保证了程序执行时,在不长的时间就会遇到可以进入的GC的SafePoint.但是如果程序不执行的时候呢? 例如线程处于Sleep或者Block状态,这时候线程无法响应JVM中断请求,走到安全点去中断挂起,JVM也不太可能等待线程被唤醒.对于这种情况就需要一个安全区域Safe Region来解决
安全区域是指一段代码片段中,对象引用关系不会发生变化,在这个区域中的任何位置开始GC都是安全的,我们把这个Safe Region也可以看到一个扩展的Safe Point
执行流程
- 当线程运行到Safe Regoin代码时,首先标志已经进入了Safe Region,如果这段时间发生GC,JVM会忽略表示为Safe Region状态的线程
- 当线程即将离开Safe Region时,会检查JVM是否已经完成GC,如果完成,则继续运行,否则线程必须等待直到收到可以安全离开Safe Region的信号为止

引用问题

强引用 Strong Reference GC不回收
软引用 Soft Reference 内存不够时回收
弱引用 Weak Reference 下一次触发GC回收
虚引用 Phantom Reference 为让对象被GC回收时得到一个通知
上述4种引用强度一次递减.除强引用外,其他引用均在java.lang.ref包下
Refrence子类中只有终结器引用包可见,其他3个引用类型都是public

强引用 Stribg Reference

最传统的引用定义,只在程序代码中普遍存在的引用赋值,即类似Object obj = new Object()这种引用关系.任何情况下只要强引用关系还存在,GC就永远不会回收被引用对象
最常见的对象引用,开发中99%都是强引用,默认的引用类型
在java在中使用new关键字创建一个对象,并赋值给一个变量,这个变量就成为该对象的一个强引用
强引用对象如果是可触及的,GC永远不会回收该对象
一个普通对象没有其他引用关系,只要超过引用的作用域或者强制赋值为null,就是可以被当做垃圾回收
相对的,软引用,弱引用和虚引用的对象是软可触及,弱可触及和虚可触及的.在一定条件下,都是可以被回收的.强引用是java内存泄漏的主要原因之一

举例

强引用的案例说明

StringBuffer str = new StringBuffer("hello");

局部变量str指向stringBuffer实例所在堆空间，通过str可以操作该实例，那么str就是stringBuffer实例的强引用对应内存结构：

如果此时，在运行一个赋值语句

StringBuffer str = new StringBuffer("hello mogublog");
StringBuffer str1 = str;

对应的内存结构为:

那么我们将 str = null; 则原来堆中的对象也不会被回收，因为还有其它对象指向该区域

强引用特点

强引用可以直接访问到目标对象
强引用指向的对象在任何时候不会被GC回收,宁可抛出OOM也不会回收被强引用指向的对象
强引用可能导致内存泄漏

软引用

软引用用于描述一些还有用但非必须的对象.只被软引用关联的对象,在系统将要发生内存溢出的时候,会把对象列入回收范围之中进行第二次回收(第一次只回收不可达对象,如果不可达回收完了还不够内存再考虑回收软引用),如果这次回收还不够内存,才会抛出OOM
软引用通常用来实现内存敏感的缓存.比如:高速缓存就用到软引用.如果还有空闲内存就暂时保留缓存,如果内存不足清理掉.保证使用缓存的同时也不会耗尽内存
GC在某一个时刻决定回收软可达对象的时候,会先清理软引用,并把可选地址引用存放在一个引用队列Reference Queue
类似弱引用,只不过JVM会尽量让软引用存活时间长,只有在内存即将不存的时候才回收
内存足够,不回收软引用可达对象;内存不够,会回收软引用可达对象

// 声明强引用
Object obj = new Object();
// 创建一个软引用
SoftReference<Object> sf = new SoftReference<>(obj);
obj = null; //销毁强引用，这是必须的，不然会存在强引用和软引用

弱引用

弱引用描述非必须对象,被弱引用关联的对象只能生存到下一次垃圾收集发生为止,在系统GC时,只要发现弱引用,不管系统堆空间是否充足,都会回收掉弱引用关联的对象
但是由于GC线程优先级很低,不一定能很快发现持有弱引用对象,这种情况下弱引用对象可以存活较长的时间
弱引用和软引用一样,在构建弱引用时,也可以指定一个引用队列,在弱引用对象被回收时,就会加入指定的引用对象,通过这个队列可以跟踪对象的回收情况
软引用,弱引用都非常适合保存缓存数据,这样在当堆内存不足的时候,缓存数据才会被回收,不会导致内存溢出.当内存资源充足的时候,缓存数据又可以存活很长时间,达到提高响应速度

// 声明强引用
Object obj = new Object();
// 创建一个弱引用
WeakReference<Object> sf = new WeakReference<>(obj);
obj = null; //销毁强引用，这是必须的，不然会存在强引用和弱引用

弱引用对象与软引用对象的最大不同在于,当GC进行回收时,需要通过算法检查是否回收软引用对象,对弱引用对象GC总是进行回收.弱引用更容易被GC回收
WeakHashMap 就是使用弱引用思想,当内存不足的时候及时回收

虚引用

又称幽灵引用或者幻影引用是所有引用类型中最弱的一个
一个对象是否有虚引用的存在,完全不会决定对象的生命周期,如果一个对象仅持有虚引用,那么他和没有引用几乎一样,随时可能被GC回收
他不能单独使用,也无法通过虚引用来获取被引用对象.当通过虚引用get()方法取得对象永远返回null
为对象设置虚引用关联的唯一目的就在于跟踪GC回收过程.比如能在一个对象被GC回收时收到一个系统通知
虚引用必须和引用队列一起使用,虚引用在创建时必须提供一个引用队列作为参数.当GC准备回收一个对象时,如果发现还存在虚引用,就会在回收对象之后,将虚引用加入引用队列,以通知应用程序对象回收情况
由于虚引用可以跟踪对象的回收时间,因此也可以将一些资源释放操作放置在虚引用执行和记录

// 声明强引用
Object obj = new Object();
// 声明引用队列
ReferenceQueue phantomQueue = new ReferenceQueue();
// 声明虚引用（还需要传入引用队列）
PhantomReference<Object> sf = new PhantomReference<>(obj, phantomQueue);
obj = null;

虚引用案例

public class PhantomReferenceTest {
    // 当前类对象的声明
    public static PhantomReferenceTest obj;
    // 引用队列
    static ReferenceQueue<PhantomReferenceTest> phantomQueue = null;

    @Override
    protected void finalize() throws Throwable {
        super.finalize();
        System.out.println("调用当前类的finalize方法");
        obj = this;
    }

    public static void main(String[] args) {
        Thread thread = new Thread(() -> {
            while(true) {
                if (phantomQueue != null) {
                    PhantomReference<PhantomReferenceTest> objt = null;
                    try {
                        objt = (PhantomReference<PhantomReferenceTest>) phantomQueue.remove();
                    } catch (Exception e) {
                        e.getStackTrace();
                    }
                    if (objt != null) {
                        System.out.println("追踪垃圾回收过程：PhantomReferenceTest实例被GC了");
                    }
                }
            }
        }, "t1");
        thread.setDaemon(true);
        thread.start();

        phantomQueue = new ReferenceQueue<>();
        obj = new PhantomReferenceTest();
        // 构造了PhantomReferenceTest对象的虚引用，并指定了引用队列
        PhantomReference<PhantomReferenceTest> phantomReference = new PhantomReference<>(obj, phantomQueue);
        try {
            System.out.println(phantomReference.get());
            // 去除强引用
            obj = null;
            // 第一次进行GC，由于对象可复活，GC无法回收该对象
            System.out.println("第一次GC操作");
            System.gc();
            Thread.sleep(1000);
            if (obj == null) {
                System.out.println("obj 是 null");
            } else {
                System.out.println("obj 不是 null");
            }
            System.out.println("第二次GC操作");
            obj = null;
            System.gc();
            Thread.sleep(1000);
            if (obj == null) {
                System.out.println("obj 是 null");
            } else {
                System.out.println("obj 不是 null");
            }
        } catch (Exception e) {
            e.printStackTrace();
        } finally {

        }
    }
}

null
第一次GC操作
调用当前类的finalize方法
obj 不是 null
第二次GC操作
追踪垃圾回收过程：PhantomReferenceTest实例被GC了
obj 是 null

尝试从虚引用get()获取对象永远是null
第一次触发GC,对象为可复活状态,调用finalize方法中obj=this,使得对象复活,此时打印obj不为null
第一次触发GC,由于GC只会调用finalize方法一次,当将obj再次置空,GC直接回收对象
在GC回收对象的同时也将回收的值存入到了引用队列中

总结

	强引用	软引用	弱引用	虚引用
GC回收时期	永远不回收	内部不足	下次GC执行	随时

终结器引用

它用于实现对象的finalize() 方法，也可以称为终结器引用

无需手动编码，其内部配合引用队列使用

在GC时，终结器引用入队。由Finalizer线程通过终结器引用找到被引用对象调用它的finalize()方法，第二次GC时才回收被引用的对象

夹毛局的程序员

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
复制链接

分享到 QQ

分享到新浪微博

扫一扫

专栏目录