gpt4 book ai didi

java - 频繁的主要 gc 但不是空闲堆?

转载 作者:塔克拉玛干 更新时间:2023-11-03 03:16:03 25 4
gpt4 key购买 nike

运行几个小时后,我的 http 服务器开始频繁进行 major gc,但没有释放任何堆。

多次major gc之后,promotion failedconcurrent mode failure发生,然后heap被释放。我的 gc 日志如下:

{Heap before GC invocations=7172 (full 720):
par new generation total 737280K, used 667492K [0x000000076b800000, 0x000000079d800000, 0x000000079d800000)
eden space 655360K, 100% used [0x000000076b800000, 0x0000000793800000, 0x0000000793800000)
from space 81920K, 14% used [0x0000000793800000, 0x00000007943d91d0, 0x0000000798800000)
to space 81920K, 0% used [0x0000000798800000, 0x0000000798800000, 0x000000079d800000)
concurrent mark-sweep generation total 1482752K, used 1479471K [0x000000079d800000, 0x00000007f8000000, 0x00000007f8000000)
concurrent-mark-sweep perm gen total 131072K, used 58091K [0x00000007f8000000, 0x0000000800000000, 0x0000000800000000)
2015-11-19T21:50:02.692+0800: 113963.532: [GC2015-11-19T21:50:02.692+0800: 113963.532: [ParNew (promotion failed)
Desired survivor size 41943040 bytes, new threshold 15 (max 15)
- age 1: 3826144 bytes, 3826144 total
- age 2: 305696 bytes, 4131840 total
- age 3: 181416 bytes, 4313256 total
- age 4: 940632 bytes, 5253888 total
- age 5: 88368 bytes, 5342256 total
- age 6: 159840 bytes, 5502096 total
- age 7: 733856 bytes, 6235952 total
- age 8: 64712 bytes, 6300664 total
- age 9: 314304 bytes, 6614968 total
- age 10: 587160 bytes, 7202128 total
- age 11: 38728 bytes, 7240856 total
- age 12: 221160 bytes, 7462016 total
- age 13: 648376 bytes, 8110392 total
- age 14: 33296 bytes, 8143688 total
- age 15: 380768 bytes, 8524456 total
: 667492K->665908K(737280K), 0.7665810 secs]2015-11-19T21:50:03.459+0800: 113964.299: [CMS2015-11-19T21:50:05.161+0800: 113966.001: [CMS-concurrent-mark: 3.579/4.747 secs] [Times: user=13.41 sys=0.35, rea
l=4.75 secs]
(concurrent mode failure): 1479910K->44010K(1482752K), 4.7267420 secs] 2146964K->44010K(2220032K), [CMS Perm : 58091K->57795K(131072K)], 5.4939440 secs] [Times: user=9.07 sys=0.13, real=5.49 secs]
Heap after GC invocations=7173 (full 721):
par new generation total 737280K, used 0K [0x000000076b800000, 0x000000079d800000, 0x000000079d800000)
eden space 655360K, 0% used [0x000000076b800000, 0x000000076b800000, 0x0000000793800000)
from space 81920K, 0% used [0x0000000798800000, 0x0000000798800000, 0x000000079d800000)
to space 81920K, 0% used [0x0000000793800000, 0x0000000793800000, 0x0000000798800000)
concurrent mark-sweep generation total 1482752K, used 44010K [0x000000079d800000, 0x00000007f8000000, 0x00000007f8000000)
concurrent-mark-sweep perm gen total 131072K, used 57795K [0x00000007f8000000, 0x0000000800000000, 0x0000000800000000)
}

CMS GC 似乎没有任何意义。你能给我解释一下吗?

这是我的 gc 配置:

/usr/local/jdk1.7.0_79/bin/java 
-server
-Xms2248m
-Xmx2248m
-Xmn800m
-XX:PermSize=128m
-XX:MaxPermSize=128m
-XX:MaxTenuringThreshold=15
-XX:+UseCMSCompactAtFullCollection
-XX:CMSFullGCsBeforeCompaction=0
-XX:+UseConcMarkSweepGC
-XX:+PrintGCDetails
-XX:+PrintGCTimeStamps
-XX:+PrintGCDateStamps
-Xloggc:gc.log
-XX:+PrintHeapAtGC
-XX:+PrintTenuringDistribution
-XX:+UseFastAccessorMethods

更新

自服务器启动以来有一个周期性任务。它的工作是从 mysql 加载数据并保存在 jvm 堆中。当客户端请求到来时,服务器应该使用数据进行计算。任务代码如下:

private volatile List<ActivityInfo> activityInfos;

public void run () {
activityInfos = db.loadActivity();
}

public ActivityInfo getActivityByClient() {
//
List<ActivityInfo> local = activityInfos;
// biz code
ActivityInfo response = // biz code
return response;
}

// executor
executor.scheduleWithFixedDelay(task, 0, 1, TimeUnit.MINUTES);

最让我困惑的是为什么堆是在 full gc 之后释放的,而不是在 major gc 之后?

更新

full gc log is here

最佳答案

这表明您的运行速度非常接近最大堆大小,因此 GC 频繁但释放的很少。尝试显着增加它,比如 1.5 倍或 2 倍。

关于java - 频繁的主要 gc 但不是空闲堆?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/33806952/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com