JVM Survivor行为一探究竟

MaxTenuringThreshold:

说到Survivor就不得不提及这个参数,笨神(微信公众号:"你假笨", 想学习JVM调优的话,强烈推荐关注这个公众号)昨天在JVM分享群里分享了这个参数, 总结如下:
这个参数主要作用是设置在YGC的时候,新生代的对象正常情况下最多经过多少次YGC的过程会晋升到老生代,注意是表示最多而不是一定,也就是说某个对象的age其实并不是一定要达到这个值才会晋升到Old的,当你设置这个值的时候,第一次会以它为准,后面的就不一定以它为准了,而是JVM会自动计算在0~15之间决定,但不会超过这个值。如果配置了CMS GC,这个值默认是6;PS的话这个值默认是15。这个值最大你可以设置到15,因为jvm里就4个bit来存这个值,所以最大就是1111,即15;

引申问题

那么JVM是怎么计算接下来S区的对象晋升到Old区的age的呢?介绍两个重要的JVM参数:

-XX:TargetSurvivorRatio

一个计算期望S区存活大小(Desired survivor size)的参数. 默认参数为50,即50%。可参考JVMPocket。

PrintTenuringDistribution

输出S区各个age的对象信息, 用法:-XX:+PrintTenuringDistribution, -XX:-PrintTenuringDistribution
例如, gc日志如下:
new threshold 1 (max 6)
- age 1: 1048608 bytes, 1048608 total
- age 2: 524304 bytes, 1572912 total

当一个S区中各个age的对象的总size大于或等于Desired survivor size ( TargetSurvivorRatio * S0 / 100 ),则重新计算age,以age和MaxTenuringThreshold两者的最小值为准;验证这个结论的Java代码如下:

public class GcSurvivorTest {

    public static void main(String[] args) throws InterruptedException {

        // 这两个对象不会被回收, 用于在s0和s1不断来回拷贝增加age直到达到PretenureSizeThreshold晋升到old
        byte[] byte1m_1 = new byte[1 * 512 * 1024];
        byte[] byte1m_2 = new byte[1 * 512 * 1024];

        // YoungGC后, byte1m_1 和 byte1m_2的age为1
        youngGc(1);
        Thread.sleep(3000);

        // 再次YoungGC后, byte1m_1 和 byte1m_2的age为2
        youngGc(1);
        Thread.sleep(3000);

        // 第三次YoungGC后, byte1m_1 和 byte1m_2的age为3
        youngGc(1);
        Thread.sleep(3000);

        // 这次再ygc时, 由于byte1m_1和byte1m_2的年龄已经是3,且MaxTenuringThreshold=3, 所以这两个对象会晋升到Old区域,且ygc后, s0(from)和s1(to)空间中的对象被清空
        youngGc(1);
        Thread.sleep(3000);

        // main方法中分配的对象不会被回收, 不断分配是为了达到TargetSurvivorRatio这个比例指定的值, 即5M*60%=3M(Desired survivor size),说明: 5M为S区的大小,60%为TargetSurvivorRatio参数指定,如下三个对象分配后就能够达到Desired survivor size
        byte[] byte1m_4 = new byte[1 * 1024 * 1024];
        byte[] byte1m_5 = new byte[1 * 1024 * 1024];
        byte[] byte1m_6 = new byte[1 * 1024 * 1024];

        // 这次ygc时, 由于s区已经占用达到了60%(-XX:TargetSurvivorRatio=60), 所以会重新计算对象晋升的age,计算公式为:min(age, MaxTenuringThreshold) = 1
        youngGc(1);
        Thread.sleep(3000);

        // 由于前一次ygc时算出age=1, 所以这一次再ygc时, byte1m_4, byte1m_5, byte1m_6就会晋升到Old区, 而不需要等MaxTenuringThreshold这么多次, 此次ygc后, s0(from)和s1(to)空间中对象再次被清空, 对象全部晋升到old
        youngGc(1);
        Thread.sleep(3000);

        System.out.println("hello world");
    }

    private static void youngGc(int ygcTimes){
        for(int i=0; i

代码配套的JVM参数(Eden: 40M, S0/S1: 5M, Old: 150M):
-verbose:gc -Xmx200M -Xmn50M -XX:TargetSurvivorRatio=60 -XX:+PrintTenuringDistribution -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:MaxTenuringThreshold=3

由于JVM参数申明了-verbose:gc, 所以直接可以通过控制台输出gc日志信息验证上面的结论,gc日志如下:

2017-07-22T16:23:48.792+0800: [GC (Allocation Failure) 2017-07-22T16:23:48.792+0800: [ParNew
Desired survivor size 3145728 bytes, new threshold 3 (max 3)
- age   1:    1643904 bytes,    1643904 total
: 40448K->1613K(46080K), 0.0016580 secs] 40448K->1613K(123904K), 0.0029600 secs] [Times: user=0.03 sys=0.00, real=0.00 secs] 
2017-07-22T16:23:51.802+0800: [GC (Allocation Failure) 2017-07-22T16:23:51.802+0800: [ParNew
Desired survivor size 3145728 bytes, new threshold 3 (max 3)
- age   2:    1640840 bytes,    1640840 total
: 42335K->1878K(46080K), 0.0020202 secs] 42335K->1878K(123904K), 0.0020925 secs] [Times: user=0.01 sys=0.00, real=0.00 secs] 
2017-07-22T16:23:54.812+0800: [GC (Allocation Failure) 2017-07-22T16:23:54.812+0800: [ParNew
Desired survivor size 3145728 bytes, new threshold 3 (max 3)
- age   3:    1640536 bytes,    1640536 total
: 41990K->1777K(46080K), 0.0017066 secs] 41990K->1777K(123904K), 0.0017903 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
2017-07-22T16:23:57.821+0800: [GC (Allocation Failure) 2017-07-22T16:23:57.821+0800: [ParNew
Desired survivor size 3145728 bytes, new threshold 3 (max 3)
: 42504K->0K(46080K), 0.0056289 secs] 42504K->1651K(123904K), 0.0057150 secs] [Times: user=0.02 sys=0.00, real=0.01 secs] 
2017-07-22T16:24:00.833+0800: [GC (Allocation Failure) 2017-07-22T16:24:00.833+0800: [ParNew
Desired survivor size 3145728 bytes, new threshold 1 (max 3)
- age   1:    3145776 bytes,    3145776 total
: 40731K->3072K(46080K), 0.0023655 secs] 42382K->4723K(123904K), 0.0024508 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
2017-07-22T16:24:03.843+0800: [GC (Allocation Failure) 2017-07-22T16:24:03.843+0800: [ParNew
Desired survivor size 3145728 bytes, new threshold 3 (max 3)
: 43806K->0K(46080K), 0.0034668 secs] 45457K->4723K(123904K), 0.0035526 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
hello world
Heap
 par new generation   total 46080K, used 15955K [0x00000000f3800000, 0x00000000f6a00000, 0x00000000f6a00000)
  eden space 40960K,  38% used [0x00000000f3800000, 0x00000000f4794e90, 0x00000000f6000000)
  from space 5120K,   0% used [0x00000000f6000000, 0x00000000f6000000, 0x00000000f6500000)
  to   space 5120K,   0% used [0x00000000f6500000, 0x00000000f6500000, 0x00000000f6a00000)
 concurrent mark-sweep generation total 77824K, used 4723K [0x00000000f6a00000, 0x00000000fb600000, 0x0000000100000000)
 Metaspace       used 2840K, capacity 4486K, committed 4864K, reserved 1056768K
  class space    used 305K, capacity 386K, committed 512K, reserved 1048576K

你可能感兴趣的:(JVM Survivor行为一探究竟)