大头菜

2021-04-19 14:42 阿里巴巴_Java开发工程师

关注

JVM-对象什么时候进入老年代（实战篇）

哈喽哈喽大家猴，我是把代码写成bug的大头菜。公众号：大头菜技术(bigheadit)。原创不易，但欢迎转载。

上一篇文章：JVM-动态年龄判断介绍了对象进入老年代的四种方式

大对象
动态年龄判断
minor gc后，survivor区空间不能容纳全部存活对象
存活对象达到年龄阈值。比如15

接下来，我们将用代码方式来验证这四种方式。

知识回顾

在实战开始之前，我们先复习一下知识点：

0.134: [GC (Allocation Failure) 0.134: [ParNew: 7444K->685K(9216K), 0.0011650 secs] 
7444K->685K(19456K), 0.0012583 secs] [Times: user=0.00 sys=0.00, real=0.01 secs]

因为涉及到GC日志的查看，我就简单介绍一下日志的大概含义：

0.134。含义就是在程序启动后多久，发生了垃圾回收。单位:秒
GC (Allocation Failure)。GC就是发生了垃圾回收的意思，这个不用说都清楚。然后括号里面的Allocation Failure，就是发生垃圾回收的原因。这里Allocation Failure，就是空间分配失败导致发生的垃圾回收。
[ParNew:ParNew就是新生代垃圾回收使用的垃圾收集器，同时也代表发生了minor gc。
7444K->685K(9216K), 0.0011650 secs]。接着7444K，是新生代垃圾回收前已使用的空间。685K，是新生代垃圾回收后已使用的空间。9216K，是新生代的总空间。0.0011650 secs，就是垃圾回收需要耗费的时间。
7444K->685K(19456K), 0.0012583 secs]，7444K是整个堆（新生代+老年代）垃圾回收前已使用的空间。685K是整个堆垃圾回收后已使用的空间。19456K是整个堆的总空间。
[Times: user=0.00 sys=0.00, real=0.01 secs] 。就是本次GC消耗的时间，因为这里保持了2为小数，四舍五入嘛，因此都是0。

好了，差不多了，直接开始吧！！！！

大对象

首先，我们简单回顾一下。

书本，也没说明，多大的对象才是大对象，比较抽象。

我们这里直接具体点：

-XX:PretenureSizeThreshold=3m

大于等于3m的对象，就是大对象。

-XX:NewSize=10m -XX:MaxNewSize=10m -XX:InitialHeapSize=20m

这里，我们给新生代10m,堆20m。

也就是说，老年代的空间=20m-10m=10m

-XX:SurvivorRatio=8

eden:s0:s1等于8：1：1

所以eden区为8m,s0为1m,s1为1m

使用的垃圾收集器为ParNew和CMS

-XX:+UseParNewGC -XX:+UseConcMarkSweepGC

打印GC的详细信息

-XX:+PrintGCDetails

打印GC的时间戳

-XX:+PrintGCTimeStamps

那这些GC日志输出在哪里，当然是文件啦。

-Xloggc:bigobject.log

好了，JVM的配置差不多了，直接上代码。

JVM配置参数

-XX:NewSize=10m -XX:MaxNewSize=10m -XX:InitialHeapSize=20m -XX:MaxHeapSize=20m -XX:SurvivorRatio=8 -XX:PretenureSizeThreshold=3m -XX:MaxTenuringThreshold=15 -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:bigobject.log

代码：

byte[] array1 = new byte[2_1MB];
byte[] array2 = new byte[3_1MB];

因为2m的对象不是大对象，因此分配到eden区。而3m的对象是大对象，因此分配到old区。

上面，这些都是我们根据理论来推测出来的。

接下来，我们运行一下代码，然后查询日志文件bigobject.log

Java HotSpot(TM) 64-Bit Server VM (25.261-b12) for bsd-amd64 JRE (1.8.0_261-b12), built on Jun 18 2020 06:38:55 by "java_re" with gcc 4.2.1 Compatible Apple LLVM 10.0.0 (clang-1000.11.45.5)
Memory: 4k page, physical 33554432k(382392k free)

/proc/meminfo:

CommandLine flags: -XX:InitialHeapSize=20971520 -XX:MaxHeapSize=20971520 -XX:MaxNewSize=10485760 -XX:MaxTenuringThreshold=15 -XX:NewSize=10485760 -XX:OldPLABSize=16 -XX:PretenureSizeThreshold=3145728 -XX:+PrintGC -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:SurvivorRatio=8 -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC -XX:+UseParNewGC 
Heap
 par new generation   total 9216K, used 4849K [0x00000007bec00000, 0x00000007bf600000, 0x00000007bf600000)
  eden space 8192K,  59% used [0x00000007bec00000, 0x00000007bf0bc580, 0x00000007bf400000)
  from space 1024K,   0% used [0x00000007bf400000, 0x00000007bf400000, 0x00000007bf500000)
  to   space 1024K,   0% used [0x00000007bf500000, 0x00000007bf500000, 0x00000007bf600000)
 concurrent mark-sweep generation total 10240K, used 3072K [0x00000007bf600000, 0x00000007c0000000, 0x00000007c0000000)
 Metaspace       used 3074K, capacity 4496K, committed 4864K, reserved 1056768K
  class space    used 337K, capacity 388K, committed 512K, reserved 1048576K

现在，我们分析一下日志内容，来验证我们的猜测是否正确。

CommandLine flags: -XX:InitialHeapSize=20971520 -XX:MaxHeapSize=20971520 -XX:MaxNewSize=10485760 -XX:MaxTenuringThreshold=15 -XX:NewSize=10485760 -XX:OldPLABSize=16 -XX:PretenureSizeThreshold=3145728 -XX:+PrintGC -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:SurvivorRatio=8 -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC -XX:+UseParNewGC
Heap

上面这一堆，就是我们自己设置的JVM参数，也有一些系统帮我们添加的。比如：-XX:+UseCompressedClassPointers -XX:+UseCompressedOops

这些不是重点，你了解一下就好。

重点是这个：

Heap  
 par new generation   total 9216K, used 4849K [0x00000007bec00000, 0x00000007bf600000, 0x00000007bf600000)
  eden space 8192K,  59% used [0x00000007bec00000, 0x00000007bf0bc580, 0x00000007bf400000)
  from space 1024K,   0% used [0x00000007bf400000, 0x00000007bf400000, 0x00000007bf500000)
  to   space 1024K,   0% used [0x00000007bf500000, 0x00000007bf500000, 0x00000007bf600000)
 concurrent mark-sweep generation total 10240K, used 3072K [0x00000007bf600000, 0x00000007c0000000, 0x00000007c0000000)

代表的含义是：GC后堆的情况，注意是GC后。这里特别强调一下。

par new generation total 9216K, used 4849K
代表的新生代，现在总的空间大小是9216K，已使用的空间大小是4849K。

其实我们知道，有2M对象是进入了eden区的，但是现在4849K明显是大于2048K（2M）的。

那说明了什么？

说明，其实JVM除了加载我们自己写的对象外，还会加载一些其他未知对象。未知对象，主要由JVM本身产生，这部分大家先忽略就好

回到主要问题上：大对象是否会直接进入老年代。

我们看以下这段日志：

concurrent mark-sweep generation total 10240K, used 3072K

老年代的总空间大小是10240K，目前已经使用了3072K。

看到这里，其实相信大家已经可以明白了。我们把大对象定义为大于等于3m的对象。而日志也告诉我们，目前老年代已经被占用了3072K，即3m。

因此，到这里我们已经用代码验证了：大对象会直接进入老年代。

动态年龄判断

首先，我们还是先了解一下什么是动态年龄判断？

书本的解释如下：

总结一下：就是说survivor区中，如果相同年龄的所有对象大小所占用的空间大于survivor空间的一半，年龄大于或等于该年龄对象的，都可以直接进入老年代。

这是书本的说法。。

但其实这个说法是错误的。

相信看过我另一篇文章JVM-动态年龄判断的小伙伴，是了解正确的说法应该是：在survivor区中，所有年龄的对象的所占空间的累加和大于survivor空间的一半，大于或等于该年龄的对象，都可以进入老年代。

接下来我们直接上代码和JVM配置参数：

JVM配置参数：

-XX:NewSize=10m -XX:MaxNewSize=10m -XX:InitialHeapSize=20m -XX:MaxHeapSize=20m -XX:SurvivorRatio=8 -XX:PretenureSizeThreshold=10m -XX:MaxTenuringThreshold=15 -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:dynamicheck.log

代码：

我们先直接把代码跑起来，然后直接看日志文件：

Java HotSpot(TM) 64-Bit Server VM (25.281-b09) for bsd-amd64 JRE (1.8.0_281-b09), built on Dec  9 2020 12:44:49 by "java_re" with gcc 4.2.1 Compatible Apple LLVM 10.0.0 (clang-1000.11.45.5)
Memory: 4k page, physical 16777216k(106332k free)

/proc/meminfo:

CommandLine flags: -XX:InitialHeapSize=20971520 -XX:MaxHeapSize=20971520 -XX:MaxNewSize=10485760 -XX:MaxTenuringThreshold=15 -XX:NewSize=10485760 -XX:OldPLABSize=16 -XX:PretenureSizeThreshold=10485760 -XX:+PrintGC -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:SurvivorRatio=8 -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC -XX:+UseParNewGC 

0.117: [GC (Allocation Failure) 0.118: [ParNew: 7115K->619K(9216K), 0.0029447 secs] 7115K->619K(19456K), 0.0033789 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
0.122: [GC (Allocation Failure) 0.122: [ParNew: 7223K->0K(9216K), 0.0020215 secs] 7223K->601K(19456K), 0.0020509 secs] [Times: user=0.01 sys=0.00, real=0.00 secs] 
Heap
 par new generation   total 9216K, used 2212K [0x00000007bec00000, 0x00000007bf600000, 0x00000007bf600000)
  eden space 8192K,  27% used [0x00000007bec00000, 0x00000007bee290e0, 0x00000007bf400000)
  from space 1024K,   0% used [0x00000007bf400000, 0x00000007bf400000, 0x00000007bf500000)
  to   space 1024K,   0% used [0x00000007bf500000, 0x00000007bf500000, 0x00000007bf600000)
 concurrent mark-sweep generation total 10240K, used 601K [0x00000007bf600000, 0x00000007c0000000, 0x00000007c0000000)
 Metaspace       used 2713K, capacity 4486K, committed 4864K, reserved 1056768K
  class space    used 291K, capacity 386K, committed 512K, reserved 1048576K

部分代码剖析：