2回复
2年前
Spring boot服务启动之后Eden每次都直接占满
1. 问题描述
在测试环境CentOS中,启动Spring boot服务,发现每次Eden区直接占满,然后触发了一次Full GC,不过Survivor区是能容纳剩余对象的(下面的GC日志可以看出)且老年代没有任何变化,所以想请教的问题如下:
- Eden区为什么会直接占满,按照下面的配置Eden区分配是2G(我是从1.6G左右调上来,后来甚至还调到了2.4G,结果都一样),关键是这个测试环境的服务器没有任何流量,项目中也没有加载什么大的对象、数据之类的。感觉光加载类也用不了这么多,怀疑是有什么机制导致的
- 为什么GC日志显示发生了Full GC,下面的GC日志中显示Heap after GC invocations=1 (full 1)且老年代没有发生任何内存占用,是我遗漏什么Full GC触发机制嘛?
2. 环境说明
2.1 JVM启动参数(主要)
总结来说就是: 堆最小最大5G, 新生代2.5G,回收器ParNew + CMS
OpenJDK 64-Bit Server VM (25.302-b08) for linux-amd64 JRE (1.8.0_302-b08), built on Aug 10 2021 16:30:49 by "mockbuild" with gcc 4.8.5 ****0623 (Red Hat 4.8.5-44)
Memory: 4k page, physical 32779460k(272804k free), swap 0k(0k free)
-XX:InitialHeapSize=5368709120
-XX:MaxHeapSize=5368709120
-XX:MaxNewSize=2684354560
-XX:MaxTenuringThreshold=6
-XX:NewSize=2684354560
-XX:+UseParNewGC
-XX:+UseConcMarkSweepGC
-XX:+UseCMSInitiatingOccupancyOnly
-XX:CMSInitiatingOccupancyFraction=80
2.2 第一次GC前后的Heap情况
eden space 2097152K, 100% used [0x0000000680000000, 0x0000000700000000, 0x0000000700000000)
{Heap before GC invocations=0 (full 1):
par new generation total 2359296K, used 2097152K [0x0000000680000000, 0x0000000720000000, 0x0000000720000000)
eden space 2097152K, 100% used [0x0000000680000000, 0x0000000700000000, 0x0000000700000000)
from space 262144K, 0% used [0x0000000700000000, 0x0000000700000000, 0x0000000710000000)
to space 262144K, 0% used [0x0000000710000000, 0x0000000710000000, 0x0000000720000000)
concurrent mark-sweep generation total 2621440K, used 0K [0x0000000720000000, 0x00000007c0000000, 0x00000007c0000000)
Metaspace used 58415K, capacity 61273K, committed 61392K, reserved 1103872K
class space used 7297K, capacity 7817K, committed 7820K, reserved 1048576K
2021-12-21T14:49:16.211+0800: 5.958: [GC (Allocation Failure) 2021-12-21T14:49:16.211+0800: 5.958: [ParNew2021-12-21T14:49:16.311+0800: 6.058: [CMS-concurrent-abortable-preclean: 0.700/3.575 secs] [Times: user=13.75 sy
s=0.67, real=3.58 secs]
Desired survivor size 134217728 bytes, new threshold 6 (max 6)
- age 1: 68331688 bytes, 68331688 total
: 2097152K->66950K(2359296K), 0.2097264 secs] 2097152K->66950K(4980736K), 0.2098128 secs] [Times: user=0.73 sys=0.02, real=0.21 secs]
Heap after GC invocations=1 (full 1):
par new generation total 2359296K, used 66950K [0x0000000680000000, 0x0000000720000000, 0x0000000720000000)
eden space 2097152K, 0% used [0x0000000680000000, 0x0000000680000000, 0x0000000700000000)
from space 262144K, 25% used [0x0000000710000000, 0x0000000714161ad0, 0x0000000720000000)
to space 262144K, 0% used [0x0000000700000000, 0x0000000700000000, 0x0000000710000000)
concurrent mark-sweep generation total 2621440K, used 0K [0x0000000720000000, 0x00000007c0000000, 0x00000007c0000000)
Metaspace used 58415K, capacity 61273K, committed 61392K, reserved 1103872K
class space used 7297K, capacity 7817K, committed 7820K, reserved 1048576K
}
2021-12-21T14:49:16.421+0800: 6.168: Total time for which application threads were stopped: 0.2100413 seconds, Stopping threads took: 0.0000439 seconds
2021-12-21T14:49:16.422+0800: 6.169: [GC (CMS Final Remark) [YG occupancy: 183972 K (2359296 K)]2021-12-21T14:49:16.422+0800: 6.169: [Rescan (parallel) , 0.0519265 secs]2021-12-21T14:49:16.474+0800: 6.221: [weak refs p
rocessing, 0.0000375 secs]2021-12-21T14:49:16.474+0800: 6.221: [class unloading, 0.0081899 secs]2021-12-21T14:49:16.482+0800: 6.230: [scrub symbol table, 0.0116212 secs]2021-12-21T14:49:16.494+0800: 6.241: [scrub strin
g table, 0.0006662 secs][1 CMS-remark: 0K(2621440K)] 183972K(4980736K), 0.0742343 secs] [Times: user=0.41 sys=0.00, real=0.07 secs]
2021-12-21T14:49:16.496+0800: 6.244: Total time for which application threads were stopped: 0.0744672 seconds, Stopping threads took: 0.0001397 seconds
2021-12-21T14:49:16.497+0800: 6.244: [CMS-concurrent-sweep-start]
2021-12-21T14:49:16.497+0800: 6.244: [CMS-concurrent-sweep: 0.000/0.000 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
2021-12-21T14:49:16.497+0800: 6.244: [CMS-concurrent-reset-start]
再次感谢!
764 阅读