logo头像
ICQL

jvm_实践

模拟GC

jdk8,使用 ParNew + CMS 的垃圾收集器组合

1
2
3
4
5
6
#jdk环境:
java -version

openjdk version "1.8.0_292"
OpenJDK Runtime Environment (AdoptOpenJDK)(build 1.8.0_292-b10)
OpenJDK 64-Bit Server VM (AdoptOpenJDK)(build 25.292-b10, mixed mode)

1)模拟young gc

测试代码:

1
2
3
4
5
6
7
8
9
10
11
12
13
//vm参数:
//-Xms20m -Xmx20m -Xmn10m -Xss1m -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:/Users/icql/gc.log
public class Test {
public static void main(String[] args) {
//断点1
byte[] object1 = new byte[2 * 1024 * 1024];
object1 = new byte[2 * 1024 * 1024];
object1 = null;
//断点2
byte[] object2 = new byte[4 * 1024 * 1024];
//断点3
}
}

gc日志:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
OpenJDK 64-Bit Server VM (25.292-b10) for bsd-amd64 JRE (1.8.0_292-b10), built on Apr 20 2021 21:55:04 by "jenkins" with gcc 4.2.1 Compatible Apple LLVM 10.0.1 (clang-1001.0.46.4)
Memory: 4k page, physical 16777216k(263204k free)

/proc/meminfo:

CommandLine flags: -XX:InitialHeapSize=20971520 -XX:MaxHeapSize=20971520 -XX:MaxNewSize=10485760 -XX:MaxTenuringThreshold=6 -XX:NewSize=10485760 -XX:OldPLABSize=16 -XX:+PrintGC -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:ThreadStackSize=1024 -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC -XX:+UseParNewGC

0.171: [GC (Allocation Failure) 0.171: [ParNew: 6693K->610K(9216K), 0.0018878 secs] 6693K->610K(19456K), 0.0020834 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]

Heap
par new generation total 9216K, used 4870K [0x00000007bec00000, 0x00000007bf600000, 0x00000007bf600000)
eden space 8192K, 52% used [0x00000007bec00000, 0x00000007bf0290f0, 0x00000007bf400000)
from space 1024K, 59% used [0x00000007bf500000, 0x00000007bf598a58, 0x00000007bf600000)
to space 1024K, 0% used [0x00000007bf400000, 0x00000007bf400000, 0x00000007bf500000)
concurrent mark-sweep generation total 10240K, used 0K [0x00000007bf600000, 0x00000007c0000000, 0x00000007c0000000)
Metaspace used 3130K, capacity 4496K, committed 4864K, reserved 1056768K
class space used 334K, capacity 388K, committed 512K, reserved 1048576K

步骤:

启动程序(debug)
程序执行到 断点1
终端执行 jps -l 查看程序 pid 为 62927
终端执行 jstat -gc 62927 1000 100 查看内存变化

分析:

断点1,程序刚启动,其他对象在 Eden 区占用 3M 左右(jstat 中 EU 显示 3150.4K)
断点2,new 了 2 个大小均约为 2M 的数组对象,Eden区总占用 3+2+2=7M(jstat 中 EU 显示 3150.4 + 4259.9 = 7410.3K)
继续执行,需要 new 1 个 4M 的数组对象,但是此时 Eden区+S0区=8+1=9M,已占用7M,显然放不下 4M数组,所以触发 young gc
查看 gc 日志可看到,Allocation Failure 所以触发 ParNew young gc,回收2个 2M 的垃圾数组对象和其他对象
断点3,young gc 回收完,Eden区就可以成功分配 4M 数组

0.171: [GC (Allocation Failure) 0.171: [ParNew: 7410K->677K(9216K), 0.0018878 secs] 7410K->677K(19456K), 0.0020834 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]

jvm_实践
jvm_实践

2)模拟对象进入老年代

对象进入老年代的常见 4 种情况:

超过young gc次数限制(gc年龄,-XX:MaxTenuringThreshold,默认15,也是最大值)
动态年龄判定,S区内 (年龄1+年龄2+…+年龄n) 对象总和大于S区50%,年龄n以后的对象 young gc 进入老年代
young gc后存活对象太多大于S区容量,直接进入老年代(优先放入S区,放不下的才进入老年代)
大对象直接进入老年代(-XX:PretenureSizeThreshold=0,默认0B代表不受限制,大于Eden区容量时)

第3种情况分析:(第4种比较简单,第1、2种情况示例不太好调)

1
2
3
4
5
6
7
8
9
10
11
12
//vm参数:
//-Xms100m -Xmx100m -Xmn50m -Xss1m -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+PrintGCDetails -XX:+PrintGCTimeStamps
public class Test {
public static void main(String[] args) {
//断点1
byte[] object1 = new byte[4 * 1024 * 1024];
byte[] object2 = new byte[2 * 1024 * 1024];
//断点2
byte[] object3 = new byte[30 * 1024 * 1024];
//断点3
}
}

(1) 断点1,程序刚启动,其他对象在 Eden 区占用 4M 左右(jstat 中 EU 显示 4096.4K)
(2) 断点2,new 了 2 个数组对象,Eden区总占用约 4+4+2=10M(jstat 中 EU 显示 11059.7K=10.8M)
(3) 继续执行,需要new一个30M的数组对象,显然 eden 区放不下了,需要进行 young gc
(4) young gc时,object1 和 object2 都是存活的,但是加起来 4+2=6M,大于 S1区的5M容量,此时是优先放入S1区,剩下的才进入老年代Old区,所以通过jstat可以很清晰的看到,4M Object1放入了S1区,而 2M Object2 则是直接进入了老年代Old区

jvm_实践
jvm_实践

3)模拟old gc

CMS 的 gc 分为 2 种:

  1. background collector(并发的CMS gc,old gc)

后台线程定时扫描(-XX:CMSWaitDuration 默认为 2s)判断是否满足以下条件,需要触发 old 区的 CMS gc(普通的CMS标记清除算法)

(1)根据统计数据判断是否需要触发 CMS gc

若未配置-XX:+UseCMSInitiatingOccupancyOnly,第一次 old gc 触发的条件是 old 区占用超 50%,后续是动态的

若配置了-XX:+UseCMSInitiatingOccupancyOnly,根据 -XX:CMSInitiatingOccupancyFraction 的值进行判断,默认是-1,根据内部公式计算得到阈值为 92%

(2)默认 -XX+CMSClassUnloadingEnabled 开启,会对 metaspace 进行垃圾回收,所以 metaspace 扩容时也会触发 CMS gc

(3)之前young gc失败过,预测到下次还有可能失败时,会触发 CMS gc

2.  foreground collector(单线程串行的CMS gc,full gc)

具体见模拟 full gc

根据上述理论,CMS old gc 触发的情况较多,模拟最常见的第 (1) 种用来分析:

-XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=35 -XX:-CMSClassUnloadingEnabled

这 3 个参数用来排除其他情况触发CMS old gc,且设置老年代对象占比大于 35% 时触发 CMS old gc

1
2
3
4
5
6
7
8
9
10
11
12
//vm参数:
//-Xms100m -Xmx100m -Xmn20m -Xss1m -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=35 -XX:-CMSClassUnloadingEnabled -XX:+PrintGCDetails -XX:+PrintGCTimeStamps
public class Test {
public static void main(String[] args) {
//断点1
byte[] object1 = new byte[20 * 1024 * 1024];
object1 = null;
//断点2
byte[] object2 = new byte[40 * 1024 * 1024];
//断点3
}
}

gc日志:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
30.097: [GC (CMS Initial Mark) [1 CMS-initial-mark: 61440K(81920K)] 64767K(100352K), 0.0028489 secs] [Times: user=0.01 sys=0.00, real=0.01 secs] 
30.100: [CMS-concurrent-mark-start]
30.100: [CMS-concurrent-mark: 0.000/0.000 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
30.100: [CMS-concurrent-preclean-start]
30.100: [CMS-concurrent-preclean: 0.000/0.000 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
30.100: [CMS-concurrent-abortable-preclean-start]
Heap
par new generation total 18432K, used 3655K [0x00000007b9c00000, 0x00000007bb000000, 0x00000007bb000000)
eden space 16384K, 22% used [0x00000007b9c00000, 0x00000007b9f91f18, 0x00000007bac00000)
from space 2048K, 0% used [0x00000007bac00000, 0x00000007bac00000, 0x00000007bae00000)
to space 2048K, 0% used [0x00000007bae00000, 0x00000007bae00000, 0x00000007bb000000)
concurrent mark-sweep generation total 81920K, used 61440K [0x00000007bb000000, 0x00000007c0000000, 0x00000007c0000000)
Metaspace used 3100K, capacity 4556K, committed 4864K, reserved 1056768K
class space used 326K, capacity 392K, committed 512K, reserved 1048576K

(1) 断点1,程序刚启动,其他对象在 Eden 区占用 3M 左右(jstat 中 EU 显示 3327.7K)
(2) 断点2,new 了 1 个数组对象 20M,显然Eden区放不下直接进入老年代(jstat 中 OU 显示 20480.0K=20M),但此时未达到cms回收阈值 20/80=25% < 35%
(3) 断点3,继续 new 了 1 个数组对象 40M,依然直接进入老年代(jstat 中 OU 显示 61440.0K=60M),注意老年代空间充足,是先进入再 cms gc,如果放不下就是 background collector 的第4种情况
(4) 查看gc日志,可以清晰的看到cms的gc过程,60/80=75% > 35%

注意:jstat 结果中的 FGC 和 FGCT 对于CMS来说比较特殊,统计的是STW的次数和时间,CMS有2个阶段是STW的,所以一次完整CMS gc周期会在这里显示 2 次

jvm_实践
jvm_实践

4)模拟full gc

CMS 的 gc 分为 2 种:

  1. background collector(并发的CMS gc,old gc)

具体见上面的模拟old gc

2.  foreground collector(单线程串行的CMS gc,full gc)

两种算法:

(1)MSC算法(标记-清理-压缩),和 Serail Old收集器类似,单线程对整个堆进行垃圾回收,也就是真正意义上的 Full GC,STW要长于普通 CMS

(2)类似普通CMS算法

使用哪种算法取决于这2个参数,-XX:+UseCMSCompactAtFullCollection,-XX:CMSFullGCsBeforeCompaction=0,默认是每次full gc都进行压缩整理内存,即使用MSC算法,

-XX:CMSFullGCsBeforeCompaction=n,则代表n次full gc后进行压缩整理内存

触发的原因:

(1)晋升失败(Promotion Failed)

young gc后,存活对象从 S区 晋升到 Old区时,Old区放不下,一般是由于内存碎片放不下大对象 或 cms后台线程来不及回收导致放不下

(2)并发模式失败(Concurrent Mode Failure)

后台线程并发 Background CMS gc 正在执行(并发阶段),同时又有 Young GC 晋升的对象 Old 区放不下

(3)收集担保失败

统计之前young gc 晋升 Old 区的平均对象大小 和 young gc当前所有对象大小,只要old区目前剩余大小大于前两种之一,认为担保安全进行young gc,否则不安全直接进行full gc

(4)显式 GC

System.gc()调用,可以使用参数 -XX:+DisableExplicitGC 禁用,如果禁用,使用了DirectByteBuffer不显示调用System.gc(),有可能导致metespace OOM

不太好模拟,后续有再补。

微信打赏

赞赏是不耍流氓的鼓励