我遇到了一个令人困惑的GC案例:虽然Eden空间已100%充满,但使用了0%的幸存者空间。当伊甸园已满时,应该触发垃圾收集,对吗?
是否可以防止GC守护程序运行?像100%的CPU?
我们正在使用jdk-1.7
。
可能是什么原因?以下是jmap输出。
我们还尝试使用jmap -histo -F
捕获更详细的内存使用情况,但随后CPU使用率降至0%,并且Java进程变得无法访问。
using thread-local object allocation.
Parallel GC with 18 thread(s)
Heap Configuration:
MinHeapFreeRatio = 40
MaxHeapFreeRatio = 70
MaxHeapSize = 12884901888 (12288.0MB)
NewSize = 1310720 (1.25MB)
MaxNewSize = 17592186044415 MB
OldSize = 5439488 (5.1875MB)
NewRatio = 2
SurvivorRatio = 8
PermSize = 21757952 (20.75MB)
MaxPermSize = 85983232 (82.0MB)
G1HeapRegionSize = 0 (0.0MB)
Heap Usage:
PS Young Generation
Eden Space:
capacity = 4265738240 (4068.125MB)
used = 4265738240 (4068.125MB)
free = 0 (0.0MB)
100.0% used
From Space:
capacity = 14352384 (13.6875MB)
used = 0 (0.0MB)
free = 14352384 (13.6875MB)
0.0% used
To Space:
capacity = 14680064 (14.0MB)
used = 0 (0.0MB)
free = 14680064 (14.0MB)
0.0% used
PS Old Generation
capacity = 8589934592 (8192.0MB)
used = 8589931920 (8191.997451782227MB)
free = 2672 (0.0025482177734375MB)
99.99996889382601% used
PS Perm Generation
capacity = 41353216 (39.4375MB)
used = 41079056 (39.17604064941406MB)
free = 274160 (0.2614593505859375MB)
99.33702858805468% used
最佳答案
当我看到您的堆配置时,我发现MaxNewSize = 17592186044415 MB
不正确,但是必须以字节为单位。
我看到几乎所有的世代都充满了相同的时间,并且Collector
试图收集这两个世代,以便他们互相阻塞。
我建议使用以下参数调整内存。
-XX:NewRatio=3 - the young generation will occupy 1/4 the overall heap
-XX:NewSize - Calculated automatically if you specify -XX:NewRatio
-XX:MaxNewSize - The largest size the young generation can grow to (unlimited if this value is not specified at command line)
我还建议使用一些幸存者空间,当将对象从
eden
复制到“终身”生成时,它将提供时间收集器。-XX:SurvivorRatio=6 - each survivor space will be 1/8 the young generation
如果幸存者空间太小,则复制集合将直接溢出到终身代。
有关任何澄清,请引用this链接。
编辑:
-XX:NewRatio=3
-年轻的一代将占据整个堆的1/4计算:
y/t=1/3
y+t=h
y+3y=h
y=h/4
t=tenured
y=young
h=heap