垃圾回收案例——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主线程的执行异常。