所以，在问this问题之后，很快就发现重要的问题不是“我怎么能”，而是“我应该”吗？
我们有客户说我们正在从Java7迁移到Java8（使用Tomcat7）。 Java7需要设置-XX:MaxPermSize，，并且由于个人需求和用途，一些客户已将其最大值增加到安装程序的默认设置。
我应该为已定义自定义最大值的客户设置-XX:MaxMetaspaceSize（到之前的-XX:MaxPermSize设置）吗？新安装怎么样？我们应该设置-XX:MaxMetaspaceSize吗？
这样决定的利弊是什么？
答案 0 :(得分：21)
正如我在上一个回答中所评论的，原因对这些内存池设置限制是不同的。
如果您的用户以前增加 MaxPermSize高于默认值，可能是为了避免使用CMS的Full GCs /并发模式失败，或者因为他们的应用程序真正需要大量的perm gen空间。
从有效的无限默认值中减少元空间限制将起到完全不同的作用：避免无限制的元空间增长。
事情是，这只是一个上限。实际提交的，即当前元空间大小将更小。实际上，有一个名为MaxMetaspaceFreeRatio的设置（默认为70％），这意味着实际的元空间大小永远不会超过其占用率的230％。
为了它的增长它首先必须填满，强制垃圾收集（元空间已满）试图释放对象，并且只有当它无法满足其MinMetaspaceFreeRatio（默认的40％）目标时才会在GC循环后，将当前元空间扩展到不超过占用率的230％。
因此在实践中，除非应用程序不断泄漏类加载器/类或生成大量动态代码，否则实际元空间大小应稳定在相对于其实际需要的带内。
TL; DR：可能有理由限制元空间大小，但它们可能与设置perm gen size的原始原因不同。因此，需要重新评估。
答案 1 :(得分：3)
只是为了表达相反的意见，可以使案例始终设置MaxMetaspaceSize。将世界范围内的整个应用程序分组为10个（二进制 - 思考它）组可以讨论原因。但请记住，设置限制仅控制何时会发生该空间的垃圾收集（GC）。
第01组：包含所有非动态类的应用
这个小组让你进入上面提到的稳定乐队。在这种情况下，要设置的大小相当容易确定（就像MaxPermSize那样）并且无论如何都不会有很多（如果有的话）。
第10组：使用动态类的应用程序
鉴于高度强大的第三方图书馆的激增，这个群体中的几乎所有应用程序都不是吗？如果库是Scala / Groovy / etc，你通常不关心它，它只是完全按照你想要的方式使用它。使用死（动态）类的垃圾填充Metaspace的价值是什么？ GC确实来了，它会很贵。我宁愿限制大小，使GC更频繁（但每个停顿时间更少），并且更容易在同一硬件上运行多个应用程序，而不必担心它们各自的元空间相互运行。
答案 2 :(得分：2)
来自@eckes评论的回答：
我会设置一个足够大的最大值，以便在正常情况下不会触发 的情况。我说这个的原因是，一个系统可能会非常有效 如果本机内存耗尽或疯狂，则不稳定且难以控制 交换发生。 Mich比OOM或Java冻结更糟糕。例如 使用2GB（期望系统至少有2gb缓冲区）