Hotspot动态年龄计算

最新推荐文章于 2022-09-03 12:05:54 发布
最新推荐文章于 2022-09-03 12:05:54 发布
阅读量270 收藏
点赞数
分类专栏： 博文 容器化 JVM 文章标签： jvm java 算法
版权声明：本文为博主原创文章，遵循 CC 4.0 BY 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/rothchil/article/details/126606112
版权
博文 同时被 3 个专栏收录
34 篇文章 1 订阅
订阅专栏
容器化
20 篇文章 3 订阅
订阅专栏
JVM
5 篇文章 0 订阅
订阅专栏

title: Hotspot动态年龄计算

date: 2022-01-29 15:00:00

categories: Java

description: JVM 调优

1. 目录

Java-big

2. 题外话

年底事情不是特别多，就和以前论坛好友聊了聊，又说到了 JVM 的垃圾回收机制，其中 Hotspot 对对象年龄的判断以前我没怎么太深入去挖掘，正好趁着这几天得个空，弥补下。

3. 背景

Hotspot 的垃圾回收机制主要针对堆和方法区中，由于 堆 中的非常频繁创建对象，所以这是 GC 工作频繁的区域，而 方法区 相对来比较稳定，不需要分代机制，所以直接 GC 。在 堆 中的频繁创建对象和回收对象占用空间，就会根据对象的年龄进行判断， Hotspot 除了根据配置的年龄进行垃圾回收之外，还有一套动态年龄计算的机制，保证 Hotspot 高效稳定的运作。 说到动态年龄计算规则，那先看下对象默认年龄的计算规则 假设对象首先在 Eden 区域分配，在一次新生代垃圾回收后，如果该对象还存活，则会进入 Survivor ，并且对象的年龄会在 0 基础上加 1 ，该对象在 Survivor 每经历一次垃圾回收，那么它的年龄都会叠加，当年龄叠加到一定阈值（默认 15 ），该对象就被从 Young Generation 晋升到 Tenured Generation 中。

年龄的阈值可被修改，参数为 -XX:MaxTenuringThreshold （可以通过 -XX:+PrintTenuringDistribution 来打印出当次 GC 后的 Threshold）。

4. 概述

说到 Hotspot 动态年龄计算，先了解 内存申请流程 以及 动态年龄的计算规则，方便以下展开描述过程中有更好的理解。

5. 基本概念

5.1. 动态规则

Hotspot 遍历所有对象时，按照年龄从小到大对其所占用的大小进行累积，当累积的某个年龄大小超过了 Survivor 区的 50% 时，当然这个 50% 是可配置的，取这个年龄和 MaxTenuringThreshold 中更小的一个值，作为新的晋升年龄阈值。

5.1.1. 内存申请流程

内存申请流程

上图为 Hotspot 的内存申请流程，包括 存栈判断、对象大小判断、年龄判断等。我们可以看出内存分配过程中先判断是否 存栈空间：

  • 在 栈 中垃圾回收更方便，栈帧结束，栈中的对象也随之消亡，所以这里不做过多描述。
  • 如果不在 栈 中分配，会首先判断该对象的大小，超过 Survivor 大小的对象也直接会被放入 tenured generation ；否则会对象会被分配进入 Eden。 本章节也着重讨论这一种场景。
5.1.2. 小结

下面针对对象在堆中的分配的两种情况，即 大对象 分配以及 普通对象 分别做阐述。

5.2. 大对象定义

这里说的大对象主要指的是 在经历过 Young GC 后，因为 Survivor 并不能放下该对象，从而直接使该对象的内存分配在 tenured generation 。

有两种情况，对象会直接分配到老年代

  • 如果在新生代分配失败且对象是一个不含任何对象引用的大数组，可被直接分配到老年代。通过在老年代的分配避免新生代的一次垃圾回收。
  • PretenureSizeThreshold 可分配到新生代对象的大小限制，任何比这个大的对象都不会尝试在新生代分配，将在老年代分配内存。 PretenureSizeThreshold 默认值是 0，意味着任何对象都会现在新生代分配内存。

6. 基本概念

6.1. 手工设置大对象

6.1.1. 场景假定
  • MaxTenuringThreshold 假定为 10
  • Xmn= 20M
  • XX:SurvivorRatio = 8， Eden 和 Survivor 比例 为 8
    • Eden = 16M
    • s0、s1 = 2M
  • PretenureSizeThreshold=4m 大对象设置为 4m
6.1.2. JVM参数

详细 JVM 配置参数如下


-verbose:gc
-Xmx40m
-Xms40m
-Xmn20m
-XX:+UseParNewGC
-XX:+UseConcMarkSweepGC
-XX:PretenureSizeThreshold=4m
-XX:SurvivorRatio=8
-XX:MaxTenuringThreshold=10
-XX:+PrintTenuringDistribution
-XX:+PrintGC
-XX:+PrintGCDetails
-XX:+PrintGCTimeStamps
-XX:+PrintGCDateStamps
-XX:+PrintHeapAtGC
-Xloggc:gc.log

20220209100731

通过 JVM 配置，可以看到我们 tenured generation 大小为 40m - 20m = 20m

6.1.3. 代码示例

public class JvmGcBigObj {
    public static void main(String[] args) {
        byte[] bytes1 = new byte[4 * 1024 * 1024];
        bytes1 = new byte[4 * 1024 * 1024];
        bytes1 = new byte[4 * 1024 * 1024];
        byte[] bytes2 = new byte[128 * 1024];
        bytes2 = null;

        byte[] bytes3 = new byte[4 * 1024 * 1024];
    }
}
6.1.4. GC日志

Java HotSpot(TM) 64-Bit Server VM (25.301-b09) for windows-amd64 JRE (1.8.0_301-b09), built on Jun  9 2021 06:46:21 by "java_re" with MS VC++ 15.9 (VS2017)
Memory: 4k page, physical 33456676k(23420196k free), swap 54428196k(41646824k free)
CommandLine flags: -XX:InitialHeapSize=41943040 -XX:MaxHeapSize=41943040 -XX:MaxNewSize=20971520 -XX:MaxTenuringThreshold=10 -XX:NewSize=20971520 -XX:OldPLABSize=16 -XX:PretenureSizeThreshold=4194304 -XX:+PrintGC -XX:+PrintGCDateStamps -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC -XX:+PrintTenuringDistribution -XX:SurvivorRatio=8 -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC -XX:-UseLargePagesIndividualAllocation -XX:+UseParNewGC 
Heap
 par new generation   total 18432K, used 3964K [0x00000000fd800000, 0x00000000fec00000, 0x00000000fec00000)
  eden space 16384K,  24% used [0x00000000fd800000, 0x00000000fdbdf380, 0x00000000fe800000)
  from space 2048K,   0% used [0x00000000fe800000, 0x00000000fe800000, 0x00000000fea00000)
  to   space 2048K,   0% used [0x00000000fea00000, 0x00000000fea00000, 0x00000000fec00000)
 concurrent mark-sweep generation total 20480K, used 16384K [0x00000000fec00000, 0x0000000100000000, 0x0000000100000000)
 Metaspace       used 3348K, capacity 4496K, committed 4864K, reserved 1056768K
  class space    used 364K, capacity 388K, committed 512K, reserved 1048576K
6.1.5. GC分析

查看垃圾回收GC日志，发现并没有 Young GC ，通过 concurrent mark-sweep generation total 20480K, used 16384K ，我们可以看出来 一共 20M 的空间，直接被分配了 16M ，说明 bytes1 和 bytes3 的内存申请都被放入 tenured generation 中，从而验证了结论。

6.2. 对象超过Survivor设定的大小

6.2.1. 场景假定
  • MaxTenuringThreshold 假定为 10
  • Xmn= 20M
  • XX:SurvivorRatio = 8， Eden 和 Survivor 比例 为 8
    • Eden = 16M
    • s0、s1 = 2M
6.2.2. JVM参数

详细 JVM 配置参数如下


-verbose:gc
-Xmx40m
-Xms40m
-Xmn20m
-XX:+UseParNewGC
-XX:+UseConcMarkSweepGC
-XX:SurvivorRatio=8
-XX:MaxTenuringThreshold=10
-XX:+PrintTenuringDistribution
-XX:+PrintGC
-XX:+PrintGCDetails
-XX:+PrintGCTimeStamps
-XX:+PrintGCDateStamps
-XX:+PrintHeapAtGC
-Xloggc:gc-obj.log
6.2.3. JAVA示例

继续复用上述的 Demo 每个数组对象的大小为 4M。


public class JvmObj {
    public static void main(String[] args) {
        byte[] bytes1 = new byte[4 * 1024 * 1024];
        bytes1 = new byte[4 * 1024 * 1024];
        bytes1 = new byte[4 * 1024 * 1024];
        byte[] bytes2 = new byte[128 * 1024];
        bytes2 = null;
        byte[] bytes3 = new byte[4 * 1024 * 1024];
        bytes3 = new byte[4 * 1024 * 1024];
        bytes3 = new byte[4 * 1024 * 1024];
        bytes3 = new byte[128 * 1024];
        bytes3 = null;

        byte[] bytes4 = new byte[4 * 1024 * 1024];
    }
}
6.2.4. GC日志

上述 JAVA 示例代码以及 JVM 参数配合起来运行，其会输出如下的 GC 日志。

Java HotSpot(TM) 64-Bit Server VM (25.301-b09) for windows-amd64 JRE (1.8.0_301-b09), built on Jun  9 2021 06:46:21 by "java_re" with MS VC++ 15.9 (VS2017)
Memory: 4k page, physical 33456676k(21280476k free), swap 54428196k(38983140k free)
CommandLine flags: -XX:InitialHeapSize=41943040 -XX:MaxHeapSize=41943040 -XX:MaxNewSize=20971520 -XX:MaxTenuringThreshold=10 -XX:NewSize=20971520 -XX:OldPLABSize=16 -XX:+PrintGC -XX:+PrintGCDateStamps -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC -XX:+PrintTenuringDistribution -XX:SurvivorRatio=8 -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC -XX:-UseLargePagesIndividualAllocation -XX:+UseParNewGC 
{Heap before GC invocations=0 (full 0):
 par new generation   total 18432K, used 15924K [0x00000000fd800000, 0x00000000fec00000, 0x00000000fec00000)
  eden space 16384K,  97% used [0x00000000fd800000, 0x00000000fe78d380, 0x00000000fe800000)
  from space 2048K,   0% used [0x00000000fe800000, 0x00000000fe800000, 0x00000000fea00000)
  to   space 2048K,   0% used [0x00000000fea00000, 0x00000000fea00000, 0x00000000fec00000)
 concurrent mark-sweep generation total 20480K, used 0K [0x00000000fec00000, 0x0000000100000000, 0x0000000100000000)
 Metaspace       used 3340K, capacity 4496K, committed 4864K, reserved 1056768K
  class space    used 363K, capacity 388K, committed 512K, reserved 1048576K
2022-02-09T15:17:15.398+0800: 0.310: [GC (Allocation Failure) 2022-02-09T15:17:15.398+0800: 0.310: [ParNew
Desired survivor size 1048576 bytes, new threshold 1 (max 10)
- age   1:    1208816 bytes,    1208816 total
: 15924K->1348K(18432K), 0.0098407 secs] 15924K->5446K(38912K), 0.0100888 secs] [Times: user=0.00 sys=0.00, real=0.01 secs] 
Heap after GC invocations=1 (full 0):
 par new generation   total 18432K, used 1348K [0x00000000fd800000, 0x00000000fec00000, 0x00000000fec00000)
  eden space 16384K,   0% used [0x00000000fd800000, 0x00000000fd800000, 0x00000000fe800000)
  from space 2048K,  65% used [0x00000000fea00000, 0x00000000feb51020, 0x00000000fec00000)
  to   space 2048K,   0% used [0x00000000fe800000, 0x00000000fe800000, 0x00000000fea00000)
 concurrent mark-sweep generation total 20480K, used 4098K [0x00000000fec00000, 0x0000000100000000, 0x0000000100000000)
 Metaspace       used 3340K, capacity 4496K, committed 4864K, reserved 1056768K
  class space    used 363K, capacity 388K, committed 512K, reserved 1048576K
}
{Heap before GC invocations=1 (full 0):
 par new generation   total 18432K, used 13956K [0x00000000fd800000, 0x00000000fec00000, 0x00000000fec00000)
  eden space 16384K,  76% used [0x00000000fd800000, 0x00000000fe450278, 0x00000000fe800000)
  from space 2048K,  65% used [0x00000000fea00000, 0x00000000feb51020, 0x00000000fec00000)
  to   space 2048K,   0% used [0x00000000fe800000, 0x00000000fe800000, 0x00000000fea00000)
 concurrent mark-sweep generation total 20480K, used 4098K [0x00000000fec00000, 0x0000000100000000, 0x0000000100000000)
 Metaspace       used 3342K, capacity 4496K, committed 4864K, reserved 1056768K
  class space    used 363K, capacity 388K, committed 512K, reserved 1048576K
2022-02-09T15:17:15.410+0800: 0.322: [GC (Allocation Failure) 2022-02-09T15:17:15.410+0800: 0.322: [ParNew
Desired survivor size 1048576 bytes, new threshold 10 (max 10)
: 13956K->0K(18432K), 0.0243044 secs] 18054K->5167K(38912K), 0.0244080 secs] [Times: user=0.66 sys=0.00, real=0.02 secs] 
Heap after GC invocations=2 (full 0):
 par new generation   total 18432K, used 0K [0x00000000fd800000, 0x00000000fec00000, 0x00000000fec00000)
  eden space 16384K,   0% used [0x00000000fd800000, 0x00000000fd800000, 0x00000000fe800000)
  from space 2048K,   0% used [0x00000000fe800000, 0x00000000fe800000, 0x00000000fea00000)
  to   space 2048K,   0% used [0x00000000fea00000, 0x00000000fea00000, 0x00000000fec00000)
 concurrent mark-sweep generation total 20480K, used 5167K [0x00000000fec00000, 0x0000000100000000, 0x0000000100000000)
 Metaspace       used 3342K, capacity 4496K, committed 4864K, reserved 1056768K
  class space    used 363K, capacity 388K, committed 512K, reserved 1048576K
}
Heap
 par new generation   total 18432K, used 4424K [0x00000000fd800000, 0x00000000fec00000, 0x00000000fec00000)
  eden space 16384K,  27% used [0x00000000fd800000, 0x00000000fdc52040, 0x00000000fe800000)
  from space 2048K,   0% used [0x00000000fe800000, 0x00000000fe800000, 0x00000000fea00000)
  to   space 2048K,   0% used [0x00000000fea00000, 0x00000000fea00000, 0x00000000fec00000)
 concurrent mark-sweep generation total 20480K, used 5167K [0x00000000fec00000, 0x0000000100000000, 0x0000000100000000)
 Metaspace       used 3349K, capacity 4496K, committed 4864K, reserved 1056768K
  class space    used 364K, capacity 388K, committed 512K, reserved 1048576K
6.2.5. GC分析
  • main 方法开始连续创建 3 个 4MB 的数组，最后还把局部变量 bytes1 设置为了 null 。

byte[] bytes1 = new byte[4 * 1024 * 1024];
bytes1 = new byte[4 * 1024 * 1024];
bytes1 = new byte[4 * 1024 * 1024];
byte[] bytes2 = new byte[128 * 1024];
bytes2 = null;

所以此时的内存如下图所示：

20220209142617

  • 紧接着创建 bytes2 此时会在 Eden 创建 128kb 的数组对象

20220209142714


byte[] bytes2 = new byte[128 * 1024];
bytes2 = null;
  • 再创建 bytes3 的数组对象，当希望在 Eden 区再次分配一个 bytes3 的数组， Eden 空间已经不允许，没有足够的空间容量来存储 bytes3 对象， YOUNG GC 就在此刻被触发。

byte[] bytes3 = new byte[4 * 1024 * 1024];



2022-02-09T15:17:15.398+0800: 0.310: [GC (Allocation Failure) 2022-02-09T15:17:15.398+0800: 0.310: [ParNew
Desired survivor size 1048576 bytes, new threshold 1 (max 10)
- age   1:    1208816 bytes,    1208816 total
: 15924K->1348K(18432K), 0.0098407 secs] 15924K->5446K(38912K), 0.0100888 secs] [Times: user=0.00 sys=0.00, real=0.01 secs]

此时发生的第一次 Young GC : 15924K->1348K(18432K), 0.0098407 secs 通过 GC 日志分析，在 GC 之前年轻代占用空间 15924K ，包括 3 个 4M 的数组 、 1 个 128k 的数组 ，还包含一些未知对象 3508k ，在垃圾回收后还存活的 未知对象大概是 1348K 。

20220211102508

在第一次 Young GC 将剩下 4MB 的数据和一些 未知对象 ， 并不能全放入 from Survivor 区。因为 Survivor 区仅仅只有 2MB ，所以将 4MB 放入老年代， 未知对象 存入 Survivor 。


Heap after GC invocations=1 (full 0):
 par new generation   total 18432K, used 1348K [0x00000000fd800000, 0x00000000fec00000, 0x00000000fec00000)
  eden space 16384K,   0% used [0x00000000fd800000, 0x00000000fd800000, 0x00000000fe800000)
  from space 2048K,  65% used [0x00000000fea00000, 0x00000000feb51020, 0x00000000fec00000)
  to   space 2048K,   0% used [0x00000000fe800000, 0x00000000fe800000, 0x00000000fea00000)
 concurrent mark-sweep generation total 20480K, used 4098K [0x00000000fec00000, 0x0000000100000000, 0x0000000100000000)
 Metaspace       used 3340K, capacity 4496K, committed 4864K, reserved 1056768K
  class space    used 363K, capacity 388K, committed 512K, reserved 1048576K

20220211102602

  • 紧接着再分配 3个 4MB 的数组，然后再分配一个 128KB 的数组，最后是让 bytes3 变量指向 null，此时 Eden 已经有 3*1024+128 k 的对象，再分配 bytes4 ，已经无法容下，触发第二次 Young GC 。

20220211102838


        byte[] bytes3 = new byte[4 * 1024 * 1024];
        bytes3 = new byte[4 * 1024 * 1024];
        bytes3 = new byte[4 * 1024 * 1024];
        bytes3 = new byte[128 * 1024];
        bytes3 = null;
        byte[] bytes4 = new byte[4 * 1024 * 1024];



{Heap before GC invocations=1 (full 0):
 par new generation   total 18432K, used 13956K [0x00000000fd800000, 0x00000000fec00000, 0x00000000fec00000)
  eden space 16384K,  76% used [0x00000000fd800000, 0x00000000fe450278, 0x00000000fe800000)
  from space 2048K,  65% used [0x00000000fea00000, 0x00000000feb51020, 0x00000000fec00000)
  to   space 2048K,   0% used [0x00000000fe800000, 0x00000000fe800000, 0x00000000fea00000)
 concurrent mark-sweep generation total 20480K, used 4098K [0x00000000fec00000, 0x0000000100000000, 0x0000000100000000)
 Metaspace       used 3342K, capacity 4496K, committed 4864K, reserved 1056768K
  class space    used 363K, capacity 388K, committed 512K, reserved 1048576K
2022-02-09T15:17:15.410+0800: 0.322: [GC (Allocation Failure) 2022-02-09T15:17:15.410+0800: 0.322: [ParNew
Desired survivor size 1048576 bytes, new threshold 10 (max 10)
: 13956K->0K(18432K), 0.0243044 secs] 18054K->5167K(38912K), 0.0244080 secs] [Times: user=0.66 sys=0.00, real=0.02 secs] 
Heap after GC invocations=2 (full 0):
 par new generation   total 18432K, used 0K [0x00000000fd800000, 0x00000000fec00000, 0x00000000fec00000)
  eden space 16384K,   0% used [0x00000000fd800000, 0x00000000fd800000, 0x00000000fe800000)
  from space 2048K,   0% used [0x00000000fe800000, 0x00000000fe800000, 0x00000000fea00000)
  to   space 2048K,   0% used [0x00000000fea00000, 0x00000000fea00000, 0x00000000fec00000)
 concurrent mark-sweep generation total 20480K, used 5167K [0x00000000fec00000, 0x0000000100000000, 0x0000000100000000)
 Metaspace       used 3342K, capacity 4496K, committed 4864K, reserved 1056768K
  class space    used 363K, capacity 388K, committed 512K, reserved 1048576K
}

在第二次 Young GC 后， Eden 和 Survivor 的空间变为 0k ； 老年代的空间也由第一次GC 的 4098K -> 5167K ，老年代的对象包含 1个4M 的对象 和 一些 未知对象 ，其中未知对象约，这些未知对象从 Survivor 转移到 老年代 空间又被处理（ HOTSPOT 具体对这些对象如何的有清楚的小伙伴麻烦告知下）。

20220211105401

  • 最终在第二次 Young GC 后， Eden 已经有空间对 bytes4 进行分配，效果图如下：

20220211105630

同时我们观察 GC日志也可以看到 Eden 空间占比已经是 27%，说明虚拟机确实按照这样的逻辑进行垃圾回收的。


Heap
 par new generation   total 18432K, used 4424K [0x00000000fd800000, 0x00000000fec00000, 0x00000000fec00000)
  eden space 16384K,  27% used [0x00000000fd800000, 0x00000000fdc52040, 0x00000000fe800000)
  from space 2048K,   0% used [0x00000000fe800000, 0x00000000fe800000, 0x00000000fea00000)
  to   space 2048K,   0% used [0x00000000fea00000, 0x00000000fea00000, 0x00000000fec00000)
 concurrent mark-sweep generation total 20480K, used 5167K [0x00000000fec00000, 0x0000000100000000, 0x0000000100000000)
 Metaspace       used 3349K, capacity 4496K, committed 4864K, reserved 1056768K
  class space    used 364K, capacity 388K, committed 512K, reserved 1048576K

7. 普通对象

7.1. 场景假定

  • MaxTenuringThreshold 假定为 3
  • Xmn= 18M
  • XX:SurvivorRatio = 1， Eden 和 Survivor 比例 为 1
    • Eden = 6144k
    • s0、s1 = 6144k

7.2. JVM参数


-verbose:gc
-Xmx38m
-Xms38m
-Xmn18m
-XX:+UseParNewGC
-XX:+UseConcMarkSweepGC
-XX:SurvivorRatio=1
-XX:MaxTenuringThreshold=3
-XX:+PrintGCDetails
-XX:+PrintGCDateStamps
-XX:+PrintTenuringDistribution
-XX:+PrintHeapAtGC
-XX:+PrintReferenceGC
-XX:+PrintGCApplicationStoppedTime
-XX:+PrintSafepointStatistics
-XX:PrintSafepointStatisticsCount=1
-Xloggc:gc-com.log

7.3. 代码示例


public class JvmSurviObj {

    public static void main(String[] args) {
        byte[] bytes1 = new byte[3 * 1024 * 1024];
        byte[] bytes2 = new byte[128 * 1024];
        bytes1 = null;
        byte[] bytes3 = new byte[3 * 1024 * 1024];
    }
}

7.4. GC日志


Java HotSpot(TM) 64-Bit Server VM (25.301-b09) for windows-amd64 JRE (1.8.0_301-b09), built on Jun  9 2021 06:46:21 by "java_re" with MS VC++ 15.9 (VS2017)
Memory: 4k page, physical 15965876k(4472588k free), swap 19504820k(6958176k free)
CommandLine flags: -XX:InitialHeapSize=39845888 -XX:InitialTenuringThreshold=3 -XX:MaxHeapSize=39845888 -XX:MaxNewSize=18874368 -XX:MaxTenuringThreshold=3 -XX:NewSize=18874368 -XX:OldPLABSize=16 -XX:+PrintGC -XX:+PrintGCApplicationStoppedTime -XX:+PrintGCDateStamps -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC -XX:+PrintReferenceGC -XX:+PrintSafepointStatistics -XX:PrintSafepointStatisticsCount=1 -XX:+PrintTenuringDistribution -XX:SurvivorRatio=1 -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC -XX:-UseLargePagesIndividualAllocation -XX:+UseParNewGC 
{Heap before GC invocations=0 (full 0):
 par new generation   total 12288K, used 4380K [0x00000000fda00000, 0x00000000fec00000, 0x00000000fec00000)
  eden space 6144K,  71% used [0x00000000fda00000, 0x00000000fde47180, 0x00000000fe000000)
  from space 6144K,   0% used [0x00000000fe000000, 0x00000000fe000000, 0x00000000fe600000)
  to   space 6144K,   0% used [0x00000000fe600000, 0x00000000fe600000, 0x00000000fec00000)
 concurrent mark-sweep generation total 20480K, used 0K [0x00000000fec00000, 0x0000000100000000, 0x0000000100000000)
 Metaspace       used 2635K, capacity 4486K, committed 4864K, reserved 1056768K
  class space    used 278K, capacity 386K, committed 512K, reserved 1048576K
2022-02-11T23:06:57.976+0800: 0.115: [GC (Allocation Failure) 2022-02-11T23:06:57.976+0800: 0.115: [ParNew2022-02-11T23:06:57.976+0800: 0.117: [SoftReference, 0 refs, 0.0000409 secs]2022-02-11T23:06:57.976+0800: 0.117: [WeakReference, 9 refs, 0.0000084 secs]2022-02-11T23:06:57.976+0800: 0.117: [FinalReference, 4 refs, 0.0000167 secs]2022-02-11T23:06:57.976+0800: 0.117: [PhantomReference, 0 refs, 0 refs, 0.0000076 secs]2022-02-11T23:06:57.976+0800: 0.117: [JNI Weak Reference, 0.0000066 secs]
Desired survivor size 3145728 bytes, new threshold 3 (max 3)
- age   1:     904344 bytes,     904344 total
: 4380K->934K(12288K), 0.0020749 secs] 4380K->934K(32768K), 0.0023095 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
Heap after GC invocations=1 (full 0):
 par new generation   total 12288K, used 934K [0x00000000fda00000, 0x00000000fec00000, 0x00000000fec00000)
  eden space 6144K,   0% used [0x00000000fda00000, 0x00000000fda00000, 0x00000000fe000000)
  from space 6144K,  15% used [0x00000000fe600000, 0x00000000fe6e9b28, 0x00000000fec00000)
  to   space 6144K,   0% used [0x00000000fe000000, 0x00000000fe000000, 0x00000000fe600000)
 concurrent mark-sweep generation total 20480K, used 0K [0x00000000fec00000, 0x0000000100000000, 0x0000000100000000)
 Metaspace       used 2635K, capacity 4486K, committed 4864K, reserved 1056768K
  class space    used 278K, capacity 386K, committed 512K, reserved 1048576K
}
2022-02-11T23:06:57.976+0800: 0.117: Total time for which application threads were stopped: 0.0025014 seconds, Stopping threads took: 0.0000335 seconds
Heap
 par new generation   total 12288K, used 4068K [0x00000000fda00000, 0x00000000fec00000, 0x00000000fec00000)
  eden space 6144K,  51% used [0x00000000fda00000, 0x00000000fdd0f748, 0x00000000fe000000)
  from space 6144K,  15% used [0x00000000fe600000, 0x00000000fe6e9b28, 0x00000000fec00000)
  to   space 6144K,   0% used [0x00000000fe000000, 0x00000000fe000000, 0x00000000fe600000)
 concurrent mark-sweep generation total 20480K, used 0K [0x00000000fec00000, 0x0000000100000000, 0x0000000100000000)
 Metaspace       used 2642K, capacity 4486K, committed 4864K, reserved 1056768K
  class space    used 279K, capacity 386K, committed 512K, reserved 1048576K

7.5. GC分析


        byte[] bytes1 = new byte[3 * 1024 * 1024];
        byte[] bytes2 = new byte[128 * 1024];
        bytes1 = null;



2022-02-11T23:06:57.976+0800: 0.115: [GC (Allocation Failure) 2022-02-11T23:06:57.976+0800: 0.115: [ParNew2022-02-11T23:06:57.976+0800: 0.117: [SoftReference, 0 refs, 0.0000409 secs]2022-02-11T23:06:57.976+0800: 0.117: [WeakReference, 9 refs, 0.0000084 secs]2022-02-11T23:06:57.976+0800: 0.117: [FinalReference, 4 refs, 0.0000167 secs]2022-02-11T23:06:57.976+0800: 0.117: [PhantomReference, 0 refs, 0 refs, 0.0000076 secs]2022-02-11T23:06:57.976+0800: 0.117: [JNI Weak Reference, 0.0000066 secs]
Desired survivor size 3145728 bytes, new threshold 3 (max 3)
- age   1:     904344 bytes,     904344 total
: 4380K->934K(12288K), 0.0020749 secs] 4380K->934K(32768K), 0.0023095 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]

4380K->934K(12288K), 0.0020749 secs 中的 4380K 包含 1个3M bytes1 和 128k bytes2 ，以及将近 1180k 的未知对象。

  • 通过在第一次 Young GC 后， From Survivor 占 15% 的新生代内存， 15% * 6144k = 921kb ， 921k 包含 数组 128k 以及一些 未知对象 ；eden 和 老年代 使用都 0% 。

20220212102548

  • 紧接着开始在 Eden 分配 bytes3 ，此时新生代空间为 3m 数组 加上 From Survivor 的 921k ，最终空间分配如下：

20220212103009


Heap
 par new generation   total 12288K, used 4068K [0x00000000fda00000, 0x00000000fec00000, 0x00000000fec00000)
  eden space 6144K,  51% used [0x00000000fda00000, 0x00000000fdd0f748, 0x00000000fe000000)
  from space 6144K,  15% used [0x00000000fe600000, 0x00000000fe6e9b28, 0x00000000fec00000)
  to   space 6144K,   0% used [0x00000000fe000000, 0x00000000fe000000, 0x00000000fe600000)
 concurrent mark-sweep generation total 20480K, used 0K [0x00000000fec00000, 0x0000000100000000, 0x0000000100000000)
 Metaspace       used 2642K, capacity 4486K, committed 4864K, reserved 1056768K
  class space    used 279K, capacity 386K, committed 512K, reserved 1048576K

8. 动态年龄

8.1. 场景假定

  • MaxTenuringThreshold 假定为 3
  • Xmn= 18M
  • XX:SurvivorRatio = 1， Eden 和 Survivor 比例 为 1
    • Eden = 6144k
    • s0、s1 = 6144k

8.2. JVM参数


-verbose:gc
-Xmx38m
-Xms38m
-Xmn18m
-XX:+UseParNewGC
-XX:+UseConcMarkSweepGC
-XX:SurvivorRatio=1
-XX:MaxTenuringThreshold=3
-XX:+PrintGCDetails
-XX:+PrintGCDateStamps
-XX:+PrintTenuringDistribution
-XX:+PrintHeapAtGC
-XX:+PrintReferenceGC
-XX:+PrintGCApplicationStoppedTime
-XX:+PrintSafepointStatistics
-XX:PrintSafepointStatisticsCount=1
-Xloggc:gc-com.log

8.3. 代码示例


public class JvmSurviObj {

    public static void main(String[] args) {
        byte[] bytes1 = new byte[3 * 1024 * 1024];
        byte[] bytes2 = new byte[128 * 1024];
        bytes1 = null;
        byte[] bytes3 = new byte[3 * 1024 * 1024];
    }
}

8.4. GC日志

8.5. GC分析

20220209171053

From Survivor 内对象的年龄已经是 1，而此时 Survivor 区域总大小是 2MB，此时 Survivor 区域中的存活对象已经有 1331k ，绝对超过 50%。触发第二次 Young GC，然后看看 Survivor 区域内的动态年龄判定规则能否生效。

  • 最后执行 byte[] bytes4 = new byte[4 * 1024 * 1024] ， Eden 区如果要再次放一个 4MB 数组下去，是放不下去的了，所以会再触发一次 Young GC 。

2022-01-27T16:47:32.378+0800: 0.302: [GC (Allocation Failure) 2022-01-27T16:47:32.378+0800: 0.302: [ParNew
Desired survivor size 1048576 bytes, new threshold 10 (max 10)
: 14139K->0K(18432K), 0.0237425 secs] 14139K->1199K(38912K), 0.0238285 secs] [Times: user=0.05 sys=0.02, real=0.02 secs]
  • 最终 GC 日志如下，此刻 14139K->0K(18432K), 0.0237425 secs 说明年轻代已经没有对象存在，但是此前年轻代还有未知对象。

20220127170535

Eden 在第二次 GC 后，由于都没引用，所以都被回收走了，只剩下 Survivor 区域中的对象，而且总大小超过 50%了，而且年龄都是1岁。

根据 Hotspot 对动态年龄判定规则： 年龄1 + 年龄2 + 年龄n 的对象总大小超过了 Survivor 区域的 50%，年龄n 以上的对象进入老年代。

20220127171207


concurrent mark-sweep generation total 20480K, used 1199K [0x00000000fec00000, 0x0000000100000000, 0x0000000100000000)
  • CMS 管理的老年代，此时使用空间刚是 1199K ，此时 Survivor 里的对象触发动态年龄判定规则，虽然没有达到10岁，但是全部进入老年代了，包括:
    • bytes2 变量一直引用的 128KB 数组
    • bytes4 变量引用的那个 4MB 数组，此时就会分配到 Eden 区域中

最终内存分布如图：

20220127172316

8.6. TargetSurvivorRatio 分析


uint ageTable::compute_tenuring_threshold(size_t survivor_capacity) {
	//survivor_capacity是survivor空间的大小
  size_t desired_survivor_size = (size_t)((((double) survivor_capacity)*TargetSurvivorRatio)/100);
  size_t total = 0;
  uint age = 1;
  while (age < table_size) {
    total += sizes[age];//sizes数组是每个年龄段对象大小
    if (total > desired_survivor_size) break;
    age++;
  }
  uint result = age < MaxTenuringThreshold ? age : MaxTenuringThreshold;
	...
}

TargetSurvivorRatio 这个数值默认为 50% 通过它可以完成以下四项：

  • 计算一个期望值，desired_survivor_size 。
  • 然后用一个 total 计数器，累加每个年龄段对象大小的总和。
  • 当 total 大于 desired_survivor_size 停止。
  • 然后用当前叠加的年龄和 设定 MaxTenuringThreshold 对比找出最小值作为结果

综述，动态年龄计算规则就是将年龄按照从小到大进行容量累加，当加入某个年龄段后，累加超过 Survivor 区域 TargetSurvivorRatio，就从这个年龄段向上的年龄的对象进行晋升。

https://blog.csdn.net/weixin_42405670/article/details/120426799

王老邪
关注
专栏目录
HotSpot 垃圾收集器
黎明就要到来
06-05 52
HotSpot 虚拟机提供了多种垃圾收集器，每种收集器都有各自的特点，虽然我们要对各个收集器进行比较，但并非为了挑选出一个最好的收集器。我们选择的只是对具体应用最合适的收集器。
JVM 性能调优——HotSpot VM 参数指南
一叶知秋的博客
02-01 1358
基于 JDK 1.8 版本 HotSpot VM 参数指南。JVM参数共分为三类， - 标准参数（-），所有的JVM实现都必须实现这些参数的功能，而且向后兼容；非标准参数（-X），默认jvm实现这些参数的功能，但是并不保证所有jvm实现都满足，且不保证向后兼容；非 Stable 参数（-XX），此类参数各个 JVM 实现会有所不同，需要慎重使用。
查询GC日志、动态年龄计算
10-25 583
https://www.cnblogs.com/onmyway20xx/p/6590603.html 从实际案例聊聊Java应用的GC优化 动态年龄计算 关于上文中提到晋升年龄阈值为2，很多同学有疑问，为什么设置了MaxTenuringThreshold=15，对象仍然仅经历2次Minor GC，就晋升到老年代？这里涉及到“动态年龄计算”的概念。 动态年龄计算：Hotspot...
Java Hotspot G1 GC的理解总结
热门推荐
张彦峰的博客
05-12 165万+
G1垃圾回收原理和回收过程分析，并给出适用场景和应用建议 参考文献、书籍及链接 1.https://tech.meituan.com/2016/09/23/g1.html 2.书
GC问题排查实战五-G1日志分析以及动态年龄调整机制
王伟王胖胖的博客
03-19 1461
GC问题排查实战五-G1日志分析以及动态年龄调整机制G1分析参数跑完后数据gc日志数据safepoint相关数据动态年龄调整机制(ParNew做例子)hotspot相关源码jdk1.8-b26哪些收集器会用到这个机制这个机制在哪个阶段被使用年龄阈值在哪个阶段被使用总结 G1分析 这次我们用G1试试。 参数 -Xms8192M -Xmx8192M -Xmn4096M -Xss1M -XX:+UseG1GC -XX:+PrintTenuringDistribution -XX:+PrintHeapAtGC -
HotSpot 对象的创建
Sherlock的博客
09-22 1651
HotSpot中对象是是通过对象模型来表示的，具体来说就是oop和klass来表示，oop代表了一个Java对象在堆内存中的表现形式。使用klass来表示Java类的信息。虚拟机创建Java对象时，会在按照klass所提供的类信息，在内存中创建一个oop对象，具体的内存可能是线程TLAB会堆空间。然后该oop对象的地址会赋给一个变量，这个变量可能在线程栈上或直接来自堆空间对此oop的引用。 一.对象模型 hotspot/src/share/vm/oops/oop.hpp HotSpot内部oop的描述如下，
HotSpot synchronized原理
Sherlock的博客
09-30 584
Java通过对synchronize关键字来支持多线程同步。在字节码层面synchronize表现为monitorenter, monitorexit， 同时外加一个flags标志区分synchronize的同步作用域。synchronized用的锁是存在Java对象头里的，虚拟机的对象头主要包括两部分数据：Mark Word(标记字段)和Klass Pointer(类元数据指针)，其中Klass Point是是对象指向它的类元数据的指针，虚拟机通过这个指针来确定这个对象是哪个类的实例，Mark Wor
HotSpot Serial收集器
Sherlock的博客
09-23 332
GC在HotSpot中的地位举足轻重。JDK9为止提供了四种收集器：Serial，CMS，Parallel，G1。按机器规模，分代类型，吞吐量，延时，CPU利用率等，结合不同的算法，每种收集器都有各自适用的使用场景，同时衍生出多种GC组合配置。今天来看Serial收集器。 Serial收集器属于分代GC收集器。 年轻代主要算法为标记复制算法，老年代主要算法为标记压缩算法。 Serial和SerialOld都是单线程GC。特点是需要STW。 适用于响应时间要求不高的桌面应用或开发调试环境。 一. Seri
JVM 技术内幕——HotSpot VM
一叶知秋的博客
06-03 6007
JDK (包含 Java语言、工具及工具API、Java SE API、JVM) 是用于支持 Java 程序开发的最小环境，JRE (包含 Java SE API、JVM) 是支持 Java 程序运行的标准环境。JDK 默认内置 JVM 是 HotSpot VM。我们平时所提及的高性能 JVM 除了 HotSpot VM，还包括 BEA JRockit VM 和 IBM J9 VM 这类在通用平台上运行的商用虚拟机。
JVM(Hotspot)
qq_43369592的博客
10-21 2049
JVM(Hotspot) 一.介绍 JVM是Java Virtual Machine（Java虚拟机）的缩写，JVM是一种用于计算设备的规范，它是一个虚构出来的计算机，是通过在实际的计算机上仿真模拟各种计算机功能来实现的。 引入Java语言虚拟机后，Java语言在不同平台上运行时不需要重新编译。Java语言使用Java虚拟机屏蔽了与具体平台相关的信息，使得Java语言编译程序只需生成在Java虚拟机上运行的目标代码（字节码），就可以在多种平台上不加修改地运行。 ##二.JVM结构图 2.1程序计数器（
Hotspot 偏向锁BiasedLocking 源码解析
菜鸟进阶之路
03-23 2802
目录 1、定义 2、init 3、init方法补充说明 4、revoke_bias 5、bulk_revoke_or_rebias_at_safepoint 6、revoke_and_rebias 7、VM_RevokeBias /VM_BulkRevokeBias 8、revoke_at_safepoint /revoke 9、preserve_marks /r...
HotSpot虚拟机中的7种垃圾回收器
qq_33898680的博客
01-13 470
垃圾收集器概述 垃圾收集器组合 图中展示了7种垃圾收集器，Serial、ParNew、Parallel Scavenge、CMS、Serial old、Parallel Old、G1 带有连线的收集器代表可以组合使用 Serial Old作为CMS出现"Concurrent Mode Failure"失败的后备预案 并发垃圾收集和并行垃圾收集的区别 并行指多条垃圾收集线程并行执行，但是用户...
Java并发系列（14）——synchronized之HotSpot源码解读（上）
JinchaoLv的博客
12-11 478
上一篇：《Java并发系列（13）——线程池的选择与参数设置》 文章目录10 synchronized 实现原理10.1 研究思路10.1.1 输出 JVM 指令10.1.2 跟踪 JVM 源码10.2 预备知识10.2.1 对象头10.2.1.1 什么是对象头10.2.1.2 打印对象头10.2.1.3 小端存储10.2.2 用户态与内核态10.2.2.1 用户态与内核态10.2.2.2 用户线程与内核线程10.3 Hashtable 性能测试10.3.1 测试一10.3.2
Anaconda安装使用以及Pycharm教程
孤山之王
09-03 7944
Anaconda环境基本使用以及与Pycharm集成
Nginx禁止通过IP访问，允许域名访问
孤山之王
07-14 6449
Nginx开启域名访问模式，屏蔽通过IP访问
CentOS环境下安装Nacos
孤山之王
08-30 6241
Centos安装Nacos完成入门的学习和开发任务
Java生成SSL证书
孤山之王
08-27 5514
JAVA生成SSL证书，可以在HTTPS中使用
JavaWeb-Mybatis动态刷新XML
孤山之王
12-30 2716
利用多线程实现Mybatis动态刷新XML，做到不重启服务完成XML中的SQL注入
Docker-03：Docker管理工具Portainer
孤山之王
08-12 2292
PortaiDocker的轻量化的管理工具，跨平台和开源管理UI
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

王老邪

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值