Java：为什么存在 MaxPermSize？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/3356005/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Java: Why does MaxPermSize exist?
提问by Jonathan Allen
Why does MaxPermSize exist?
为什么 MaxPermSize 存在？
回答by D?nu
回答by Elf King
It exists because it helps tune the Garbage Collection subsystem within the JVM. Depending on the underlying architecture and memory management, a JVM implementation may have sub-optimal garbage collection (too thrashy for example) ... You can specify a MaxPermSize by hand rather than have it calculated so that the application behaves smoothly...
它的存在是因为它有助于调整 JVM 中的垃圾收集子系统。根据底层体系结构和内存管理，JVM 实现可能具有次优垃圾收集（例如，太麻烦）……您可以手动指定 MaxPermSize，而不是计算它，以便应用程序运行顺畅……
回答by luke
Here is a good article on the Permanent generation in the Garbage collector:
这是一篇关于垃圾收集器中永久代的好文章：
Presenting the Permanent Generationon Jon Masamitsu's Weblog
EDIT:
编辑：
I haven't seen anything that would indicate why they made the design decision to have a max limit on the permanent generation size. But i imagine it was done for several reasons.
我没有看到任何可以表明他们为什么做出对永久代大小有最大限制的设计决定的东西。但我想这是出于几个原因。
It makes it much easier to implement, GCs are decidedly non trivial so simplifying your implementation in any way is probably a good idea.
YAGNI (You aint gonna need it) most applications load a fixed number of classes and usually its not particularly large, so they have probably optimized for the common case and just picked a sane default and left it configurable.
Assuming that your perm gen size is growing to be unpredictably large, then you probably have an error in a class loader (or need to rethink your architecture). Even in applications that do generate classes at run time (or do other such tricks) the number of generated classes is usually fixed as well, so you should be able to tune maxperm to fit your needs.
I'm no expert on all the details of java class loading and garbage collection but they are both complicated parts of the JVM so i imagine that they would try to keep these two components as orthogonal as possible, and allowing for the perm gen to grow dynamically would probably couple these two components together in complicated ways (especially because both components have serious threading considerations)
There are probably some performance benefits to capping the max perm generation, allowing it to grow might involve extra copying of the collection, or it might mean that your perm generation no longer exists in a contiguous address space, which could effect the way your other algorithms work for managing the collection.
它使它更容易实现，GC 绝对不是微不足道的，因此以任何方式简化您的实现可能是一个好主意。
YAGNI（你不会需要它）大多数应用程序加载固定数量的类，通常它不是特别大，所以他们可能已经针对常见情况进行了优化，只是选择了一个合理的默认值并使其可配置。
假设您的 perm gen 大小增长到不可预测的大，那么您可能在类加载器中出现错误（或需要重新考虑您的架构）。即使在运行时生成类（或执行其他此类技巧）的应用程序中，生成的类的数量通常也是固定的，因此您应该能够调整 maxperm 以满足您的需要。
我不是 Java 类加载和垃圾收集的所有细节的专家，但它们都是 JVM 的复杂部分，所以我想他们会尽量保持这两个组件正交，并允许 perm gen 增长动态可能会以复杂的方式将这两个组件耦合在一起（特别是因为这两个组件都有严重的线程问题）
限制最大永久代可能有一些性能优势，允许它增长可能涉及额外的集合复制，或者这可能意味着您的永久代不再存在于连续的地址空间中，这可能会影响其他算法的方式管理集合的工作。
Obviously these are all speculation. But even if all these are wrong i definitely don't think that it is 'idiotic' for sun to have chosen a fixed size, there are probably way more engineering and implementation considerations than i could even dream of :)
显然，这些都是猜测。但即使所有这些都是错误的，我绝对不认为 sun 选择固定大小是“愚蠢的”，可能还有比我想象的更多的工程和实施考虑：)
回答by Trent Gray-Donald
To present a slightly different perspective, the IBM JVM doesn't have a permgen, but rather goes out to the OS and allocates chunks of memory as it needs them. (rumor is jrockit does the same, but I can't confirm for sure.)
从稍微不同的角度来看，IBM JVM 没有永久代，而是进入操作系统并根据需要分配内存块。（有传言说 jrockit 也是如此，但我无法确定。）
This is advantageous in that you're not going to hit a (seemingly) arbitrary limit and need to tune it for legitimate growth situations.
这是有利的，因为您不会达到（看似）任意的限制，并且需要针对合法的增长情况对其进行调整。
On the flip side, it's a problem for runaway apps (that essentially leak classes) - the JVM will essentially go and consume all memory in the address space. This can result in badness, where native code will suddenly fail malloc() calls, or Java breaking in odd ways - like being unable to allocate new threads (which consumes memory for the stack). Another downside is that it doesn't provide "cost certainty" about how much memory part of the JVM will consume.
另一方面，对于失控的应用程序（本质上是泄漏类）来说，这是一个问题——JVM 本质上会消耗地址空间中的所有内存。这可能导致糟糕的情况，其中本机代码会突然失败 malloc() 调用，或者 Java 以奇怪的方式中断 - 例如无法分配新线程（这会消耗堆栈的内存）。另一个缺点是它不能提供有关 JVM 将消耗多少内存部分的“成本确定性”。
So it's a tradeoff - how do you want to fail in "potential badness" scenarios?
所以这是一个权衡——你想如何在“潜在的坏处”场景中失败？
回答by Zuhaib
The permanent generation is used to hold reflective of the VM itself such as class objects and method objects. These reflective objects are allocated directly into the permanent generation, and it is sized independently from the other generations. Generally, sizing of this generation can be ignored because the default size is adequate. However, programs that load many classes may need a larger permanent generation.
永久代用于保存 VM 本身的反映，例如类对象和方法对象。这些反射对象直接分配到永久代中，并且它的大小独立于其他代。通常，可以忽略这一代的大小，因为默认大小就足够了。但是，加载许多类的程序可能需要更大的永久代。
PermSize is additional separate heap space to the -Xmx value set by the user. The section of the heap reserved for the permanent generation holds all of the reflective data for the JVM. You should adjust the size accordingly if your application dynamically load and unload a lot of classes in order to optimize the performance. Basically, he heap stores the objects and the perm gen keeps information about the objects inside of it. Therefore, the larger the heap, the larger the perm gen needs to be.
PermSize 是用户设置的 -Xmx 值的额外独立堆空间。为永久代保留的堆部分包含 JVM 的所有反射数据。如果您的应用程序动态加载和卸载大量类，您应该相应地调整大小以优化性能。基本上，heap 存储对象，perm gen 保存有关其中对象的信息。因此，堆越大，perm gen 就需要越大。
By default, MaxPermSize will be 32mb for -client and 64mb for -server. However, if you do not set both PermSize and MaxPermSize, the overall heap will not increase unless it is needed. When you set both PermSize and MaxPermSize, for example, 192mb, the extra heap space will get allocated when it will startup and will stay allocated.
默认情况下，-client 的 MaxPermSize 为 32mb，-server 的 MaxPermSize 为 64mb。但是，如果您没有同时设置 PermSize 和 MaxPermSize，则除非需要，否则整个堆不会增加。当您同时设置 PermSize 和 MaxPermSize（例如 192mb）时，额外的堆空间将在启动时分配并保持分配状态。
回答by Albert Renshaw
Perhaps you want to give your user the option on how much memory your application will take up, yes the OS does have a limit and will stop it anyways, but maybe the user wants to be able to limit it in the applications settings so they can do other things with that memory later on in the day without crashing your app because it's ALREADYtaken up that space and can't release it because it's using it. So in the settings menu you have a "maximum amount of memory we use" slider and they can adjust it which correspondingly adjusts the MaxPermSize.
也许您想让您的用户选择您的应用程序将占用多少内存，是的，操作系统确实有限制并且无论如何都会停止它，但也许用户希望能够在应用程序设置中对其进行限制，以便他们可以当天晚些时候使用该内存做其他事情而不会崩溃您的应用程序，因为它已经占用了该空间并且无法释放它，因为它正在使用它。因此，在设置菜单中，您有一个“我们使用的最大内存量”滑块，他们可以对其进行调整，从而相应地调整MaxPermSize.
回答by ProfWrightBSU
By having the MaxPermSize setting your app will throw the GC Out of Memory error at startup, so that you don't think your app is up and running and have your customers calling because the system doesn't work or is very sluggish.
通过设置 MaxPermSize，您的应用程序将在启动时抛出 GC Out of Memory 错误，因此您不会认为您的应用程序已启动并正在运行，并且您的客户不会因为系统不工作或非常缓慢而打电话。
Let's say you have 4gb on your VM and you know that you need 2gb of non-perm space for your app to hit the contractually agreed upon performance metrics. If your perm gen is going to take up more than 2gb, there is no point in starting the app, because you won't be able to meet your performance measures listed in your statement of work.
假设您的 VM 上有 4gb，并且您知道您的应用需要 2gb 的非永久空间才能达到合同约定的性能指标。如果您的 perm gen 将占用超过 2GB 的空间，则启动该应用程序毫无意义，因为您将无法满足工作说明书中列出的性能指标。
It is better to know that at startup, and get more memory into the box, or reconfigure your VM to take more of the physical server memory (whatever the case may be) than to start the application, allow the classes, ehcache, or whatever else to load, think everything is fine and then find out from your customers that the system is taking 10 seconds to load a page.
最好在启动时知道这一点，并在框中获得更多内存，或者重新配置您的 VM 以占用更多物理服务器内存（无论情况如何），而不是启动应用程序、允许类、ehcache 或其他任何内容否则加载，认为一切都很好，然后从您的客户那里发现系统加载页面需要 10 秒钟。
