对象进入老年代的四种形式
  • minor gc后，survivor区空间不能包容全副存活对象
  • 存活对象达到年龄阈值。比方15
  • 大对象
  • 动静年龄判断

动静年龄判断

首先，咱们还是先理解一下什么是动静年龄判断？

书本的解释如下：

总结一下：就是说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

局部代码分析：

当初间断调配了3个2M的对象，和1个300K的对象，最初还把array1置为null。此时的堆图应该是这样子的

接下来，还要持续调配一个2M的对象，这个时候eden区还能持续调配空间吗？

必定不能够，因为eden区只有8M。

那这个时候，只好执行young gc来清理空间了。

接着，咱们看一下日志文件：

ParNew: 7115K->619K(9216K)

阐明GG前，占用了7115K，这里大略包含3个2m对象+300k对象+几百K未知对象。通过GC后，只剩下619K对象，包含300K对象和未知对象。

而后给新创建的2m对象调配到eden区

此时，咱们得察看一个重点：就是from区是1m,就是1024K。当初呢，有619K对象曾经来到了from区，是超过from区的一半的。

接着咱们持续看代码：

执行完这个代码。会在堆里会新增2个2m对象，1个300K对象，最初array3置为null。

如果要继续执行byte[] array4 = new byte[2*_1MB];

那么eden区就不够空间了。这个时候会触发第二次young gc了。

咱们持续看一下第二次young gc的日志：

ParNew: 7223K->0K(9216K)

阐明了啥？

GC前，一共应用了7223K，包含eden区的3个2m对象+300K对象和from区的300K对象+未知对象，GC后，整个新生代都有空了。

实践上，GC后，array2还援用着300K对象的。所以，能够必定的是，这300K对象，必定不会被回收。

但当初GC日志显著通知咱们，新生代在GC后的空间使用率为0。

这是为什么呢？

不焦急，咱们持续看一下老年代的空间日志：

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

你看，老年代居然被应用了601K。其实这601K，就是300K对象和未知对象的空间。

为什么它们会在老年代？

就是因为触发了动静年龄判断呀。

你想想，首先，300K不是大对象吧。（-XX:PretenureSizeThreshold=10m）

也没达到15岁，因为才young gc两次。（-XX:MaxTenuringThreshold=15）

而且当初survivor是1024K空间，是足以包容601K的存活对象的。所以，这些都不是导致对象进入老年代的起因。

当初因为2次young gc，那600K对象都存活着，并且占用的空间是超过survivor区的空间大小一半。从而触发动静空间判断，进入老年代。

说到这里，置信大家应该都能明确了。如果还不明确，欢送加大头菜微信一起探讨。