java为什么会有这么小的PermGen提交增量？

Question

我分析了一个java功能测试，它花费了很长时间，偶尔会出现OOM（在C堆中，而不是java中），我发现java串行GC中存在一个真正的次优行为（它可能适用于所有java GC）

以下是测试运行中完整GC点的Permgen统计数据示例（大小以KB为单位）：

before  after   commit
167935  167935  167936
172031  172031  172032

正如您所看到的，这些完整的gc运行并没有清理permgen空间。没什么大不了的，但它指出这些完整的gc是无用的。此外，commit值有点滑稽。我假设gc日志项的提交值是增加提交大小后的值。我现在认为它实际上是在完整GC运行之前的提交值

此外，我认为permgen提交大小在每一次完整GC运行中以4MB（172032K-167936K）的固定、不可调大小增长。这意味着，如果您以默认的permgen大小（比如64mb）开始，并且当您的应用程序完全启动时，它需要128mb的permgen，那么permgen需要16个完整gc才能达到其最终提交大小

在我分析的功能测试中，必须运行58个完整的gc，每个都需要0.5到2秒。通过使jvm参数-XX:PermSize等于-XX:MaxPermSize，我能够将其减少到零完整GC（而不会显著增加更快的新一代GC），并将GC检测消息报告的GC时间减少90%，从90秒减少到9秒

我找了很多地方，但找不到permgen堆提交大小增长率的其他调优参数。在程序启动时完全分配permgen堆的最大可能大小有点难看。有没有人知道，除了将PermSize增加到等于MaxPermSize之外，还有什么替代方法可以在启动时不分配太多内存的情况下获得类似的结果？为什么permgen提交增量如此小且固定

Answer 1

Permgen不会被垃圾收集。（在正常情况下）。Permgen是保存java运行时的实际类对象和其他“内脏”的地方。当应用程序初始化和使用各种类和/或加载和/或使用JAR时，这些关联的类文件基本上存储在permgen中

必须有其他与你的应用程序相关的参数来解释你的观察结果

permgen的增加和垃圾收集之间确实没有文档记录的关系。在静态情况下，装载器会收集数据，而在静态情况下，装载器不会使用