加快Java -Xms和-Xmx选项的权衡

给定这两个命令

A：

$ java -Xms10G -Xmx10G myjavacode input.txt

B：

$ java -Xms5G -Xmx5G myjavacode input.txt

我有两个问题：

1. 由于命令A保留了更多的参数存储空间，因此A的运行速度会比B快吗？
2. 如何-Xmx和-Xms影响正在运行的进程，我的程序的输出？

这取决于您的Java使用的GC。并行GC在较大的内存设置上可能会更好地工作-尽管我不是专家。

通常，如果您拥有更大的内存，则不需频繁对其进行GC处理-会有大量的垃圾空间。但是，当涉及到GC时，GC必须在更多的内存上工作-从而可能会变慢。

该-Xmx参数定义堆可以为JVM达到的最大内存大小。您必须非常了解您的程序，并查看其在负载下的性能，并相应地设置此参数。如果程序的堆内存达到最大堆大小，则较低的值可能会导致OutOfMemoryExceptions或非常差的性能。如果您的程序在专用服务器上运行，则可以将此参数设置得更高一些，因为它不会影响其他程序。

该-Xms参数设置JVM的初始堆内存大小。这意味着，当您启动程序时，JVM将立即分配此内存量。如果您的程序从一开始就消耗大量堆内存，这将很有用。这样可以避免JVM不断增加堆并在那里获得一些性能。如果您不知道此参数是否会对您有所帮助，请不要使用它。

总而言之，这是一个折衷方案，您只能根据程序的内存行为来决定。

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

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

解决方案是从会话中逐出旧对象。

斯图尔特

1. 分配始终取决于您的操作系统。如果分配过多的内存，最终可能会将部分加载到交换中，这确实很慢。
2. 程序运行速度是慢还是快取决于VM必须处理和清理的引用。GC不必遍历已分配的内存来查找废弃的对象。它知道对象以及它们通过引用映射分配的内存量。因此，扫描仅取决于对象的大小。如果您的程序在两种情况下的行为均相同，则唯一的性能影响应该是对VM启动，VM尝试分配操作系统提供的内存以及使用交换（再次导致结果为1）。

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

如果使用的是Java 6，则可以使用jconsole（在jdk的bin目录中）附加到您的进程，并观察收集器的行为。通常，收集器非常聪明，您不需要进行任何调整，但是如果有需要，可以使用许多选项来进一步调整收集过程。

-Xms和-Xmx的各种设置之间的速度折衷取决于运行Java应用程序的应用程序和系统。它还取决于您的JVM和使用的其他垃圾回收参数。

这个问题已有11年历史了，从那时起，JVM参数对性能的影响就变得更加难以预先预测。因此，您可以尝试使用不同的值并查看对性能的影响，或者使用免费的工具（如Optimizer Studio）自动找到最佳的JVM参数值。

> 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.

这些-X选件是非标准的，如有更改，恕不另行通知。

（复制粘贴）

这一直是我在一个应用程序上工作时遇到的问题，该应用程序为每个请求创建大量线程。

因此，这是一个非常好的问题，它涉及两个方面：
1.我的Xms和Xmx值是否应该相同
       -大多数网站，甚至oracle文档都建议相同。但是，我建议在这些值之间留出10％到20％的缓冲区，以便在突然的高流量高峰或偶然的内存泄漏的情况下为应用程序调整堆大小。

2.是否应该以较小的堆大小启动我的应用程序
       -这就是问题-无论您使用哪种GC算法（甚至是G1），大堆总会有一些折衷。目的是确定应用程序的行为，以使其可以在延迟和吞吐量方面允许GC暂停的堆大小为准。
              -例如，如果您的应用程序有很多线程（每个线程在本机内存中有1 MB堆栈，在堆中没有），但是不占用大量对象空间，那么我建议使用较低的Xms值。
              -如果您的应用程序创建了许多线程数量增加的对象，那么请确定可以设置Xms的值来容忍那些STW暂停。这意味着确定可以容忍的传入请求的最大响应时间，并调整最小堆大小。