与此类似的问题：java.lang.OutOfMemoryError：压缩类空间 但是我的应用程序没有因 OutOfMemory 错误而退出，并且我对 JVM 压缩类空间的预期使用情况感兴趣。
我的应用程序压缩类空间是否应该随着垃圾收集而上下变化？如果我看到压缩类空间使用量随着时间的推移逐渐增加，这是否表明存在内存泄漏（幸存者和伊甸园空间随着垃圾收集而上下波动，并且看起来并不高）？
我们遇到了一个问题，压缩的类空间达到 1Gb 限制，并且应用程序变得无响应。我已经进行了一些更改来尝试解决此问题，但很难 100% 判断问题是否得到解决。如果我的压缩类空间不足，增加它是否合理，或者我的应用程序可能会继续全部可用，直到用完为止？如果 Eden 和 Survivor 空间随着垃圾收集而上下波动，这是否意味着我的应用程序没有内存泄漏，或者压缩类空间问题仍然存在？
我的应用程序压缩类空间是否应该通过垃圾回收来上下移动？
当定义新类时，压缩的类空间将会上升，如果垃圾收集器检测到现有类不再可达......并收集它们，压缩的类空间将会下降。
我们无法说出您的应用程序会发生什么，因为这取决于它的设计工作方式。 如果您的应用程序动态定义新类并且您已经修复了任何类泄漏（即类的内存泄漏），那么您应该看到压缩的类空间随着垃圾收集而上下移动。
如果我看到压缩类空间使用量随着时间的推移逐渐增加，这是否表明存在内存泄漏？
可能是的。
如果我的压缩类空间不足，增加它是否合理，或者我的应用程序可能会继续全部可用，直到用完为止？
如果增加率大致呈线性，最终您将达到无法再增加压缩类空间限制的程度。
但我们无法告诉您应用程序的行为方式。 因此，（只是）增加限制是否“合理”。 这将取决于实际增长率是多少，是否是线性的，以及耗尽的现实世界后果是什么。 还有...
找到类泄漏的原因有多难，以及
后者。