垃圾回收案例——GC分析

GC 分析

首先运行一段空的代码,并设置虚拟机参数:“-Xms20M -Xmx20M -Xmn10M -XX:+UseSerialGC -XX:+PrintGCDetails -verbose:gc” 。


public class Demo {

    private static final int _512KB = 512*1024;
    private static final int _1MB = 1024*1024;
    private static final int _6MB = 6*1024*1024;
    private static final int _7MB = 7*1024*1024;
    private static final int _8MB = 8*1024*1024;

    // -Xms20M -Xmx20M -Xmn10M -XX:+UseSerialGC -XX:+PrintGCDetails -verbose:gc
    // -Xms20M -Xmx20M (初始和最大的堆空间20M)
    // -Xmn10M (新生代10M)
    // -XX:+UseSerialGC(垃圾回收器)
    // -XX:+PrintGCDetails -verbose:gc(打印GC的详情)
    public static void main(String[] args) {

    }

}

上面的运行结果为:

无任何代码逻辑时堆空间

 上图可以看出堆主要分为new generation(新生代)、tenured generation(老年代)、Metaspace(元空间)。

对于新生代来,我们在JVM参数给新生代分配了10M,但是上图新生代的Total仅有9216K,少了1024K,是因为默认幸存区To的空间是不能使用的,所以新生代的空间为9216K。eden spance 占有8M,虽然我们没有任何的逻辑,此时的伊甸园中已经有26%的内存已经被使用,是因为在程序运行的时候就会默认加载一些对象,这些对象都放在了伊甸园中。

那如果我们往堆内存中放入一个7M的对象又会发生什么呢?

由图中可以看出在插入一个7M对象的时候,进行了一次垃圾回收,而且是Minor GC(如果是Full GC则会输出Full GC),垃圾回收中的信息DefNew 说明这个是在新生代中的进行的垃圾回收,2004K->600K(9216K)的意思是回收前的占用为2004K,回收后内存占有600K然后总的内存大小为9216K,然后用时0.0333417秒。再这之后的信息是整个堆内存的一个信息,前面是关于新生代的。堆内存在回收钱占用2004K,回收后占用600K整个堆内存共计19456K,堆内存的回收共计耗时为0.0386088秒。

在输出信息的下面就是堆内存中新生代、老年代的各个信息。可以看出From区占用了58%的空间,虽然to占用0%,但是在回收的过程中是先放置To区然后再交换From和To区。

如果在上面的代码中我们在添加两个521KB的对象又是什么样的效果?

添加第一个512KB对象
添加第二个512KB的对象

 

 


 

 

 

 

 

 

 很清楚的可以看出在添加第一个512KB对象的时候伊甸园的空间还是比较充足的,只是添加之后已经使用了96%,而且添加的过程中也只执行了一次GC。添加第二个512KB的对象时,伊甸园的空间很明显是不够的,所以再次进行了一次垃圾回收,显然这次的回收的即使回收新生代,也不能满足的空间需求,所以很多对象已经晋升到老年代,虽然没有超过阈值,是因为此时内存十分紧张。

GC 大对象

在往堆内存放入对象的时候,如果放入的对象超过了伊甸园的大小,这个时候JVM该如何处理呢?

因为我们设置虚拟机参数的时候已经设置了伊甸园的大小为8M,这个时候如果插入一个8M的对象,伊甸园即新生代整个区域都放不下这个对象,就算此时触发新生代的垃圾回收,也放不下这个8M对象。这个时候如果老年代的空间足够,会把这个大的对象直接晋升放入老年代中去,而且这种情况下不会触发垃圾回收。

如果插入两个8M的对象,此时很明显堆的空间不足,所以会报错,但是在报错之前,JVM还是会进行挽救,会进行Full GC,而Full Gc会触发Minor GC。

当内存溢出放在一个子线程中,并不会导致Java主线程的执行异常。

 

猜你喜欢

转载自blog.csdn.net/qq_35363507/article/details/104934530
今日推荐