Java8Metaspace: OutOfMemoryError:处理反射膨胀

Question

网络上有很多链接和开放的问与答，但我仍然错过了很多信息。

第一件事

问题：

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

框架：

春天，冬眠，干草，码头

嫌疑人1：

在使用期间，metaspace逐渐增长，以下反射类按比例加载到jmap -histo cron作业观察到的metaspace中。

sun.reflect.GeneratedConstructorAccessor1299
sun.reflect.GeneratedMethodAccessor6929
sun.reflect.GeneratedSerializationConstructorAccessor4220

可能的解决办法：

当我们使用大量处理反射信息的库时，我们认为128 m不足以容纳元空间中的所有generatedXX类。因此，我们计划将metaspace限制增加一倍。-XX:MaxMetaspaceSize=256m

我们是，而不是，我们在考虑设置以下内容

-D sun.reflect.noInflation -D sun.reflect.inflationThreshold

嫌疑人2：

完整的GC甚至在到达/占用完整配置的元空间(128 M)之前就一直在运行，并且应用程序变得没有响应/慢/有时OOM，因为jvm只做FGC。

全GC (元数据GC阈值) [PSYoungGen: 224K->0K(698368K)] [ParOldGen: 52910K->52933K(1398272K)] 53134K->52933K(2096640K)，[Metaspace: 92733K->92733K(1163264K)]，0.1964143秒

。

Metaspace使用147414K，容量155731K，承诺159616K，预留1187840K 类空间使用17242 K，容量19252 K，承诺20352 K，预留1048576K

可能的解决办法：

在vm启动时没有显式地提到-XX:CompressedClassSpaceSize，这可能会导致过度保留地址空间，从而导致误导性提交的space，从而导致完整的GC。因此，显式设置-XX:CompressedClassSpaceSize=256m将有助于vm正确地规划和保留内存。

问题：

1. 嫌疑人1:是否有人面临类似的问题，并得到了任何解决办法？
2. 嫌疑人2:设置-XX:CompressedClassSpaceSize真的会改变元规划/预留并影响GC吗？有什么指示吗？
3. 还有其他嫌疑人吗？建议？

Answer 1

在花了这么多时间之后，我们发现没有班级泄漏，我们是

"反射通货膨胀"

package sun.reflect;

/**
 The master factory for all reflective objects, both those in
 java.lang.reflect (Fields, Methods, Constructors) as well as their
 delegates (FieldAccessors, MethodAccessors, ConstructorAccessors).
**/

public class ReflectionFactory {


    // "Inflation" mechanism. Loading bytecodes to implement Method.invoke() and Constructor.newInstance() currently costs
    // 3-4x more than an invocation via native code for the first invocation (though subsequent invocations have been benchmarked
    // to be over 20x faster). Unfortunately this cost increases startup time for certain applications that use reflection
    // intensively (but only once per class) to bootstrap themselves. To avoid this penalty we reuse the existing JVM entry points
    // for the first few invocations of Methods and Constructors and then switch to the bytecode-based implementations.

我亲自验证了这一点，在每16次反射产生时，就会使用这种技术来提高响应时间。

最后，我们增加了元空间，一切看起来都很好。