我有一个可重复的情况,即JVM正在经历大量GC负载。当我使用jmap -heap
请求JVM统计信息时,我得到以下信息(这是来自Linux上的Oracle JDK 1.7.0_25)
请注意,虽然它表示MaxPermSize
为256米,但它也表示PermGen的容量为136MB,但容量为99.9%。
这可以解释GC捶打,但我的问题是为什么JVM不会将PermGen扩展到完全可用的256m?是否有一些参数可以阻止池扩展的发生,并阻止JVM充分利用256m?
请注意,Tenured pool也有点紧张,但远不及permgen。
using thread-local object allocation.
Mark Sweep Compact GC
Heap Configuration:
MinHeapFreeRatio = 5
MaxHeapFreeRatio = 10
MaxHeapSize = 805306368 (768.0MB)
NewSize = 1048576 (1.0MB)
MaxNewSize = 4294901760 (4095.9375MB)
OldSize = 4194304 (4.0MB)
NewRatio = 8
SurvivorRatio = 8
PermSize = 50331648 (48.0MB)
MaxPermSize = 268435456 (256.0MB)
G1HeapRegionSize = 0 (0.0MB)
Heap Usage:
New Generation (Eden + 1 Survivor Space):
capacity = 43909120 (41.875MB)
used = 495240 (0.47229766845703125MB)
free = 43413880 (41.40270233154297MB)
1.1278750291511195% used
Eden Space:
capacity = 39059456 (37.25MB)
used = 495240 (0.47229766845703125MB)
free = 38564216 (36.77770233154297MB)
1.2679132039114933% used
From Space:
capacity = 4849664 (4.625MB)
used = 0 (0.0MB)
free = 4849664 (4.625MB)
0.0% used
To Space:
capacity = 4849664 (4.625MB)
used = 0 (0.0MB)
free = 4849664 (4.625MB)
0.0% used
tenured generation:
capacity = 389492736 (371.44921875MB)
used = 350542912 (334.30377197265625MB)
free = 38949824 (37.14544677734375MB)
89.99985868799361% used
Perm Generation:
capacity = 143392768 (136.75MB)
used = 143338624 (136.6983642578125MB)
free = 54144 (0.0516357421875MB)
99.96224077353747% used
174149 interned Strings occupying 19526656 bytes.
答案 0 :(得分:1)
一个可能的原因是您的计算机没有更多可用内存,因此JVM无法为PermGen分配更多空间(您需要〜+ 30%的可用内存而不是配置的内存)。
其他原因(我更喜欢这个)将是Java人体工程学的奇怪行为。您的JVM可能会确定您的PermGen“最佳大小”为136MB但在某些时候无法增加它。也许是因为你的PermGen引起的内存泄漏。如果使用“并发标记”和“扫描GC”,则可以尝试使用-XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled
。
答案 1 :(得分:0)
总系统RAM是多少?它是32位还是64位jvm? 就主要问题而言(如上所述) - JVM尝试分配PermGen空间(在定义的范围内)但在系统内存不可用时抛出OOM错误。
但我不同意Alexey Ragozin - 如果MaxPermGen Size低于需要,那么JVM将停止并抛出Perm Gen Space错误 - 无论主机或堆的其他部分有多少内存[Eden / Tenured]。< / p>