Java的-Xms和-Xmx选项的速度权衡

Given these two commands

鉴于这两个命令

答:

$ java -Xms10G -Xmx10G myjavacode input.txt

$ java -Xms5G -Xmx5G myjavacode input.txt

I have two questions:

我有两个问题:

Since command A reserves more memory with its parameters, will A run faster than B?
既然命令A用它的参数保留了更多的内存，那么A的运行速度会比B快吗?
How do -Xmx and -Xms affect the running process and the output of my program?
-Xmx和-Xms如何影响程序的运行过程和输出?

6 个解决方案

#1

It depends on the GC your java is using. Parallel GCs might work better on larger memory settings - I'm no expert on that though.

这取决于java使用的GC。并行GCs可能在更大的内存设置上工作得更好——尽管我不是这方面的专家。

In general, if you have larger memory the less frequent it needs to be GC-ed - there is lots of room for garbage. However, when it comes to a GC, the GC has to work on more memory - which in turn might be slower.

一般来说，如果你有更大的内存，那么就需要更少的GC-ed，因为有很多空间可以放垃圾。然而，当涉及到GC时，GC必须处理更多的内存——这反过来可能会更慢。

#2

163

The -Xmx argument defines the max memory size that the heap can reach for the JVM. You must know your program well and see how it performs under load and set this parameter accordingly. A low value can cause OutOfMemoryExceptions or a very poor performance if your program's heap memory is reaching the maximum heap size. If your program is running in dedicated server you can set this parameter higher because it wont affect other programs.

xmx参数定义堆可以达到JVM的最大内存大小。您必须非常了解您的程序，并了解它在负载下的执行情况，并相应地设置此参数。如果您的程序的堆内存达到最大堆大小，那么低值可能导致outofmemoryexception或非常糟糕的性能。如果您的程序在专用服务器中运行，您可以将该参数设置得更高，因为它不会影响其他程序。

The -Xms argument sets the initial heap memory size for the JVM. This means that when you start your program the JVM will allocate this amount of memory instantly. This is useful if your program will consume a large amount of heap memory right from the start. This avoids the JVM to be constantly increasing the heap and can gain some performance there. If you don't know if this parameter is going to help you, don't use it.

xms参数设置JVM的初始堆内存大小。这意味着当您启动程序时，JVM将立即分配这段内存。如果您的程序从一开始就消耗大量堆内存，那么这将非常有用。这样可以避免JVM不断地增加堆，从而获得一些性能。如果你不知道这个参数是否对你有帮助，不要使用它。

In summary, this is a compromise that you have to decide based only in the memory behavior of your program.

总之，这是一种妥协，您必须根据程序的内存行为来决定。

#3

I have found that in some cases too much memory can slow the program down.

我发现在某些情况下，内存过多会使程序变慢。

For example I had a hibernate based transform engine that started running slowly as the load increased. It turned out that each time we got an object from the db, hibernate was checking memory for objects that would never be used again.

例如，我有一个基于hibernate的转换引擎，随着负载的增加，它开始缓慢运行。事实证明，每次我们从db获得一个对象时，hibernate都会检查内存中是否有再也不会使用的对象。

The solution was to evict the old objects from the session.

解决方案是从会话中删除旧对象。

Stuart

斯图尔特

#4

Allocation always depends on your OS. If you allocate too much memory, you could end up having loaded portions into swap, which indeed is slow.
分配总是取决于您的操作系统。如果您分配了太多的内存，那么您可能最终将部分加载到交换器中，这确实很慢。
Whether your program runs slower or faster depends on the references the VM has to handle and to clean. The GC doesn't have to sweep through the allocated memory to find abandoned objects. It knows it's objects and the amount of memory they allocate by reference mapping. So sweeping just depends on the size of your objects. If your program behaves the same in both cases, the only performance impact should be on VM startup, when the VM tries to allocate memory provided by your OS and if you use the swap (which again leads to 1.)
程序的运行速度是慢还是快取决于VM必须处理和清理的引用。GC不需要遍历分配的内存来找到被丢弃的对象。它知道它是对象，以及它们通过引用映射分配的内存量。所以扫频取决于物体的大小。如果您的程序在这两种情况下的行为相同，那么惟一的性能影响应该是在VM启动时，当VM试图分配OS提供的内存时，如果您使用交换(这又导致了1)。

#5

It is difficult to say how the memory allocation will affect your speed. It depends on the garbage collection algorithm the JVM is using. For example if your garbage collector needs to pause to do a full collection, then if you have 10 more memory than you really need then the collector will have 10 more garbage to clean up.

很难说内存分配将如何影响您的速度。这取决于JVM使用的垃圾收集算法。例如，如果您的垃圾收集器需要暂停以执行完整的收集，那么如果您有超过实际需要的10个内存，那么收集器将有10个以上的垃圾需要清理。

If you are using java 6 you can use the jconsole (in the bin directory of the jdk) to attach to your process and watch how the collector is behaving. In general the collectors are very smart and you won't need to do any tuning, but if you have a need there are numerous options you have use to further tune the collection process.

如果您正在使用java 6，您可以使用jconsole(在jdk的bin目录中)附加到您的进程，并观察收集器的行为。一般来说，收集器非常聪明，您不需要进行任何调优，但是如果需要，您可以使用许多选项来进一步调优收集过程。

#6

> C:\java -X

-Xmixed           mixed mode execution (default)
-Xint             interpreted mode execution only
-Xbootclasspath:<directories and zip/jar files separated by ;>
                  set search path for bootstrap classes and resources
-Xbootclasspath/a:<directories and zip/jar files separated by ;>
                  append to end of bootstrap class path
-Xbootclasspath/p:<directories and zip/jar files separated by ;>
                  prepend in front of bootstrap class path
-Xnoclassgc       disable class garbage collection
-Xincgc           enable incremental garbage collection
-Xloggc:<file>    log GC status to a file with time stamps
-Xbatch           disable background compilation
-Xms<size>        set initial Java heap size
-Xmx<size>        set maximum Java heap size
-Xss<size>        set java thread stack size
-Xprof            output cpu profiling data
-Xfuture          enable strictest checks, anticipating future default
-Xrs              reduce use of OS signals by Java/VM (see documentation)
-Xcheck:jni       perform additional checks for JNI functions
-Xshare:off       do not attempt to use shared class data
-Xshare:auto      use shared class data if possible (default)
-Xshare:on        require using shared class data, otherwise fail.

The -X options are non-standard and subject to change without notice.

-X选项是非标准的，并在不另行通知的情况下更改。

(copy-paste)

(复制粘贴)

#1