Java垃圾回收ygc代码模拟

1、先来看看一个成功的按照预想进行了一次ygc的例子

/**
 * ygc测试
 * -Xms10m -Xmx10m -Xmn5m -XX:+UseParallelGC -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:gc.log
       设置10m堆大小,年轻代和老年代各分5m,年轻代里伊甸区4m、两个幸存者区都是0.5m
 * */
public class TestYoungGC2 {
    private static int _1MB = 1024*1024;
    public static void main(String[] args) {
        List cache = new ArrayList<byte[]>();
        //只能循环三次新增3M对象、到第4次就会发生ygc,因为eden本身不是完全4M可用的
        for (int i = 0; i < 4; i++){
            System.out.println("循环" + (i+1) + "开始");
            cache.add(new byte[_1MB]);
            cache.remove(0);
            System.out.println("循环" + (i+1) + "结束");
        }

        System.out.println("此时ygc回收了3M垃圾剩余1M对象、但这1M对象也失去了引用,下一次ygc将被回收");
        cache.add(new byte[2*_1MB]);
        System.out.println("此时又新分配2M对象到eden, 最后新生代3M+, 老年代接近0M");
    }
}

输出:

循环1开始
循环1结束
循环2开始
循环2结束
循环3开始
循环3结束
循环4开始
0.158: [GC (Allocation Failure) [PSYoungGen: 4046K->496K(4608K)] 4046K->644K(9728K), 0.0009270 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
循环4结束
此时ygc回收了3M垃圾剩余1M对象、但这1M对象也失去了引用,下一次ygc将被回收
此时又新分配2M对象到eden, 最后新生代3M+, 老年代接近0M
Heap
PSYoungGen total 4608K, used 3688K [0x00000000ffb00000, 0x0000000100000000, 0x0000000100000000)
eden space 4096K, 77% used [0x00000000ffb00000,0x00000000ffe1e368,0x00000000fff00000)
from space 512K, 96% used [0x00000000fff00000,0x00000000fff7c020,0x00000000fff80000)
to space 512K, 0% used [0x00000000fff80000,0x00000000fff80000,0x0000000100000000)
ParOldGen total 5120K, used 148K [0x00000000ff600000, 0x00000000ffb00000, 0x00000000ffb00000)
object space 5120K, 2% used [0x00000000ff600000,0x00000000ff625010,0x00000000ffb00000)
Metaspace used 2579K, capacity 4486K, committed 4864K, reserved 1056768K
class space used 286K, capacity 386K, committed 512K, reserved 1048576K

 2、再看一个使用byte[]数组模拟ygc的例子,比较特殊

-XX:NewSize=5m -XX:MaxNewSize=5m -XX:InitialHeapSize=10m -XX:MaxHeapSize=10m -XX:SurvivorRatio=8 -XX:+PrintGCDetails -XX:+PrintGCTimeStamps

public class TestYoungGC {
    public static void main(String[] args) {
        byte[] array1 = new byte[1024*1024];
        array1 = new byte[1024*1024];
        array1 = new byte[1024*1024];
        array1 = null; //上面3M对象变成垃圾对象,可以被回收
        byte[] array2 = new byte[2*1024*1024]; //array2在eden分配不下,应该触发ygc
    }
}

运行结果:

Heap
PSYoungGen total 4608K, used 4096K [0x00000000ffb00000, 0x0000000100000000, 0x0000000100000000)
eden space 4096K, 100% used [0x00000000ffb00000,0x00000000fff00000,0x00000000fff00000)
from space 512K, 0% used [0x00000000fff80000,0x00000000fff80000,0x0000000100000000)
to space 512K, 0% used [0x00000000fff00000,0x00000000fff00000,0x00000000fff80000)
ParOldGen total 5120K, used 2048K [0x00000000ff600000, 0x00000000ffb00000, 0x00000000ffb00000)
object space 5120K, 40% used [0x00000000ff600000,0x00000000ff800010,0x00000000ffb00000)
Metaspace used 2577K, capacity 4486K, committed 4864K, reserved 1056768K
class space used 286K, capacity 386K, committed 512K, reserved 1048576K

意料之外的事情发生了:在向eden新分了3M对象之后,array2的2M对象并没有按照剧本来触发ygc回收先前的3M垃圾,然后再把这2M分到eden。

从结果来看是这2M被直接分到老年代了,而eden因为刚好没有满,所以3M垃圾到最后也没有ygc回收掉。

这种现象在 http://www.reins.altervista.org/java/gc1.4.2_faq.html 这篇文章有很好的解释:

有两种情况对象是可能直接进入老年代,而不是尝试在新生代分配:

1、你要分配的对象是一个大数组、且不包含其他对象的引用。

2、你手工设置了-XX:PretenureSizeThreshold参数来指定直接进入老年代的对象的大小。

所以为了导演出原来预期的结果,我们分别模拟下上面的两种方法

1、首先,应该是array2太大了,先把它弄小点,最后试验出来:array2 设置小于等于2*1024*1024 -24触发ygc,大于等于2*1024*1024 -23不触发ygc,直接进入了老年代。

     所以代码修改如下:

public class TestYoungGC {
    public static void main(String[] args) {
        byte[] array1 = new byte[1024*1024];
        array1 = new byte[1024*1024];
        array1 = new byte[1024*1024];
        array1 = null; //上面3M对象变成垃圾对象,可以被回收
        byte[] array2 = new byte[2*1024*1024 - 24]; //array2在eden分配不下,应该触发ygc
    }
}

输出:

0.155: [GC (Allocation Failure) [PSYoungGen: 4046K->496K(4608K)] 4046K->652K(9728K), 0.0011635 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
Heap
PSYoungGen total 4608K, used 2585K [0x00000000ffb00000, 0x0000000100000000, 0x0000000100000000)
eden space 4096K, 51% used [0x00000000ffb00000,0x00000000ffd0a540,0x00000000fff00000)
from space 512K, 96% used [0x00000000fff00000,0x00000000fff7c040,0x00000000fff80000)
to space 512K, 0% used [0x00000000fff80000,0x00000000fff80000,0x0000000100000000)
ParOldGen total 5120K, used 156K [0x00000000ff600000, 0x00000000ffb00000, 0x00000000ffb00000)
object space 5120K, 3% used [0x00000000ff600000,0x00000000ff627010,0x00000000ffb00000)
Metaspace used 2577K, capacity 4486K, committed 4864K, reserved 1056768K
class space used 286K, capacity 386K, committed 512K, reserved 1048576K

终于按照剧本来了!

2、第二个方法,还是byte[] array2 = new byte[2*1024*1024],然后设置-XX:PretenureSizeThreshold=10m ,指定超过10M的对象才能直接进入老年代

     结果:

Heap
PSYoungGen total 4608K, used 4096K [0x00000000ffb00000, 0x0000000100000000, 0x0000000100000000)
eden space 4096K, 100% used [0x00000000ffb00000,0x00000000fff00000,0x00000000fff00000)
from space 512K, 0% used [0x00000000fff80000,0x00000000fff80000,0x0000000100000000)
to space 512K, 0% used [0x00000000fff00000,0x00000000fff00000,0x00000000fff80000)
ParOldGen total 5120K, used 2048K [0x00000000ff600000, 0x00000000ffb00000, 0x00000000ffb00000)
object space 5120K, 40% used [0x00000000ff600000,0x00000000ff800010,0x00000000ffb00000)
Metaspace used 2577K, capacity 4486K, committed 4864K, reserved 1056768K
class space used 286K, capacity 386K, committed 512K, reserved 1048576K

又不按剧本走了!  查阅网上资料,PretenureSizeThreshold这个参数只对Serial和ParNew两款收集器有效,笔者电脑在jdk8环境下默认的垃圾收集器是parallel,不认这个参数。

所以调整一下收集器,再次修改jvm启动参数:

-XX:NewSize=5m -XX:MaxNewSize=5m -XX:InitialHeapSize=10m -XX:MaxHeapSize=10m -XX:SurvivorRatio=8 -XX:PretenureSizeThreshold=10m -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:PretenureSizeThreshold=10m -XX:+UseParNewGC

运行:

0.158: [GC (Allocation Failure) 0.158: [ParNew: 4046K->512K(4608K), 0.0012050 secs] 4046K->632K(9728K), 0.0012951 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
Heap
par new generation total 4608K, used 2601K [0x00000000ff600000, 0x00000000ffb00000, 0x00000000ffb00000)
eden space 4096K, 51% used [0x00000000ff600000, 0x00000000ff80a558, 0x00000000ffa00000)
from space 512K, 100% used [0x00000000ffa80000, 0x00000000ffb00000, 0x00000000ffb00000)
to space 512K, 0% used [0x00000000ffa00000, 0x00000000ffa00000, 0x00000000ffa80000)
tenured generation total 5120K, used 120K [0x00000000ffb00000, 0x0000000100000000, 0x0000000100000000)
the space 5120K, 2% used [0x00000000ffb00000, 0x00000000ffb1e000, 0x00000000ffb1e000, 0x0000000100000000)
Metaspace used 2577K, capacity 4486K, committed 4864K, reserved 1056768K
class space used 286K, capacity 386K, committed 512K, reserved 1048576K
Java HotSpot(TM) 64-Bit Server VM warning: Using the ParNew young collector with the Serial old collector is deprecated and will likely be removed in a future release

终于如愿以偿按照剧本来了,最后变有个warning,意思是仅指定parNew作为新生代收集器的话、jvm默认给搭配的是serial old老年代收集器。要消除warning,手工指定一下别的老年代收集器即可,比如-XX:+UseConcMarkSweepGC

 参考资料:

http://www.reins.altervista.org/java/gc1.4.2_faq.html

https://www.spirithy.com/2019/04/01/trigger-jvm-full-gc-young-gc/

https://www.jianshu.com/p/f7cde625d849

https://www.cnblogs.com/hanlinhu/p/9487049.html

posted on 2020-11-08 17:22  肥兔子爱豆畜子  阅读(500)  评论(0编辑  收藏  举报

导航