不能配置虚拟机所需内存数量。但是，请注意，这是虚拟内存，而不是常驻内存，因此如果不实际使用，它只会保持在那里而不会受到损害。

提醒一下，您可以尝试其他JVM，而不是Sun JVM，内存占用更小，但我不能在这里建议。

Sun的java 1.4有以下参数来控制内存大小:

-Xmsn Specify the initial size, in bytes, of the memory allocation pool. This value must be a multiple of 1024 greater than 1MB. Append the letter k or K to indicate kilobytes, or m or M to indicate megabytes. The default value is 2MB. Examples: -Xms6291456 -Xms6144k -Xms6m -Xmxn Specify the maximum size, in bytes, of the memory allocation pool. This value must a multiple of 1024 greater than 2MB. Append the letter k or K to indicate kilobytes, or m or M to indicate megabytes. The default value is 64MB. Examples: -Xmx83886080 -Xmx81920k -Xmx80m

http://java.sun.com/j2se/1.4.2/docs/tooldocs/windows/java.html

Java 5和6有更多的功能。参见http://java.sun.com/javase/technologies/hotspot/vmoptions.jsp

只是一个想法，但是您可以检查ulimit -v选项的影响。

这不是一个实际的解决方案，因为它将限制所有进程可用的地址空间，但这将允许您使用有限的虚拟内存检查应用程序的行为。

这是Java长期以来的一个抱怨，但它在很大程度上是没有意义的，而且通常是基于查看错误的信息。通常的说法是“Java上的Hello World需要10兆字节!”它为什么需要这个?”好吧，这里有一种方法可以让Hello World在64位JVM上占用超过4g字节……至少从一种衡量方式来看是这样的。

java -Xms1024m -Xmx4096m com.example.Hello

测量内存的不同方法

在Linux上，top命令为内存提供了几个不同的数字。下面是关于Hello World的例子:

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 2120 kgregory  20   0 4373m  15m 7152 S    0  0.2   0:00.10 java

VIRT is the virtual memory space: the sum of everything in the virtual memory map (see below). It is largely meaningless, except when it isn't (see below). RES is the resident set size: the number of pages that are currently resident in RAM. In almost all cases, this is the only number that you should use when saying "too big." But it's still not a very good number, especially when talking about Java. SHR is the amount of resident memory that is shared with other processes. For a Java process, this is typically limited to shared libraries and memory-mapped JARfiles. In this example, I only had one Java process running, so I suspect that the 7k is a result of libraries used by the OS. SWAP isn't turned on by default, and isn't shown here. It indicates the amount of virtual memory that is currently resident on disk, whether or not it's actually in the swap space. The OS is very good about keeping active pages in RAM, and the only cures for swapping are (1) buy more memory, or (2) reduce the number of processes, so it's best to ignore this number.

Windows任务管理器的情况要复杂一些。在Windows XP下，有“内存使用”和“虚拟内存大小”列，但官方文档对它们的含义保持沉默。Windows Vista和Windows 7增加了更多的列，它们实际上是有文档的。其中，“工作集”测量是最有用的;它大致相当于Linux上RES和SHR的总和。

了解虚拟内存映射

The virtual memory consumed by a process is the total of everything that's in the process memory map. This includes data (eg, the Java heap), but also all of the shared libraries and memory-mapped files used by the program. On Linux, you can use the pmap command to see all of the things mapped into the process space (from here on out I'm only going to refer to Linux, because it's what I use; I'm sure there are equivalent tools for Windows). Here's an excerpt from the memory map of the "Hello World" program; the entire memory map is over 100 lines long, and it's not unusual to have a thousand-line list.

0000000040000000     36K r-x--  /usr/local/java/jdk-1.6-x64/bin/java
0000000040108000      8K rwx--  /usr/local/java/jdk-1.6-x64/bin/java
0000000040eba000    676K rwx--    [ anon ]
00000006fae00000  21248K rwx--    [ anon ]
00000006fc2c0000  62720K rwx--    [ anon ]
0000000700000000 699072K rwx--    [ anon ]
000000072aab0000 2097152K rwx--    [ anon ]
00000007aaab0000 349504K rwx--    [ anon ]
00000007c0000000 1048576K rwx--    [ anon ]
...
00007fa1ed00d000   1652K r-xs-  /usr/local/java/jdk-1.6-x64/jre/lib/rt.jar
...
00007fa1ed1d3000   1024K rwx--    [ anon ]
00007fa1ed2d3000      4K -----    [ anon ]
00007fa1ed2d4000   1024K rwx--    [ anon ]
00007fa1ed3d4000      4K -----    [ anon ]
...
00007fa1f20d3000    164K r-x--  /usr/local/java/jdk-1.6-x64/jre/lib/amd64/libjava.so
00007fa1f20fc000   1020K -----  /usr/local/java/jdk-1.6-x64/jre/lib/amd64/libjava.so
00007fa1f21fb000     28K rwx--  /usr/local/java/jdk-1.6-x64/jre/lib/amd64/libjava.so
...
00007fa1f34aa000   1576K r-x--  /lib/x86_64-linux-gnu/libc-2.13.so
00007fa1f3634000   2044K -----  /lib/x86_64-linux-gnu/libc-2.13.so
00007fa1f3833000     16K r-x--  /lib/x86_64-linux-gnu/libc-2.13.so
00007fa1f3837000      4K rwx--  /lib/x86_64-linux-gnu/libc-2.13.so
...

简单解释一下格式:每一行都以段的虚拟内存地址开始。接下来是段大小、权限和段的源。最后一项是一个文件或“anon”，它表示通过mmap分配的内存块。

从上面开始，我们有

The JVM loader (ie, the program that gets run when you type java). This is very small; all it does is load in the shared libraries where the real JVM code is stored. A bunch of anon blocks holding the Java heap and internal data. This is a Sun JVM, so the heap is broken into multiple generations, each of which is its own memory block. Note that the JVM allocates virtual memory space based on the -Xmx value; this allows it to have a contiguous heap. The -Xms value is used internally to say how much of the heap is "in use" when the program starts, and to trigger garbage collection as that limit is approached. A memory-mapped JARfile, in this case the file that holds the "JDK classes." When you memory-map a JAR, you can access the files within it very efficiently (versus reading it from the start each time). The Sun JVM will memory-map all JARs on the classpath; if your application code needs to access a JAR, you can also memory-map it. Per-thread data for two threads. The 1M block is the thread stack. I didn't have a good explanation for the 4k block, but @ericsoe identified it as a "guard block": it does not have read/write permissions, so will cause a segment fault if accessed, and the JVM catches that and translates it to a StackOverFlowError. For a real app, you will see dozens if not hundreds of these entries repeated through the memory map. One of the shared libraries that holds the actual JVM code. There are several of these. The shared library for the C standard library. This is just one of many things that the JVM loads that are not strictly part of Java.

共享库特别有趣:每个共享库至少有两个段:一个只读段包含库代码，一个读写段包含库的全局每进程数据(我不知道没有权限的段是什么;我只在x64 Linux上见过)。库的只读部分可以在所有使用该库的进程之间共享;例如，libc有1.5M的虚拟内存空间可以共享。

什么时候虚拟内存大小很重要?

虚拟内存映射包含很多东西。其中一些是只读的，一些是共享的，还有一些是已分配但从未被触及的(例如，在本例中几乎所有的4Gb堆)。但是操作系统足够智能，只加载它需要的东西，所以虚拟内存大小在很大程度上是无关紧要的。

虚拟内存大小很重要的情况是，如果运行在32位操作系统上，则只能分配2Gb(某些情况下是3Gb)进程地址空间。在这种情况下，您正在处理稀缺资源，并且可能不得不做出权衡，例如为了内存映射一个大文件或创建大量线程而减小堆大小。

但是，考虑到64位计算机无处不在，我不认为虚拟内存大小将是一个完全无关的统计数据。

常驻集大小什么时候重要?

常驻集大小是RAM中实际存在的虚拟内存空间的一部分。如果您的RSS增长到总物理内存的很大一部分，那么可能是时候开始担心了。如果您的RSS增长到占用您所有的物理内存，并且您的系统开始交换，那么您早就该开始担心了。

但是RSS也会误导人，特别是在负载较轻的机器上。操作系统不需要花费大量精力来回收进程使用的页面。这样做几乎没有什么好处，而且如果将来流程接触页面，可能会出现代价高昂的页面错误。因此，RSS统计数据可能包括许多不活跃使用的页面。

底线

除非您正在进行交换，否则不要过度关注各种内存统计数据告诉您的信息。需要注意的是，不断增长的RSS可能表明某种类型的内存泄漏。

对于Java程序，关注堆中发生的事情要重要得多。所消耗的空间总量很重要，您可以采取一些步骤来减少空间总量。更重要的是在垃圾收集上花费的时间，以及收集堆的哪些部分。

访问磁盘(即数据库)是昂贵的，而内存是便宜的。如果你可以用其中一个来交换另一个，那就这样做。

分配给Java进程的内存量与我所期望的相当。我在嵌入式/内存有限的系统上运行Java时也遇到过类似的问题。运行任何具有任意VM限制的应用程序，或者在没有足够交换量的系统上运行应用程序，都容易崩溃。这似乎是许多现代应用程序的本质，它们的设计并不适合在资源有限的系统上使用。

您还可以尝试其他一些选项来限制JVM的内存占用。这可能会减少虚拟内存占用:

- xx:ReservedCodeCacheSize=32m保留代码缓存大小(单位:字节)- maximum 代码缓存大小。(Solaris 64位, -server x86: 48m;在 1.5.0_06及以前版本，Solaris 64位和and64: 1024m。 -XX:MaxPermSize=64m永久代的大小。[5.0及更新版本: 64位虚拟机扩展30%;1．4 amd64: 96;1.3.1 -client: 32m.]

此外，还应该将-Xmx(最大堆大小)设置为尽可能接近应用程序实际内存使用峰值的值。我相信JVM的默认行为仍然是每次将堆大小扩展到最大时将堆大小增加一倍。如果你从32M的堆开始，你的应用程序的峰值是65M，那么堆最终会增长32M -> 64M -> 128M。

你也可以尝试这样做，让VM不那么积极地增长堆:

-XX:MinHeapFreeRatio=40垃圾回收后的最小堆空闲百分比 避免扩张。

另外，根据我几年前的实验，加载的本机库的数量对最小内存占用有很大的影响。如果我没记错的话(我可能记错了)，加载java.net.Socket增加了超过15M。

Sun JVM需要大量内存用于HotSpot，并且它将运行时库映射到共享内存中。

如果内存是个问题，可以考虑使用另一个适合嵌入的JVM。IBM有j9，还有使用GNU类路径库的开源“jamvm”。此外，Sun在sun黑子上运行了Squeak JVM，所以有替代方案。

使用-XX:MaxHeapFreeRatio变量是在资源有限的情况下减少系统堆的一种方法。这通常设置为70，是GC收缩堆之前的最大空闲百分比。将它设置为一个较低的值，您将在eg jvisualvm分析器中看到您的程序通常使用较小的堆块。

编辑:要为-XX:MaxHeapFreeRatio设置小值，必须同时设置-XX:MinHeapFreeRatio 如

java -XX:MinHeapFreeRatio=10 -XX:MaxHeapFreeRatio=25 HelloWorld

EDIT2:添加了一个实际应用程序的示例，该应用程序启动并执行相同的任务，一个使用默认参数，另一个使用10和25作为参数。我没有注意到任何实际的速度差异，尽管在后面的例子中，java理论上应该使用更多的时间来增加堆。

最后，最大堆是905，使用堆是378

最后，最大堆是722，使用堆是378

这实际上有一些影响，因为我们的应用程序运行在远程桌面服务器上，许多用户可能同时运行它。

Java和glibc >= 2.10(包括Ubuntu >= 10.04, RHEL >= 6)有一个已知的问题。

解药是把这个环境。变量:

export MALLOC_ARENA_MAX=4

如果您正在运行Tomcat，您可以将此添加到TOMCAT_HOME/bin/setenv.sh文件中。

对于Docker，将此添加到Dockerfile

ENV MALLOC_ARENA_MAX=4

IBM有一篇关于设置MALLOC_ARENA_MAX的文章 https://www.ibm.com/developerworks/community/blogs/kevgrig/entry/linux_glibc_2_10_rhel_6_malloc_may_show_excessive_virtual_memory_usage?lang=en

这篇博文说

常驻记忆以一种类似于 内存泄漏或内存碎片。

还有一个开放的JDK bug JDK-8193521“glibc默认配置浪费内存”

在谷歌或SO上搜索MALLOC_ARENA_MAX以获得更多参考。

你可能还想调优其他malloc选项，以优化低内存碎片分配:

# tune glibc memory allocation, optimize for low fragmentation
# limit the number of arenas
export MALLOC_ARENA_MAX=2
# disable dynamic mmap threshold, see M_MMAP_THRESHOLD in "man mallopt"
export MALLOC_MMAP_THRESHOLD_=131072
export MALLOC_TRIM_THRESHOLD_=131072
export MALLOC_TOP_PAD_=131072
export MALLOC_MMAP_MAX_=65536