为什么（Sun）JVM具有固定的内存使用上限（-Xmx）？ [英] Why does the (Sun) JVM have a fixed upper limit for memory usage (-Xmx)?

问题描述

本着质疑的精神 Java：为什么MaxPermSize存在？，我我想问一下为什么Sun JVM对其内存分配池的大小使用固定的上限。

In the spirit of question Java: Why does MaxPermSize exist?, I'd like to ask why the Sun JVM uses a fixed upper limit for the size of its memory allocation pool.

默认值是物理RAM的1/4（上限） &下限）;因此，如果你有一个需要内存的应用程序，你必须手动更改限制（参数-Xmx），否则你的应用程序将表现不佳，甚至可能因OutOfMemoryError崩溃。

The default is 1/4 of your physical RAM (with upper & lower limit); as a consequence, if you have a memory-hungry application you have to manually change the limit (parameter -Xmx), or your app will perform poorly, possible even crash with an OutOfMemoryError.

为什么这个固定限制甚至存在？为什么JVM不会根据需要分配内存，就像本机程序在大多数操作系统上一样？

Why does this fixed limit even exist? Why does the JVM not allocate memory as needed, like native programs do on most operating systems?

这将解决Java软件的一大类常见问题（只需google到通过设置-Xmx来查看解决问题的网上有多少提示。

This would solve a whole class of common problems with Java software (just google to see how many hints there are on the net on solving problems by setting -Xmx).

编辑：

一些答案​​指出，这将保护系统的其余部分免受Java程序的影响而导致内存泄漏;没有限制，这将耗尽整个系统耗尽所有内存。这是事实，然而，对于任何其他程序同样如此，现代操作系统已经允许您限制程序的最大内存（Linux ulimit，Windows作业对象）。所以这并没有真正回答这个问题，即为什么JVM的做法与大多数其他程序/运行时环境不同？。

Some answers point out that this will protect the rest of the system from a Java program with a run-away memory leak; without the limit this would bring the whole system down by exhausting all memory. This is true, however, it is equally true for any other program, and modern OSes already let you limit the maximum memory for a programm (Linux ulimit, Windows "Job Objects"). So this does not really answer the question, which is "Why does the JVM do it differently from most other programs / runtime environments?".

推荐答案

嗯，我将尝试总结目前为止的答案。

Hm, I'll try summarizing the answers so far.

JVM需要对其堆大小进行硬限制没有技术原因。它可以在没有一个的情况下实现，事实上许多其他动态语言都没有。

There is no technical reason why the JVM needs to have a hard limit for its heap size. It could have been implemented without one, and in fact many other dynamic languages do not have this.

因此，给JVM一个堆大小限制只是一个设计决策实施者。再猜测为什么这样做有点困难，可能没有一个原因。最可能的原因是它有助于保护系统免受Java程序的内存泄漏，否则可能耗尽所有RAM并导致其他应用程序崩溃或系统崩溃。

Therefore, giving the JVM a heap size limit was simply a design decision by the implementors. Second-guessing why this was done is a bit difficult, and there may not be a single reason. The most likely reason is that it helps protect a system from a Java program with a memory leak, which might otherwise exhaust all RAM and cause other apps to crash or the system to thrash.

Sun可能已经省略了该功能，只是告诉人们使用操作系统本机资源限制机制，但他们可能希望始终有限制，因此他们自己实现了。
无论如何，JVM需要知道任何这样的限制（以适应其GC策略），因此使用OS本机机制不会节省太多编程工作。

Sun could have omitted the feature and simply told people to use the OS-native resource limiting mechanisms, but they probably wanted to always have a limit, so they implemented it themselves. At any rate, the JVM needs to be aware of any such limit (to adapt its GC strategy), so using an OS-native mechanism would not have saved much programming effort.

此外，有一个原因可以解释为什么这样的内置限制对于JVM比没有GC的普通程序（例如C / C ++程序）更重要：

Also, there is one reason why such a built-in limit is more important for the JVM than for a "normal" program without GC (such as a C/C++ program):

与具有手动内存管理的程序不同，使用GC的程序实际上并没有明确定义的内存要求，即使使用固定的输入数据也是如此。它只有最低要求，即在给定时间点实际存在（可达）的所有对象的大小总和。但是，在实践中，程序将需要额外的内存来保存死亡但尚未GCed的对象，因为GC无法立即收集每个对象，因为这会导致过多的GC开销。因此，GC只会不时地启动，因此堆上需要一些喘息空间，死对象可以等待GC。

Unlike a program with manual memory management, a program using GC does not really have a well-defined memory requirement, even with fixed input data. It only has a minimum requirement, i.e. the sum of the sizes of all objects that are actually live (reachable) at a given point in time. However, in practice a program will need additional memory to hold dead, but not yet GCed objects, because the GC cannot collect every object right away, as that would cause too much GC overhead. So GC only kicks in from time to time, and therefore some "breathing room" is required on the heap, where dead objects can await the GC.

这意味着使用GC的程序所需的内存实际上是节省内存和良好吞吐量之间的折衷（通过让GC运行较少）。因此，在某些情况下，将堆限制设置为低于JVM将尽可能使用的限制可能是有意义的，因此以牺牲性能为代价来节省RAM。要做到这一点，需要有一种方法来设置堆限制。

This means that the memory required for a program using GC is really a compromise between saving memory and having good througput (by letting the GC run less often). So in some cases it may make sense to set the heap limit lower than what the JVM would use if it could, so save RAM at the expense of performance. To do this, there needs to be a way to set a heap limit.

这篇关于为什么（Sun）JVM具有固定的内存使用上限（-Xmx）？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！