jvm源码阅读笔记[2]：你不知道的晋升阈值TenuringThreshold详解

关注

原创最新推荐文章于 2026-04-13 07:28:02 发布 6.5k 阅读 AI 写同款· GEO 优化 ›

【寄存器模型】二、前门访问与后门访问 1.后门访问可以更好的完成前门访问能够完成的事情：后门访问不消耗仿真时间，且消耗的运行时间也远小于前门访问的运行时间。 2.后门访问可以完成前门访问不能完成的事：对于某些特定的场景，如网络通信系统中的一些只读计数器，当要验证计数器进位归零的场景时，前门访问无法完成写寄存器操作，只能通过消耗仿真时间来使计数器到达特定的计数值。而后门访问可以直接对只读寄存器赋一个初值...... 阅读详情

   从零开始看源码，旨在从源码验证书上的结论，探索书上未知的细节。有疑问欢迎留言探讨
   个人源码地址：https://github.com/FlashLightNing/openjdk-notes
   还有一个openjdk6,7,8,9的地址：https://github.com/dmlloyd/openjdk
   jvm源码阅读笔记[1]：如何触发一次CMS回收
   jvm源码阅读笔记[2]：你不知道的晋升阈值TenuringThreshold详解
   jvm源码阅读笔记[3]：从内存分配到触发GC的细节
   jvm源码阅读笔记[4]：从GC说到vm operation
   jvm源码阅读笔记[5]：内存分配失败触发的GC究竟对内存做了什么？

大家都知道年轻代中经历了多次GC之后仍然没有被回收的对象就会晋升到老年代中。它引入了一个“年龄”的状态：每经历一次GC，对象的年龄就会+1。而到了某一时刻，如果对象的年龄大于设置的一个晋升的阈值，该对象就会晋升到老年代中。对象的年龄最大只能是15，因为jvm中使用4个字节来表示对象的年龄。
那么，问题来了，阈值都是怎么计算的呢？《深入理解Java虚拟机》中告诉我们，有这么一个参数：

-XX:MaxTenuringThreshold=6

表示设置对象最多经过6次GC而没有被回收的话，就会晋升到老年代中。
但是正如这个参数中的max，它只是设置最大的阈值。而在运行的过程中，虚拟机会动态计算晋升的阈值。那么，它又是怎么来计算的呢？来看看下面的代码：
（地址：https://github.com/FlashLightNing/openjdk-notes/blob/master/src/share/vm/gc_implementation/shared/ageTable.cpp）

uint ageTable::compute_tenuring_threshold(size_t survivor_capacity) {
  //TargetSurvivorRatio默认50，意思是：在回收之后希望survivor区的占用率达到这个比例
  size_t desired_survivor_size = (size_t)((((double) survivor_capacity)*TargetSurvivorRatio)/100);
  size_t total = 0;
  uint age = 1;
  assert(sizes[0] == 0, "no objects with age zero should be recorded");
  while (age < table_size) {//table_size=16
    total += sizes[age];
    //如果加上这个年龄的所有对象的大小之后，占用量>期望的大小，就设置age为新的晋升阈值
    if (total > desired_survivor_size) break;
    age++;
  }

  uint result = age < MaxTenuringThreshold ? age : MaxTenuringThreshold;

//可以看到加了PrintTenuringDistribution参数，会打印age分布图
  if (PrintTenuringDistribution || UsePerfData) {

    //打印期望的survivor的大小以及新计算出来的阈值，和设置的最大阈值
    if (PrintTenuringDistribution) {
      gclog_or_tty->cr();
      gclog_or_tty->print_cr("Desired survivor size " SIZE_FORMAT " bytes, new threshold %u (max %u)",
        desired_survivor_size*oopSize, result, (int) MaxTenuringThreshold);
    }

    total = 0;
    age = 1;
    while (age < table_size) {
      total += sizes[age];
      if (sizes[age] > 0) {
        if (PrintTenuringDistribution) {//打印各个年龄所占的空间
          gclog_or_tty->print_cr("- age %3u: " SIZE_FORMAT_W(10) " bytes, " SIZE_FORMAT_W(10) " total",
                                        age,    sizes[age]*oopSize,          total*oopSize);
        }
      }
      if (UsePerfData) {
        _perf_sizes[age]->set_value(sizes[age]*oopSize);
      }
      age++;
    }
    if (UsePerfData) {
      SharedHeap* sh = SharedHeap::heap();
      CollectorPolicy* policy = sh->collector_policy();
      GCPolicyCounters* gc_counters = policy->counters();
      gc_counters->tenuring_threshold()->set_value(result);
      gc_counters->desired_survivor_size()->set_value(
        desired_survivor_size*oopSize);
    }
  }

  return result;//最终返回计算的阈值
}

   所以呢，代码是不会欺骗你的。从所有年龄=0的对象占的空间开始累加，如果加上年龄=n的所有对象的空间之后，大于survivor区的大小*TargetSurvivorRatio/100(TargetSurvivorRatio默认值为50)，若大于这个大小，则结束循环，将n和MaxTenuringThreshold比较，若n小，则阈值为n。若n大，则只能去设置的最大阈值MaxTenuringThreshold。

   好，接下来让我们测试一下
   参数及代码：

参考：http://www.jianshu.com/p/f91fde4628a5
-verbose:gc -Xmx200M -Xmn50M -XX:TargetSurvivorRatio=60  -XX:+PrintTenuringDistribution -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:MaxTenuringThreshold=6

   打印的GC日志截图：



   可以看到，阈值一开始是6，后面变成了2，然后又变成了6，最后又变成了4。
   让我们来计算一下是不是这样呢？
   年轻代是50m，然后eden和survivor区的比例默认是8：1：1.所以计算出来的survivor区的size=50*1024*1024*0.1=5242880byte。
   图中打印的Desired survivor size=3145728byte.
   计算出来的：5242880byte*TargetSurvivorRatio/100=5242880*60/100=3145728!
   正好相等，没有一点点偏差！！
   接下来算一下为什么第2次GC的时候，阈值变成2了呢？
   age=1的大小+age=2的大小=2622024+2115896=4737920>3145728(Desired survivor size)。所以参考上面的代码，阈值=2。
再来看第3次为什么=6了？
   第3次GC时，只有一个age=3的对象，所占大小=2622024<3145728。所以在循环添加时会一直到age最大值15。注意是个while循环和break的条件。

while (age < table_size) {//table_size=16
    total += sizes[age];
    //如果加上这个年龄的所有对象的大小之后，占用量>期望的大小，就设置age为新的晋升阈值
    if (total > desired_survivor_size) break;
    age++;
  }

   然后又根据以下代码：

uint result = age < MaxTenuringThreshold ? age : MaxTenuringThreshold;

   所以阈值变成了6。
   后面的就不一一分析了。
   在这里，总结一下就是：

年轻代晋升到老年代的年龄阈值是由参数TargetSurvivorRatio和参数MaxTenuringThreshold影响的。
MaxTenuringThreshold决定了晋升的最大阈值。
TargetSurvivorRatio影响运行过程中虚拟机计算的晋升阈值。
假设晋升阈值为n，那么一定满足以下条件：所有年龄<=n的对象大小之和 < survivor区的大小*TargetSurvivorRatio%

不知道说到这里，我讲清楚没有…

   但是，这种调整晋升阈值的方式只适用于defNew,parNew年轻代收集器。对于ParallelScavenge收集器，还另有一番天地。
(地址:https://github.com/FlashLightNing/openjdk-notes/blob/master/src/share/vm/gc_implementation/parallelScavenge/psAdaptiveSizePolicy.cpp)
   PSAdaptiveSizePolicy.cpp中有这样一段计算晋升阈值的代码


   以及这么一段加减的代码：


   可以看到，对于ps来说，调整晋升的阈值是通过判断收集器young gc和full gc的耗时的。如果young gc太频繁，虚拟机认为可以降低晋升阈值从而减少年轻代的对象，让更多的对象晋升到老年代，达到减少young gc的时间。
   反之，如果full gc太频繁了，虚拟机就提高晋升的阈值，减少晋升到老年代的对象，从而控制full gc的时间。
_threshold_tolerance_percent=1.0 + ThresholdTolerance/100.0.
ThresholdTolerance默认值为10.也就是说

young_gc_time>full_gc_time*1.1,则threshold降低。
full_gc_time>young_gc_time*1.1,则threshold提高。

   但是需要注意的坑是：如果你的应用在没有用PS之前只是young gc频繁，而基本没有full gc的话，在用了PS之后，因为young gc频繁(比如1秒钟或者几秒钟一次)而导致该阈值会不断减少，最终减到1.这会导致什么问题呢？所有年龄>1的对象都会晋升到老年代，引起没必要的full gc。也许只有等到full gc很频繁之后，才会提高晋升的阈值。
   参考这篇文章：http://blog.youkuaiyun.com/lirenzuo/article/details/77529025

   有没有办法解决呢？有。关闭UseAdaptiveSizePolicy即可。

-XX:-UseAdaptiveSizePolicy

顺便要说的是，如果用的ps，那么因为没有用ageTable里面的那种计算方法，就算加了PrintTenuringDistribution也就不会打印对象age分布图。而在用CMS的时候，加上该参数，因为年轻代用的parNew收集器，阈值计算用的是ageTable的算法，所以会打印age分布图。还有一点是，在cms下，UseAdaptiveSizePolicy参数是默认关闭的。而在PS下是打开的。

   从零开始看源码，旨在从源码验证书上的结论，探索书上未知的细节。有疑问欢迎留言探讨
   个人源码地址：https://github.com/FlashLightNing/openjdk-notes
   还有一个openjdk6,7,8,9的地址：https://github.com/dmlloyd/openjdk
   jvm源码阅读笔记[1]：如何触发一次CMS回收
   jvm源码阅读笔记[2]：你不知道的晋升阈值TenuringThreshold详解
   jvm源码阅读笔记[3]：从内存分配到触发GC的细节
   jvm源码阅读笔记[4]：从GC说到vm operation
   jvm源码阅读笔记[5]：内存分配失败触发的GC究竟对内存做了什么？