收藏:

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了收藏:相关的知识,希望对你有一定的参考价值。


XX:MaxTenuringThreshold
  晋升年龄最大阈值,默认15。在新生代中对象存活次数(经过YGC的次数)后仍然存活,就会晋升到老年代。每经过一次YGC,年龄加1,当survivor区的对象年龄达到TenuringThreshold时,表示该对象是长存活对象,就会直接晋升到老年代。

-XX:TargetSurvivorRatio
  设定survivor区的目标使用率。默认50,即survivor区对象目标使用率为50%。

  JVM会将每个对象的年龄信息、各个年龄段对象的总大小记录在“age table”表中。基于“age table”、survivor区大小、survivor区目标使用率(-XX:TargetSurvivorRatio)、晋升年龄阈值(-XX:MaxTenuringThreshold),JVM会动态的计算tenuring threshold的值。一旦对象年龄达到了tenuring threshold就会晋升到老年代。

  为什么要动态的计算tenuring threshold的值呢?假设有很多年龄还未达到TenuringThreshold的对象依旧停留在survivor区,这样不利于新对象从eden晋升到survivor。因此设置survivor区的目标使用率,当使用率达到时重新调整TenuringThreshold值,让对象尽早的去old区。

  如果希望跟踪每次新生代GC后,survivor区中对象的年龄分布,可在启动参数上增加-XX:+PrintTenuringDistribution。

 

下面详细说下-XX:TargetSurvivorRatio这个参数:

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<ygcTimes*40; i++)
byte[] byte1m = new byte[1 * 1024 * 1024];



代码配套的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

作者:阿飞的博客

简书著作权归作者所有,任何形式的转载都请联系作者获得授权并注明出处。

以上是关于收藏:的主要内容,如果未能解决你的问题,请参考以下文章

工厂模式

一文详解MySQL事务底层原理,全是干货,推荐收藏

命令模式-接收者与执行者解耦和

一个故事看懂机械硬盘原理

一个故事看懂机械硬盘原理

一个故事看懂机械硬盘原理