假设一个64位JVM，将MaxPermSize保持为小有什么显着的好处吗？
这是在经常重新部署的Java EE应用程序的上下文中，并且具有类加载器泄漏。作为一个中期解决方案，将MaxPermSize提升到一个荒谬的价值似乎是非常合理的 - 只要它不会破坏磁盘交换空间。
由于取消部署的应用程序代码几乎全部未使用（除了泄漏中涉及的代码），它已被操作系统分页。因此，未部署碎屑对物理内存的负担似乎可以忽略不计;通过观察RSS（Unix上的工作集大小）验证了这一点。
我应该关注其他影响吗？
答案 0 :(得分：6)
我应该增加客户端虚拟机中永久代的大小吗？
这将永远是一个判断电话。通常，增加一代的大小（这不仅适用于永久代）可以减少各种问题的发生率但是，这可能会导致其他进程过度分页和/或垃圾收集或丢失记忆异常。
有两种失败模式需要考虑。
当提升MaxPermSize时，以前表现良好的用于垃圾收集以恢复永久生成空间的程序可能会因无限的分页而死亡。对于永久性的一代，这通常只发生在临时字符串的重度实习中。
另一种失败模式是必须为永久生成保留地址空间，这将减少堆的其余部分可用的地址空间（最大-Xmx可能因此太大）。这将导致配置为使用所有可用空间的程序在初始化时失败。
同样this article说：
因此，我们利用这样一个事实，即通过在收集终生代之前收集永久世代，将类保留在永久世代中。目前永久性一代是连续收集的。
大型永久性发电可能会导致GC的时间延长。