加快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的最大内存大小。 你必须很好地了解你的程序,看看它是如何在负载下执行的,并相应地设置这个参数。 如果程序的堆内存达到最大堆大小,则较低的值可能会导致OutOfMemoryExceptionexception或非常差的性能。 如果程序在专用服务器上运行,则可以将此参数设置得更高,因为它不会影响其他程序。

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

总之,这是一个妥协,你必须根据你的程序的内存行为来决定。

我发现在某些情况下,太多的内存会减慢程序速度。

例如,我有一个基于Hibernate的转换引擎,随着负载的增加,它开始缓慢运行。 事实certificate,每次我们从数据库中获得一个对象时,hibernate正在检查永远不会再使用的对象的内存。

解决办法是从会议中逐出旧的物品。

斯图尔特

  1. 分配总是取决于你的操作系统。 如果分配的内存太多,可能会导致将部分内容加载到交换中,这确实很慢。
  2. 无论您的程序运行速度是否更慢,都取决于VM必须处理和清理的引用。 GC不必扫描分配的内存来查找废弃的对象。 它知道它是通过引用映射分配的对象和内存量。 所以清扫只取决于你的对象的大小。 如果你的程序在这两种情况下performance相同,唯一的性能影响应该是在虚拟机启动时,当虚拟机试图分配你的操作系统提供的内存,并且如果你使用交换(这又会导致1)

很难说内存分配将如何影响你的速度。 这取决于JVM正在使用的垃圾收集algorithm。 例如,如果你的垃圾收集器需要暂停做一个完整的收集,那么如果你有10多个内存比你真正​​需要的收集器将有10多垃圾清理。

如果您使用的是Java 6,则可以使用jconsole(位于jdk的bin目录中)附加到进程,并观察收集器的行为。 一般来说,collections家非常聪明,你不需要做任何调整,但是如果你有需要,你可以使用很多选项来进一步调整collections过程。

 > 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选项是非标准的,如有更改,恕不另行通知。

(复制粘贴)