jvm默认xss_Jvm默认新生代和老年代的比例

文章目录：

• 1、JVM线程的栈在64位Linux操作系统上的默认大小是多少
• 2、如何修改jvm启动参数
• 3、centos tomcat7 jvm 默认值是多少
• 4、如何设置jvm启动参数
• 5、java jvm内存可以设置多少
• 6、如何设置Java虚拟机JVM启动内存参数

JVM线程的栈在64位Linux操作系统上的默认大小是多少

不显式设置-Xss或-XX:ThreadStackSize时，在Linux x64上ThreadStackSize的默认值就是1024KB，给Java线程创建栈会用这个参数指定的大小。这是前一块代码的意思。

如果把-Xss或者-XX:ThreadStackSize设为0，就是使用“系统默认值”。而在Linux x64上HotSpot VM给Java栈定义的“系统默认”大小也是1MB。

所以这个条件下普通Java线程的默认栈大小怎样都是1MB。

如何修改jvm启动参数

用java命令查看。

用java -option进行修改参数。

还有tomcat，eclipse启动时通过配置文件加载的。

详细如下：

安装Java开发软件时，默认安装包含两个文件夹，一个JDK(Java开发工具箱)，一个JRE(Java运行环境，内含JVM)，其中JDK内另含一个JRE。如果只是运行Java程序，则JRE已足够；而JDK则只有开发人员才用到。

一、配置JVM内存

1.配置JVM内存的参数

-XmxJavaHeap最大值，默认值为物理内存的1/4，最佳设值应该视物理内存大小及计算机内其他内存开销而定；

-XmsJavaHeap初始值，Server端JVM最好将-Xms和-Xmx设为相同值，开发测试机JVM可以保留默认值；

2.如何配置JVM内存分配：

（1）当在命令提示符下启动并使用JVM时（只对当前运行的类生效）

java-Xmx128m-Xms64m-Xmn32m-Xss16mTest

（2）当在集成开发环境下（如eclipse）启动并使用JVM时：

第一种设置方法：

在eclipse根目录下打开eclipse.ini，默认内容为（这里设置的是运行当前开发工具的JVM内存分配）：

-vmargs-Xms40m-Xmx256m-vmargs表示以下为虚拟机设置参数，可修改其中的参数值，，另外，eclipse.ini内还可以设置非堆内存，如：-XX:PermSize=56m，-XX:MaxPermSize=128m。

此处设置的参数值可以通过以下配置在开发工具的状态栏显示：

在eclipse根目录下创建文件options，文件内容为：org.eclipse.ui/perf/showHeapStatus=true

修改eclipse根目录下的eclipse.ini文件，在开头处添加如下内容：

-debugoptions-vmjavaw.exe重新启动eclipse，就可以看到下方状态条多了JVM信息。

第二种设置方法：

打开eclipse－窗口－首选项－Java－已安装的JRE（对在当前开发环境中运行的java程序皆生效）

编辑当前使用的JRE，在缺省VM参数中输入：-Xmx128m-Xms64m-Xmn32m-Xss16m

第三种设置方法：

打开eclipse－运行－运行－Java应用程序（只对所设置的java类生效）

选定需设置内存分配的类－自变量，在VM自变量中输入：-Xmx128m-Xms64m-Xmn32m-Xss16m

注：如果在同一开发环境中同时进行了第二种和第三种设置，则第二种设置生效，第三种设置无效，如：

开发环境的设置为：-Xmx256m，而类Test的设置为：-Xmx128m-Xms64m，则运行Test时生效的设置为：

-Xmx256m-Xms64m

（3）当在服务器环境下（如Tomcat）启动并使用JVM时（对当前服务器环境下所以Java程序生效）：

a.设置环境变量：

变量名：CATALINA_OPTS

变量值：-Xmx128m-Xms64m-Xmn32m-Xss16m

b.打开Tomcat根目录下的bin文件夹，编辑catalina.bat，将其中的%CATALINA_OPTS%（共有四处）替换为：-Xmx128m-Xms64m-Xmn32m-Xss16m

二、查看配置JVM内存信息

Runtime.getRuntime().maxMemory();//最大可用内存，对应-Xmx

Runtime.getRuntime().freeMemory();//当前JVM空闲内存

Runtime.getRuntime().totalMemory();//当前JVM占用的内存总数，其值相当于当前JVM已使用的内存及freeMemory()的总和

关于maxMemory()，freeMemory()和totalMemory()：

maxMemory()为JVM的最大可用内存，可通过-Xmx设置，默认值为物理内存的1/4，设值不能高于计算机物理内存；

totalMemory()为当前JVM占用的内存总数，其值相当于当前JVM已使用的内存及freeMemory()的总和，会随着JVM使用内存的增加而增加；

freeMemory()为当前JVM空闲内存，因为JVM只有在需要内存时才占用物理内存使用，所以freeMemory()的值一般情况下都很小，而JVM实际可用内存并不等于freeMemory()，而应该等于maxMemory()-totalMemory()+freeMemory()。及其配置JVM内存分配。

centos tomcat7 jvm 默认值是多少

我的服务器的配置：

# OS specific support. $var _must_ be set to either true or false.

JAVA_OPTS="-Xms1024m -Xmx4096m -Xss1024K -XX:PermSize=512m -XX:MaxPermSize=2048m"

正文：

常见的内存溢出有以下两种:

java.lang.OutOfMemoryError: PermGen space

java.lang.OutOfMemoryError: Java heap space

---------------------------------------------------------

这里以tomcat环境为例，其它WEB服务器如jboss,weblogic等是同一个道理。

一、java.lang.OutOfMemoryError: PermGen space

PermGen space的全称是Permanent Generation space,是指内存的永久保存区域,

这块内存主要是被JVM存放Class和Meta信息的,Class在被Loader时就会被放到PermGen space中,

它和存放类实例(Instance)的Heap区域不同,GC(Garbage Collection)不会在主程序运行期对

PermGen space进行清理，所以如果你的应用中有很多CLASS的话,就很可能出现PermGen space错误,

这种错误常见在web服务器对JSP进行pre compile的时候。如果你的WEB APP下都用了大量的第三方jar, 其大小

超过了jvm默认的大小(4M)那么就会产生此错误信息了。

解决方法： 手动设置MaxPermSize大小

建议：将相同的第三方jar文件移置到tomcat/shared/lib目录下，这样可以达到减少jar 文档重复占用内存的目的。

二、java.lang.OutOfMemoryError: Java heap space

JVM堆的设置是指java程序运行过程中JVM可以调配使用的内存空间的设置.JVM在启动的时候会自动设置Heap size的值，

其初始空间(即-Xms)是物理内存的1/64，最大空间(-Xmx)是物理内存的1/4。可以利用JVM提供的-Xmn -Xms -Xmx等选项可

进行设置。Heap size 的大小是Young Generation 和Tenured Generaion 之和。

提示：在JVM中如果98％的时间是用于GC且可用的Heap size 不足2％的时候将抛出此异常信息。

提示：Heap Size 最大不要超过可用物理内存的80％，一般的要将-Xms和-Xmx选项设置为相同，而-Xmn为1/4的-Xmx值。

解决方法：手动设置Heap size

----------------------------------------------------------

Linux下修改JVM内存大小:

要添加在tomcat 的bin 下catalina.sh 里，位置cygwin=false前 。注意引号要带上,红色的为新添加的.

# OS specific support. $var _must_ be set to either true or false.

JAVA_OPTS="-Xms256m -Xmx512m -Xss1024K -XX:PermSize=128m -XX:MaxPermSize=256m"

cygwin=false

windows下修改JVM内存大小:

情况一:解压版本的Tomcat, 要通过startup.bat启动tomcat才能加载配置

要添加在tomcat 的bin 下catalina.bat 里

rem Guess CATALINA_HOME if not defined

set CURRENT_DIR=%cd%后面添加,红色的为新添加的.

set JAVA_OPTS=-Xms256m -Xmx512m -XX:PermSize=128M -XX:MaxNewSize=256m -XX:MaxPermSize=256m -Djava.awt.headless=true

情况二:安装版的Tomcat下没有catalina.bat

windows服务执行的是bin/tomcat.exe.他读取注册表中的值,而不是catalina.bat的设置.

修改注册表HKEY_LOCAL_MACHINE/SOFTWARE/Apache Software Foundation/Tomcat Service Manager/Tomcat5/Parameters/JavaOptions

原值为

-Dcatalina.home="C:/ApacheGroup/Tomcat 5.0"

-Djava.endorsed.dirs="C:/ApacheGroup/Tomcat 5.0/common/endorsed"

-Xrs

加入 -Xms300m -Xmx350m

重起tomcat服务,设置生效

---------------------------------------------------------

各参数的比例:

Xmx 与PermSize的和不可超过JVM可获得的总内存

PermSize不可大于Xmx

================

如何设置Tomcat的JVM虚拟机内存大小

可以给Java虚拟机设置使用的内存，但是如果你的选择不对的话，虚拟机不会补偿。可通过命令行的方式改变虚拟机使用内存的大小。如下表所示有两个参数用来设置虚拟机使用内存的大小。

参数

描述

-Xms

JVM初始化堆的大小

-Xmx

JVM堆的最大值

这 两个值的大小一般根据需要进行设置。初始化堆的大小执行了虚拟机在启动时向系统申请的内存的大小。一般而言，这个参数不重要。但是有的应用程序在大负载的 情况下会急剧地占用更多的内存，此时这个参数就是显得非常重要，如果虚拟机启动时设置使用的内存比较小而在这种情况下有许多对象进行初始化，虚拟机就必须 重复地增加内存来满足使用。由于这种原因，我们一般把-Xms和-Xmx设为一样大，而堆的最大值受限于系统使用的物理内存。一般使用数据量较大的应用程 序会使用持久对象，内存使用有可能迅速地增长。当应用程序需要的内存超出堆的最大值时虚拟机就会提示内存溢出，并且导致应用服务崩溃。因此一般建议堆的最 大值设置为可用内存的最大值的80%。

Tomcat默认可以使用的内存为128MB，在较大型的应用项目中，这点内存是不够的，需要调大。

Windows下，在文件/bin/catalina.bat，Unix下，在文件/bin/catalina.sh的前面，增加如下设置：

JAVA_OPTS='-Xms【初始化内存大小】 -Xmx【可以使用的最大内存】'

需要把这个两个参数值调大。例如：

JAVA_OPTS='-Xms256m -Xmx512m'

表示初始化内存为256MB，可以使用的最大内存为512MB。

另 外需要考虑的是Java提供的垃圾回收机制。虚拟机的堆大小决定了虚拟机花费在收集垃圾上的时间和频度。收集垃圾可以接受的速度与应用有关，应该通过分析 实际的垃圾收集的时间和频率来调整。如果堆的大小很大，那么完全垃圾收集就会很慢，但是频度会降低。如果你把堆的大小和内存的需要一致，完全收集就很快， 但是会更加频繁。调整堆大小的的目的是最小化垃圾收集的时间，以在特定的时间内最大化处理客户的请求。在基准测试的时候，为保证最好的性能，要把堆的大小 设大，保证垃圾收集不在整个基准测试的过程中出现。

如果系统花费很多的时间收集垃圾，请减小堆大小。一次完全的垃圾收集应该不超过 3-5 秒。如果垃圾收集成为瓶颈，那么需要指定代的大小，检查垃圾收集的详细输出，研究 垃圾收集参数对性能的影响。一般说来，你应该使用物理内存的 80% 作为堆大小。当增加处理器时，记得增加内存，因为分配可以并行进行，而垃圾收集不是并行的。

Tomcat 5常用优化和配置

1、JDK内存优化：

Tomcat默认可以使用的内存为128MB,Windows下,在文件{tomcat_home}/bin/catalina.bat，Unix下，在文件{tomcat_home}/bin/catalina.sh的前面，增加如下设置：

JAVA_OPTS='-Xms[初始化内存大小] -Xmx[可以使用的最大内存]

一般说来，你应该使用物理内存的 80% 作为堆大小。

2、连接器优化：

在tomcat配置文件server.xml中的配置中，和连接数相关的参数有：

maxThreads：

Tomcat使用线程来处理接收的每个请求。这个值表示Tomcat可创建的最大的线程数。默认值150。

acceptCount：

指定当所有可以使用的处理请求的线程数都被使用时，可以放到处理队列中的请求数，超过这个数的请求将不予处理。默认值10。

minSpareThreads：

Tomcat初始化时创建的线程数。默认值25。

maxSpareThreads：

一旦创建的线程超过这个值，Tomcat就会关闭不再需要的socket线程。默认值75。

enableLookups：

是否反查域名，默认值为true。为了提高处理能力，应设置为false

connnectionTimeout：

网络连接超时，默认值60000，单位：毫秒。设置为0表示永不超时，这样设置有隐患的。通常可设置为30000毫秒。

maxKeepAliveRequests：

保持请求数量，默认值100。

bufferSize：

输入流缓冲大小，默认值2048 bytes。

compression：

压缩传输，取值on/off/force，默认值off。

其中和最大连接数相关的参数为maxThreads和acceptCount。如果要加大并发连接数，应同时加大这两个参数。web server允许的最大连接数还受制于*作系统的内核参数设置，通常Windows是2000个左右，Linux是1000个左右。

3、tomcat中如何禁止和允许列目录下的文件

在{tomcat_home}/conf/web.xml中，把listings参数设置成false即可，如下：

servlet

...

init-param

param-namelistings/param-name

param-valuefalse/param-value

/init-param

...

/servlet

4、tomcat中如何禁止和允许主机或IP地址访问

Host name="localhost" ...

...

Valve className="org.apache.catalina.valves.RemoteHostValve"

allow="*.mycompany.com,"/

Valve className="org.apache.catalina.valves.RemoteAddrValve"

deny="192.168.1.*"/

...

/Host

服务器的配置

JAVA_OPTS='-server -Xms512m -Xmx768m -XX:NewSize=128m -XX:MaxNewSize=192m -XX:SurvivorRatio=8'

如何设置jvm启动参数

不管是YGC还是Full GC,GC过程中都会对导致程序运行中中断,正确的选择不同的GC策略,调整JVM、GC的参数，可以极大的减少由于GC工作，而导致的程序运行中断方面的问题，进而适当的提高Java程序的工作效率。但是调整GC是以个极为复杂的过程，由于各个程序具备不同的特点，如：web和GUI程序就有很大区别（Web可以适当的停顿，但GUI停顿是客户无法接受的），而且由于跑在各个机器上的配置不同（主要cup个数，内存不同），所以使用的GC种类也会不同(如何选择见GC种类及如何选择)。本文将注重介绍JVM、GC的一些重要参数的设置来提高系统的性能。

GC性能方面的考虑

对于GC的性能主要有2个方面的指标：吞吐量throughput（工作时间不算gc的时间占总的时间比）和暂停pause（gc发生时app对外显示的无法响应）。

1. Total Heap

默认情况下，vm会增加/减少heap大小以维持free space在整个vm中占的比例，这个比例由MinHeapFreeRatio和MaxHeapFreeRatio指定。

一般而言，server端的app会有以下规则：

对vm分配尽可能多的memory；

将Xms和Xmx设为一样的值。如果虚拟机启动时设置使用的内存比较小，这个时候又需要初始化很多对象，虚拟机就必须重复地增加内存。

处理器核数增加，内存也跟着增大。

2. The Young Generation

另外一个对于app流畅性运行影响的因素是young generation的大小。young generation越大，minor collection越少；但是在固定heap size情况下，更大的young generation就意味着小的tenured generation，就意味着更多的major collection(major collection会引发minor collection)。

NewRatio反映的是young和tenured generation的大小比例。NewSize和MaxNewSize反映的是young generation大小的下限和上限，将这两个值设为一样就固定了young generation的大小（同Xms和Xmx设为一样）。

如果希望，SurvivorRatio也可以优化survivor的大小，不过这对于性能的影响不是很大。SurvivorRatio是eden和survior大小比例。

一般而言，server端的app会有以下规则：

首先决定能分配给vm的最大的heap size，然后设定最佳的young generation的大小；

如果heap size固定后，增加young generation的大小意味着减小tenured generation大小。让tenured generation在任何时候够大，能够容纳所有live的data（留10%-20%的空余）。

经验规则

年轻代大小选择

响应时间优先的应用:尽可能设大,直到接近系统的最低响应时间限制(根据实际情况选择).在此种情况下,年轻代收集发生的频率也是最小的.同时,减少到达年老代的对象.

吞吐量优先的应用:尽可能的设置大,可能到达Gbit的程度.因为对响应时间没有要求,垃圾收集可以并行进行,一般适合8CPU以上的应用.

避免设置过小.当新生代设置过小时会导致:1.YGC次数更加频繁 2.可能导致YGC对象直接进入旧生代,如果此时旧生代满了,会触发FGC.

年老代大小选择

响应时间优先的应用:年老代使用并发收集器,所以其大小需要小心设置,一般要考虑并发会话率和会话持续时间等一些参数.如果堆设置小了,可以会造成内存碎 片,高回收频率以及应用暂停而使用传统的标记清除方式;如果堆大了,则需要较长的收集时间.最优化的方案,一般需要参考以下数据获得:

并发垃圾收集信息、持久代并发收集次数、传统GC信息、花在年轻代和年老代回收上的时间比例。

吞吐量优先的应用:一般吞吐量优先的应用都有一个很大的年轻代和一个较小的年老代.原因是,这样可以尽可能回收掉大部分短期对象,减少中期的对象,而年老代尽存放长期存活对象.

较小堆引起的碎片问题

因为年老代的并发收集器使用标记,清除算法,所以不会对堆进行压缩.当收集器回收时,他会把相邻的空间进行合并,这样可以分配给较大的对象.但是,当堆空间较小时,运行一段时间以后,就会出现"碎片",如果并发收集器找不到足够的空间,那么并发收集器将会停止,然后使用传统的标记,清除方式进行回收.如果出现"碎片",可能需要进行如下配置:

-XX:+UseCMSCompactAtFullCollection:使用并发收集器时,开启对年老代的压缩.

-XX:CMSFullGCsBeforeCompaction=0:上面配置开启的情况下,这里设置多少次Full GC后,对年老代进行压缩

用64位操作系统，Linux下64位的jdk比32位jdk要慢一些，但是吃得内存更多，吞吐量更大

XMX和XMS设置一样大，MaxPermSize和MinPermSize设置一样大，这样可以减轻伸缩堆大小带来的压力

使用CMS的好处是用尽量少的新生代，经验值是128M－256M， 然后老生代利用CMS并行收集， 这样能保证系统低延迟的吞吐效率。 实际上cms的收集停顿时间非常的短，2G的内存， 大约20－80ms的应用程序停顿时间

系统停顿的时候可能是GC的问题也可能是程序的问题，多用jmap和jstack查看，或者killall -3 java，然后查看java控制台日志，能看出很多问题。(相关工具的使用方法将在后面的blog中介绍)

仔细了解自己的应用，如果用了缓存，那么年老代应该大一些，缓存的HashMap不应该无限制长，建议采用LRU算法的Map做缓存，LRUMap的最大长度也要根据实际情况设定。

采用并发回收时，年轻代小一点，年老代要大，因为年老大用的是并发回收，即使时间长点也不会影响其他程序继续运行，网站不会停顿

JVM参数的设置(特别是 –Xmx –Xms –Xmn -XX:SurvivorRatio -XX:MaxTenuringThreshold等参数的设置没有一个固定的公式，需要根据PV old区实际数据 YGC次数等多方面来衡量。为了避免promotion faild可能会导致xmn设置偏小，也意味着YGC的次数会增多，处理并发访问的能力下降等问题。每个参数的调整都需要经过详细的性能测试，才能找到特定应用的最佳配置。

promotion failed:

垃圾回收时promotion failed是个很头痛的问题，一般可能是两种原因产生，第一个原因是救助空间不够，救助空间里的对象还不应该被移动到年老代，但年轻代又有很多对象需要放入救助空间；第二个原因是年老代没有足够的空间接纳来自年轻代的对象；这两种情况都会转向Full GC，网站停顿时间较长。

解决方方案一：

第一个原因我的最终解决办法是去掉救助空间，设置-XX:SurvivorRatio=65536 -XX:MaxTenuringThreshold=0即可，第二个原因我的解决办法是设置CMSInitiatingOccupancyFraction为某个值（假设70），这样年老代空间到70%时就开始执行CMS，年老代有足够的空间接纳来自年轻代的对象。

解决方案一的改进方案：

又有改进了，上面方法不太好，因为没有用到救助空间，所以年老代容易满，CMS执行会比较频繁。我改善了一下，还是用救助空间，但是把救助空间加大，这样也不会有promotion failed。具体操作上，32位Linux和64位Linux好像不一样，64位系统似乎只要配置MaxTenuringThreshold参数，CMS还是有暂停。为了解决暂停问题和promotion failed问题，最后我设置-XX:SurvivorRatio=1 ，并把MaxTenuringThreshold去掉，这样即没有暂停又不会有promotoin failed，而且更重要的是，年老代和永久代上升非常慢（因为好多对象到不了年老代就被回收了），所以CMS执行频率非常低，好几个小时才执行一次，这样，服务器都不用重启了。

-Xmx4000M -Xms4000M -Xmn600M -XX:PermSize=500M -XX:MaxPermSize=500M -Xss256K -XX:+DisableExplicitGC -XX:SurvivorRatio=1 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=0 -XX:+CMSClassUnloadingEnabled -XX:LargePageSizeInBytes=128M -XX:+UseFastAccessorMethods -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=80 -XX:SoftRefLRUPolicyMSPerMB=0 -XX:+PrintClassHistogram -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC -Xloggc:log/gc.log

CMSInitiatingOccupancyFraction值与Xmn的关系公式

上面介绍了promontion faild产生的原因是EDEN空间不足的情况下将EDEN与From survivor中的存活对象存入To survivor区时,To survivor区的空间不足，再次晋升到old gen区，而old gen区内存也不够的情况下产生了promontion faild从而导致full gc.那可以推断出：eden+from survivor old gen区剩余内存时，不会出现promontion faild的情况，即：

(Xmx-Xmn)*(1-CMSInitiatingOccupancyFraction/100)=(Xmn-Xmn/(SurvivorRatior+2)) 进而推断出：

CMSInitiatingOccupancyFraction =((Xmx-Xmn)-(Xmn-Xmn/(SurvivorRatior+2)))/(Xmx-Xmn)*100

例如：

当xmx=128 xmn=36 SurvivorRatior=1时 CMSInitiatingOccupancyFraction=((128.0-36)-(36-36/(1+2)))/(128-36)*100 =73.913

当xmx=128 xmn=24 SurvivorRatior=1时 CMSInitiatingOccupancyFraction=((128.0-24)-(24-24/(1+2)))/(128-24)*100=84.615…

当xmx=3000 xmn=600 SurvivorRatior=1时 CMSInitiatingOccupancyFraction=((3000.0-600)-(600-600/(1+2)))/(3000-600)*100=83.33

CMSInitiatingOccupancyFraction低于70% 需要调整xmn或SurvivorRatior值。

java jvm内存可以设置多少

-Xmx Java Heap最大值,默认值为物理内存的1/4,最佳设值应该视物理内存大小及计算机内其他内存开销而定;

-Xms Java Heap初始值,Server端JVM最好将-Xms和-Xmx设为相同值,开发测试机JVM可以保留默认值;

-Xmn Java Heap Young区大小,不熟悉最好保留默认值; -Xss 每个线程的Stack大小,不熟悉最好保留默认值;

2

2. 如何分配JVM内存设置:

(1)当在命令提示符下启动并使用JVM时(只对当前运行的类Test生效): java -Xmx128m -Xms64m -Xmn32m -Xss16m Test (2)当在集成开发环境下(如eclipse)启动并使用JVM时:

a. 在eclipse根目录下打开eclipse.ini,默认内容为(这里设置的是运行当前开发工具的JVM内存分配): -vmargs -Xms40m -Xmx256m

-vmargs表示以下为虚拟机设置参数,可修改其中的参数值,也可添加-Xmn,-Xss,另外,eclipse.ini内还可以设置非堆内存,如:-XX:PermSize=56m,-XX:MaxPermSize=128m.

此处设置的参数值可以通过以下配置在开发工具的状态栏显示: 在eclipse根目录下创建文件options,文件内容为:org.eclipse.ui/perf/showHeapStatus=true

修改eclipse根目录下的eclipse.ini文件,在开头处添加如下内容: -debug options -vm javaw.exe

重新启动eclipse,就可以看到下方状态条多了JVM信息.

b. 打开eclipse-窗口-首选项-Java-已安装的JRE(对在当前开发环境中运行的java程序皆生效)

编辑当前使用的JRE,在缺省VM参数中输入:-Xmx128m -Xms64m -Xmn32m -Xss16m

c. 打开eclipse-运行-运行-Java应用程序(只对所设置的java类生效) 选定需设置内存分配的类-自变量,在VM自变量中输入:-Xmx128m -Xms64m

选定需设置内存分配的类-自变量,在VM自变量中输入:-Xmx128m -Xms64m -Xmn32m -Xss16m

注:如果在同一开发环境中同时进行了b和c设置,则b设置生效,c设置无效,如:

开发环境的设置为:-Xmx256m,而类Test的设置为:-Xmx128m -Xms64m,则运行Test时生效的设置为: -Xmx256m -Xms64m

(3)当在服务器环境下(如Tomcat)启动并使用JVM时(对当前服务器环境下所以Java程序生效): a. 设置环境变量: 变量名:CATALINA_OPTS

变量值:-Xmx128m -Xms64m -Xmn32m -Xss16m

3

b. 打开Tomcat根目录下的bin文件夹,编辑catalina.bat,将其中

的%CATALINA_OPTS%(共有四处)替换为:-Xmx128m -Xms64m -Xmn32m -Xss16m

如何设置Java虚拟机JVM启动内存参数

-Xmx Java Heap最大值，默认值为物理内存的1/4，最佳设值应该视物理内存大小及计算机内其他内存开销而定；

-Xms Java Heap初始值，Server端JVM最好将-Xms和-Xmx设为相同值，开发测试机JVM可以保留默认值；

-Xmn Java Heap Young区大小，不熟悉最好保留默认值；

-Xss 每个线程的Stack大小，不熟悉最好保留默认值；

2. 如何设置JVM内存分配：

（1）当在命令提示符下启动并使用JVM时（只对当前运行的类Test生效）：

java -Xmx128m -Xms64m -Xmn32m -Xss16m Test

（2）当在集成开发环境下（如eclipse）启动并使用JVM时：

a. 在eclipse根目录下打开eclipse.ini，默认内容为（这里设置的是运行当前开发工具的JVM内存分配）