JVM垃圾回收机制详解-CSDN博客

本文链接：https://blog.csdn.net/ARSCCC/article/details/114524401

本文深入探讨了JVM的垃圾回收，包括System.gc()的理解，内存溢出与内存泄漏的区分，Stop The World现象，以及并发与并行垃圾回收的区别。强调了手动触发GC的不确定性，内存溢出的常见原因，以及如何避免内存泄漏。此外，还介绍了安全点与安全区域的概念，用于确保GC过程中的线程安全性。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

文章目录

System.gc()的理解
- 手动GC理解不可达对象的回收行为
内存溢出与内存泄漏
Stop The World
垃圾回收的并行与并发
安全点与安全区域

System.gc()的理解

在默认情况下，通过System.gc()或者是Runtime.gc()的调用，会显示的触发Full GC，同时对老年代和新生代进行回收，尝试释放被丢弃对象的内存；
但是System.gc()调用附带有一个免责声明，也就是说即使调用了System.gc()也无法保证对垃圾收集器的调用（也就是无法保证立即触发GC）；
JVM的实现者可以通过System.gc()调用来决定JVM的GC行为，而一般情况下，垃圾回收应该是自动的，无需手动实现的，否则就太过于麻烦了，但是在一些特殊的情况下，比如我们正在编写一个性能基准，我们可以在运行之间调用System.gc()；
以下代码如果注释掉System.runFinalization()，那么控制台就不一定会输出相关的内容，这也证明了System.gc()无法保证GC一定会执行；

public class SystemGCTest {
    public static void main(String[] args) {
        new SystemGCTest();
        System.gc();//提醒jvm的垃圾回收器执行gc,但是不确定是否马上执行gc
        //与Runtime.getRuntime().gc();的作用一样。
        System.runFinalization();//强制调用使用引用的对象的finalize()方法
    }

    @Override
    protected void finalize() throws Throwable {
        super.finalize();
        System.out.println("SystemGCTest 重写了finalize()");
    }
}

手动GC理解不可达对象的回收行为

public class LocalVarGC {
    public void localvarGC1() {
        byte[] buffer = new byte[10 * 1024 * 1024];//10MB
        System.gc();
        //输出: 不会被回收, 因为引用仍然存在, FullGC时被放入老年代
        //[GC (System.gc()) [PSYoungGen: 14174K->10736K(76288K)] 14174K->10788K(251392K), 0.0089741 secs] [Times: user=0.01 sys=0.00, real=0.01 secs]
        //[Full GC (System.gc()) [PSYoungGen: 10736K->0K(76288K)] [ParOldGen: 52K->10649K(175104K)] 10788K->10649K(251392K), [Metaspace: 3253K->3253K(1056768K)], 0.0074098 secs] [Times: user=0.01 sys=0.02, real=0.01 secs]
    }

    public void localvarGC2() {
        byte[] buffer = new byte[10 * 1024 * 1024];
        buffer = null;
        System.gc();
        //输出: 正常被回收, 这时buffer已经为null，引用已经不存在了
        //[GC (System.gc()) [PSYoungGen: 14174K->544K(76288K)] 14174K->552K(251392K), 0.0011742 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
        //[Full GC (System.gc()) [PSYoungGen: 544K->0K(76288K)] [ParOldGen: 8K->410K(175104K)] 552K->410K(251392K), [Metaspace: 3277K->3277K(1056768K)], 0.0054702 secs] [Times: user=0.01 sys=0.00, real=0.01 secs]

    }

    public void localvarGC3() {
        {
            byte[] buffer = new byte[10 * 1024 * 1024];
        }
        System.gc();
        //输出: 不会被回收,虽说System.gc()在代码块的作用域外,但是通过查看字节码文件可以得到在局部变量表中buffer仍然存在, 所以说此时buffer仍然存在引用, 并不会被回收, FullGC时被放入老年代
        //[GC (System.gc()) [PSYoungGen: 14174K->10736K(76288K)] 14174K->10784K(251392K), 0.0076032 secs] [Times: user=0.02 sys=0.00, real=0.01 secs]
        //[Full GC (System.gc()) [PSYoungGen: 10736K->0K(76288K)] [ParOldGen: 48K->10649K(175104K)] 10784K->10649K(251392K), [Metaspace: 3252K->3252K(1056768K)], 0.0096328 secs] [Times: user=0.01 sys=0.01, real=0.01 secs]
    }

    public void localvarGC4() {
        {
            byte[] buffer = new byte[10 * 1024 * 1024];
        }
        int value = 10;
        System.gc();
        //输出: 正常被回收, 此时局部变量表中索引为1的位置被value占用了(索引为0的位置是this), 所以关于buffer的引用已经不存在了, 故此时buffer可以被回收;
        //[GC (System.gc()) [PSYoungGen: 14174K->496K(76288K)] 14174K->504K(251392K), 0.0016517 secs] [Times: user=0.01 sys=0.00, real=0.00 secs]
        //[Full GC (System.gc()) [PSYoungGen: 496K->0K(76288K)] [ParOldGen: 8K->410K(175104K)] 504K->410K(251392K), [Metaspace: 3279K->3279K(1056768K)], 0.0055183 secs] [Times: user=0.00 sys=0.00, real=0.01 secs]
    }

    public void localvarGC5() {
        localvarGC1();
        System.gc();
        //输出: 正常被回收, 因为在localvarGC1()中虽然存在对buffer的引用, 但是由于作用域的原因, 在调用System.gc()的时候, 关于buffer的引用已经不存在了, buffer可以被正常回收; 
        //[GC (System.gc()) [PSYoungGen: 14174K->10720K(76288K)] 14174K->10744K(251392K), 0.0121568 secs] [Times: user=0.02 sys=0.00, real=0.02 secs]
        //[Full GC (System.gc()) [PSYoungGen: 10720K->0K(76288K)] [ParOldGen: 24K->10650K(175104K)] 10744K->10650K(251392K), [Metaspace: 3279K->3279K(1056768K)], 0.0101068 secs] [Times: user=0.01 sys=0.02, real=0.01 secs]
        //[GC (System.gc()) [PSYoungGen: 0K->0K(76288K)] 10650K->10650K(251392K), 0.0005717 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
        //[Full GC (System.gc()) [PSYoungGen: 0K->0K(76288K)] [ParOldGen: 10650K->410K(175104K)] 10650K->410K(251392K), [Metaspace: 3279K->3279K(1056768K)], 0.0045963 secs] [Times: user=0.01 sys=0.00, real=0.00 secs]
    }

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

内存溢出与内存泄漏

内存溢出相对于内存泄漏来说，尽管更容易被理解，但是同样的，内存溢出也是引发程序崩溃的罪魁祸首之一；
由于GC一直在发展，所以一般情况下，除非应用程序占用的内存增长速度非常快，造成垃圾回收已经跟不上内存消耗的速度，否则不太容易出现OOM的情况；
大多数情况下，GC会进行各种年龄段的垃圾回收，实在不行了就放大招，来一次独占式的Full GC操作，这时候会回收大量的内存，供应用程序继续使用；
javadoc中对OutOfMemoryError的解释是，没有空闲内存，并且垃圾收集器也无法提供更多内存；

内存溢出

首先说没有空闲内存的情况：说明Java虚拟机的堆内存不够，原因有二：
- Java虚拟机的堆内存设置不够，比如：可能存在内存泄漏问题；也很有可能就是堆的大小不合理，比如我们要处理比较可观的数据量，但是没有显式指定JVM堆大小或者指定数值偏小。我们可以通过参数-Xms、-Xmx来调整；
- 代码中创建了大量的大对象，并且长时间不能被垃圾收集器收集（存在被引用）对于老版本的OpenJDK，因为永久代的大小是有限的，并且JVM对永久代的垃圾回收（比如常量池回收，卸载不需要的类型）非常不积极，所以当我们不断添加新类型的时候，永久代出现OOM也会变得多见，尤其是在运行时存在大量的动态类型生成的场合，类似inter字符串缓存占用太多的空间，也会导致OOM问题，对应的异常信息会标记出来和永久代相关：“java. lang. OutOfMemoryError:PermGen space”；随着元数据区的引入，方法区的内存已经不再那么的窘迫，所以相应的OOM有所改观，出现OOM时的异常信息则变成了"java.lang.OutOfMemoryError:Metaspace"，当然，直接内存不足也会导致OOM；
这里隐含着一层意思是，在抛出OOM之前，通常垃圾收集器会被触发尽其所能去清理出空间；例如在引用机制分析中，涉及到JVM会去尝试回收软引用指向的对象等；在java.nio.BIts.reserveMemory()方法中，我们能清楚的看到，System.gc()会被调用，以清理空间；
当然也不是在任何情况下垃圾收集器都会被触发的，比如我们去分配一个超大对象，类似一个超大数组超过了堆的最大值，JVM就会判断出垃圾收集并不能解决这个问题，所以便会直接抛出OOM异常；

内存泄漏(Memory Leak)

也称作“存储渗漏”。严格来说，只有对象不会再被程序用到了，但是GC又不能回收他们的情况，才叫内存泄漏；
但实际情况很多时候一些不太好的实践（或疏忽）会导致对象的生命周期变得很长甚至导致OOM，也可以叫做宽泛意义上的“内存泄漏”；
尽管内存泄漏并不会立刻引起程序崩溃，但是一旦发生内存泄漏，程序中的可用内存就会被逐步蚕食，直至耗尽所有内存，最终出现OutOfMemory异常，导致程序崩溃；
注意，这里的存储空间并不是指物理内存，而是指虚拟内存大小，这个虚拟内存大小取决于磁盘交换区设定的大小；

举例

单例模式：单例的生命周期和应用程序是一样长的，所以单例程序中，如果持有对外部对象的引用的话，那么这个外部对象是不能被回收的，则会导致内存泄漏的产生；
一些提供close的资源未关闭导致内存泄漏，比如数据库连接(dataSourse. getConnection()），网络连接（socket）和io连接必须手动close，否则是不能被回收的；

Stop The World

简称STW，指的是GC事件发生过程中，会产生应用程序的停顿。停顿产生时整个应用程序线程都会被暂停，没有任何响应，有点像卡死的感觉，这个停顿称为STW；
可达性分析算法中枚举根节点（GC Roots）会导致所有Java执行线程停顿，分析工作必须在一个能确保一致性的快照中进行；一致性指整个分析期间整个执行系统看起来像被冻结在某个时间点上，如果出现分析过程中对象引用关系还在不断变化，则分析结果的准确性无法保证；
被STW中断的应用程序线程会在完成GC之后恢复，频繁中断会让用户感觉像是网速不快造成电影卡带一样，所以我们需要减少STW的发生；
STW事件和采用哪款GC无关，所有的GC都有这个事件；
哪怕是G1也不能完全避免STW情况发生，只能说垃圾回收器越来越优秀，回收效率越来越高，尽可能地缩短了暂停时间；
STW是JVM在后台自动发起和自动完成的，在用户不可见的情况下，把用户正常的工作线程全部停掉；
开发中不要用System.gc()；会导致STW的发生；
测试代码；

public class StopTheWorldDemo {
    public static class WorkThread extends Thread {
        List<byte[]> list = new ArrayList<byte[]>();

        public void run() {
            try {
                while (true) {
                    for(int i = 0;i < 1000;i++){
                        byte[] buffer = new byte[1024];
                        list.add(buffer);
                    }

                    if(list.size() > 10000){
                        list.clear();
                        System.gc();//会触发full gc，进而会出现STW事件
                    }
                }
            } catch (Exception ex) {
                ex.printStackTrace();
            }
        }
    }

    public static class PrintThread extends Thread {
        public final long startTime = System.currentTimeMillis();

        public void run() {
            try {
                while (true) {
                    // 每秒打印时间信息
                    long t = System.currentTimeMillis() - startTime;
                    System.out.println(t / 1000 + "." + t % 1000);
                    Thread.sleep(1000);
                }
            } catch (Exception ex) {
                ex.printStackTrace();
            }
        }
    }

    public static void main(String[] args) {
        WorkThread w = new WorkThread();
        PrintThread p = new PrintThread();
        w.start();
        p.start();
    }
}

在这里插入图片描述

垃圾回收的并行与并发

并发(Concurrent)

在操作系统中，是指一个时间段中有几个程序都处于己启动运行到运行完毕之间，且这几个程序都是在同一个处理器上运行；
并发不是真正意义上的“同时进行”，只是CPU把一个时间段划分成几个时间片段（时间区间），然后在这几个时间区间之间来回切换，由于CPU处理的速度非常快，只要时间间隔处理得当，即可让用户感觉是多个应用程序同时在进行；

并行(Parallel)

当系统有一个以上CPU时，当一个CPU执行一个进程时，另一个CPU可以执行另一个进程，两个进程互不抢占CPU资源，可以同时进行，我们称之为并行（Parallel）；
其实决定并行的因素不是CPU的数量，而是CPU的核心数量，比如一个CPU多个核也可以并行；
适合科学计算，后台处理等弱交互场景；

二者对比

并发，指的是多个事情，在同一时间段内同时发生了；
并行，指的是多个事情，在同一时间点上同时发生了；
并发的多个任务之间是互相抢占资源的；
并行的多个任务之间是不互相抢占资源的；
只有在多CPU或者一个CPU多核的情况中，才会发生并行。否则，看似同时发生的事情，其实都是并发执行的；

垃圾回收的并发与并行

并发和并行，在谈论垃圾收集器的上下文语境中，他们可以解释如下：并行 (Parallel) ：指多条垃圾收集线程并行工作，但此时用户线程仍处于等待状态；如ParNew、 Parallel Scavenge、 Parallel Old；串行（Serial）：相较于并行的概念，单线程执行；如果内存不够，则程序暂停，启动JVM垃圾回收器进行垃圾回收。回收完，再启动程序的线程；
并发(Concurrent)：指用户线程与垃圾收集线程同时执行（但不一定是并行的，可能会交替执行），垃圾回收线程在执行时不会停顿用户程序的运行；用户程序在继续运行，而垃圾收集程序线程运行于另一个CPU上；如：CMS、G1；

安全点与安全区域

安全点(Safepoint)

程序执行时并非在所有地方都能停顿下来开始GC，只有在特定的位置才能停顿下来开始GC，这些位置称为“安全点(Safepoint)”
Safe Point的选择很重要，如果太少可能导致GC等待的时间太长，如果太频繁可能导致运行时的性能问题。大部分指令的执行时间都非常短暂，通常会根据“是否具有让程序长时间执行的特征”为标准。比如：选择些执行时间较长的指令作为Safe Point，如方法调用、循环跳转和异常跳转等；

如何在GC发生时，检查所有线程都跑到最近的安全点停顿下来呢？

抢先式中断：（目前没有虚拟机采用了）首先中断所有线程。如果还有线程不在安全点，就恢复线程，让线程跑到安全点；
主动式中断：设置一个中断标志，各个线程运行到Safe Point的时候主动轮询这个标志，如果中断标志为真，则将自己进行中断挂起；

安全区域(Safe Region)

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