有很多 链接 和开放的 问答 在网络上,但我仍然缺乏很多信息。
首先要做的事情
问题:
java.lang.OutOfMemoryError: Metaspace
jvm:
java version: "1.8.0_131"
vm: Java HotSpot(TM) 64-Bit Server
vm args: -Xms1024m -Xmx1024m -XX:MaxMetaspaceSize=128m
框架:
Spring, Hibernate, Wicket, Jetty
嫌疑人1:
在使用期间,元空间逐渐增长,并且以下反射类比例地加载到元空间中[由jmap -histo cron jobs观察]
sun.reflect.GeneratedConstructorAccessor1299
sun.reflect.GeneratedMethodAccessor6929
sun.reflect.GeneratedSerializationConstructorAccessor4220
可能的解决方案:
a. 因为我们使用了大量处理反射内容的库,我们认为128m无法容纳metaspace中生成的所有generatedXX类,所以我们计划将metaspace限制加倍。-XX:MaxMetaspaceSize=256m
b. 我们不打算设置以下内容:
-D sun.reflect.noInflation
-D sun.reflect.inflationThreshold
可疑情况2:
即使在达到/占用完全配置的metaspace(128m)之前,Full GC仍在持续运行,并且应用程序变得无响应/缓慢/有时会发生OOM,因为jvm只执行FGC。
[Full GC (Metadata GC Threshold) [PSYoungGen: 224K->0K(698368K)] [ParOldGen: 52910K->52933K(1398272K)] 53134K->52933K(2096640K), [Metaspace: 92733K->92733K(1163264K)], 0.1964143 secs] [Times: user=0.59 sys=0.00, real=0.19 secs]
.
Metaspace使用了147414K,容量为155731K,已分配159616K,保留了1187840K的空间
类空间使用了17242K,容量为19252K,已分配20352K,保留了1048576K的空间
可能的解决方案:
在vm启动时没有明确提到-XX:CompressedClassSpaceSize,这可能导致过度保留地址空间,从而导致误导committed sapce,进而引发Full GC。因此,显式设置-XX:CompressedClassSpaceSize=256m将有助于vm进行正确的内存规划和保留。
问题:
- 疑点1:是否有人遇到过类似的问题并得到任何解决方法?
- 疑点2:设置-XX:CompressedClassSpaceSize是否真的会对metaspace规划/保留和GC产生影响?有什么指针吗?
- 还有其他疑点或建议吗?