Tomcat内存溢出的原因
在⽣产环境中tomcat内存设置不好很容易出现内存溢出。造成内存溢出是不⼀样的，当然处理⽅式也不⼀样。 这⾥根据平时遇到的情况和相关资料进⾏⼀个总结。常见的⼀般会有下⾯三种情况： 1.OutOfMemoryError： Java heap space 2.OutOfMemoryError： PermGen space
3.OutOfMemoryError： unable to create new native thread. Tomcat内存溢出解决⽅案
对于前两种情况，在应⽤本⾝没有内存泄露的情况下可以⽤设置tomcat jvm参数来解决。（-Xms -Xmx -XX：PermSize -XX：MaxPermSize） 最后⼀种可能需要调整操作系统和tomcat jvm参数同时调整才能达到⽬的。 第⼀种：是堆溢出。 原因分析：
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值。 没有内存泄露的情况下，调整-Xms -Xmx参数可以解决。 -Xms：初始堆⼤⼩ -Xmx：最⼤堆⼤⼩
但堆的⼤⼩受下⾯三⽅⾯影响：
1.相关操作系统的数据模型（32-bt还是64-bit）限制；（32位系统下，⼀般限制在1.5G~2G；我在2003 server 系统下（物理内存：4G和6G，jdk：1.6）测试1612M，64位操作系统对内存⽆限制。） 2.系统的可⽤虚拟内存限制； 3.系统的可⽤物理内存限制。
堆的⼤⼩可以使⽤ java -Xmx***M version 命令来测试。⽀持的话会出现jdk的版本号，不⽀持会报错。 -Xms -Xmx⼀般配置成⼀样⽐较好⽐如set JAVA_OPTS= -Xms1024m -Xmx1024m
其初始空间(即-Xms)是物理内存的1/64，最⼤空间(-Xmx)是物理内存的1/4。可以利⽤JVM提供的-Xmn -Xms -Xmx等选项可进⾏设置
实例，以下给出1G内存环境下java jvm 的参数设置参考：
JAVA_OPTS=\"-server -Xms800m -Xmx800m -XX:PermSize=64M -XX:MaxNewSize=256m -XX:MaxPermSize=128m -Djava.awt.headless=true \"JAVA_OPTS=\"-server -Xms768m -Xmx768m -XX:PermSize=128m -XX:MaxPermSize=256m -XX:NewSize=192m -XX:MaxNewSize=384m\"
CATALINA_OPTS=\"-server -Xms768m -Xmx768m -XX:PermSize=128m -XX:MaxPermSize=256m-XX:NewSize=192m -XX:MaxNewSize=384m\"
服务器为1G内存：JAVA_OPTS=\"-server -Xms800m -Xmx800m -XX:PermSize=64M -XX:MaxNewSize=256m -XX:MaxPermSize=128m -Djava.awt.headless=true\"
服务器为64位、2G内存: JAVA_OPTS='-server -Xms1024m -Xmx1536m -XX:PermSize=128M -XX:MaxNewSize=256m -XX:MaxPermSize=256m'
-------------------解决⽅案1：-----------------------------前提：是执⾏startup.bat启动tomcat的⽅式Linux服务器：
在/usr/local/apache-tomcat-5.5.23/bin ⽬录下的catalina.sh添加：JAVA_OPTS='-Xms512m -Xmx1024m'
或者 JAVA_OPTS=\"-server -Xms800m -Xmx800m -XX:MaxNewSize=256m\"或者 CATALINA_OPTS=\"-server -Xms256m -Xmx300m\"Windows服务器：
在catalina.bat最前⾯加⼊
set JAVA_OPTS=-Xms128m -Xmx350m
或者set CATALINA_OPTS=-Xmx300M -Xms256M
（区别是⼀个直接设置jvm内存， 另⼀个设置tomcat内存，CATALINA_OPTS似乎可以与JAVA_OPTS不加区别的使⽤）基本参数说明-client，-server
这两个参数⽤于设置虚拟机使⽤何种运⾏模式，⼀定要作为第⼀个参数，client模式启动⽐较快，但运⾏时性能和内存管理效率不如server模式，通常⽤于客户端应⽤程序。相反，server模式启动⽐client慢，但可获得更⾼的运⾏性能。
在windows上，缺省的虚拟机类型为client模式，如果要使⽤server模式，就需要在启动虚拟机时加-server参数，以获得更⾼性能，对服务器端应⽤，推荐采⽤server模式，尤其是多个CPU的系统。在Linux，Solaris上缺省采⽤server模式。 此外，在多cup下，建议⽤server模式
-Xms 设置虚拟机可⽤内存堆的初始⼤⼩，缺省单位为字节，该⼤⼩为1024的整数倍并且要⼤于1MB，可⽤k(K)或m(M)为单位来设置较⼤的内存数。初始堆⼤⼩为2MB。加“m”说明是MB，否则就是KB了。例如：-Xms6400K，-Xms256M-Xmx 设置虚拟机 的最⼤可⽤⼤⼩，缺省单位为字节。该值必须为1024整数倍，并且要⼤于2MB。可⽤k(K)或m(M)为单位来设置较⼤的内存数。缺省堆最⼤值为64MB。 例如：-Xmx81920K，-Xmx80M 当应⽤程序申请了⼤内存运⾏时虚拟机抛出java.lang.OutOfMemoryError: Java heap space错误，就需要使⽤-Xmx设置较⼤的可⽤内存堆。 PermSize/MaxPermSize：定义Perm段的尺⼨，即永久保存区域的⼤⼩，PermSize为JVM启动时初始化Perm的内存⼤⼩；MaxPermSize为最⼤可占⽤的Perm内存⼤⼩。在⽤户⽣产环境上⼀般将这两个值设为相同，以减少运⾏期间系统在内存申请上所花的开销。 如果⽤startup.bat启动tomcat,OK设置⽣效.够成功的分配200M内存.-------------------解决⽅案2：------------------------前提：是执⾏startup.bat启动tomcat的⽅式⼿动设置Heap sizeWindows服务器： 修改TOMCAT_HOME/bin/catalina.bat，在“echo \"Using CATALINA_BASE: $CATALINA_BASE\"”上⾯加⼊以下⾏：Java代码 set JAVA_OPTS=%JAVA_OPTS% -server -Xms800m -Xmx800m -XX:MaxNewSize=256m 注：JAVA_OPTS是保留先前设置。Linux服务器： 修改TOMCAT_HOME/bin/catalina.sh 在“echo \"Using CATALINA_BASE: $CATALINA_BASE\"”上⾯加⼊以下⾏： JAVA_OPTS=\"$JAVA_OPTS -server -Xms800m -Xmx800m -XX:MaxNewSize=256m\" 注：$JAVA_OPTS是保留先前设置。 -------------------解决⽅案3：-----------------------------前提：是执⾏windows的系统服务启动tomcat的⽅式 但是如果不是执⾏startup.bat启动tomcat⽽是利⽤windows的系统服务启动tomcat服务,上⾯的设置就不⽣效了,就是说set JAVA_OPTS=-Xms128m -Xmx350m 没起作⽤.上⾯分配200M内存就OOM了..windows服务执⾏的是bin\omcat.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服务,设置⽣效 -------------------解决⽅案4：-----------------------------前提：是执⾏windows的系统服务启动tomcat的⽅式在安装tomcat时若有勾选\"NT Service(NT/2000/XP only)\" 则安装完成后在安装⽬录的\"bin\"⽬录⾥会有⼀个tomcat.exe的档案先把tomcat的服务停掉 在命令列模式下（运⾏⾥输⼊CMD）将⽬录切换到tomcat的bin⽬录⽤下⾯的命令把服务移除 tomcat -uninstall \"Apache Tomcat 4.1\" 接下来，写个批处理。内容如下 set SERVICENAME=Apache Tomcat 4.1set CATALINA_HOME=E:\\Tomcat 4.1.24set CLASSPATH=D:\\j2sdk1.4.1_01\\libset JAVACLASSPATH=%CLASSPATH% set JAVACLASSPATH=%JAVACLASSPATH%;�TALINA_HOME%\\bin\\bootstrap.jar set JAVACLASSPATH=%JAVACLASSPATH%;�TALINA_HOME%\\common\\lib\\servlet.jarset JAVACLASSPATH=%JAVACLASSPATH%;%JAVA_HOME%\\lib\ools.jar tomcat.exe -install \"%SERVICENAME%\" \"%JAVA_HOME%\\jre\\bin\\server\\jvm.dll\" -Djava.class.path=\"%JAVACLASSPATH%\" -Dcatalina.home=\"�TALINA_HOME%\" -Xms512m -Xmx768m -start org.apache.catalina.startup.Bootstrap -params start -stop org.apache.catalina.startup.Bootstrap -params stop -out \"�TALINA_HOME%\\logs\\stdout.log\" -err \"�TALINA_HOME%\\logs\\stderr.log\" 注意，从 tomcat.exe -install开始的是最后⼀⾏！不要⼿⼯回车换⾏把这⼀⾏分成了好⼏段。保存后在命令⾏下执⾏这个bat⽂件，注意执⾏的时候将“服务”窗⼝关闭。 第⼆种：永久保存区域溢出 原因分析： 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)那么就会产⽣此错误信息了。但⽬前的hibernate和spring项⽬中也很容易出现这样的问题。可能是由于这些框架会动态class，⽽且jvm的gc是不会清理PemGen space的，超过了jvm默认的⼤⼩(4M)，导致内存溢出。 建议：将相同的第三⽅jar⽂件移置到tomcat/shared/lib⽬录下，这样可以达到减少jar ⽂档重复占⽤内存的⽬的。这⼀个⼀般是加⼤-XX：PermSize -XX：MaxPermSize 来解决问题。 -XX：PermSize 永久保存区域初始⼤⼩ -XX：PermSize 永久保存区域初始最⼤值 这⼀般结合第⼀条使⽤，⽐如 set JAVA_OPTS= -Xms1024m -Xmx1024m -XX：PermSize=128M -XX：PermSize=256M 有⼀点需要注意：java -Xmx***M version 命令来测试的最⼤堆内存是 -Xmx与 -XX：PermSize的和 ⽐如系统⽀持最⼤的jvm堆⼤⼩事1.5G，那 -Xmx1024m -XX：PermSize=768M 是⽆法运⾏的。-----------------解决⽅案1：-------------------------Linux服务器： 在catalina.sh的第⼀⾏增加：JAVA_OPTS=-Xms64m-Xmx256m -XX:PermSize=128M-XX:MaxNewSize=256m-XX:MaxPermSize=256m或者 在“echo \"Using CATALINA_BASE: $CATALINA_BASE\"”上⾯加⼊以下⾏：JAVA_OPTS=\"-server -XX:PermSize=64M -XX:MaxPermSize=128mWindows服务器： 在catalina.bat的第⼀⾏增加： set JAVA_OPTS=-Xms64m -Xmx256m -XX:PermSize=128M -XX:MaxNewSize=256m -XX:MaxPermSize=256m -----------------解决⽅案2：------------------------修改TOMCAT_HOME/bin/catalina.bat（Linux下为catalina.sh），在Java代码“echo \"Using CATALINA_BASE: $CATALINA_BASE\"”上⾯加⼊以下⾏： set JAVA_OPTS=%JAVA_OPTS% -server -XX:PermSize=128M -XX:MaxPermSize=512m “echo \"Using CATALINA_BASE: $CATALINA_BASE\"”上⾯加⼊以下⾏： set JAVA_OPTS=%JAVA_OPTS% -server -XX:PermSize=128M -XX:MaxPermSize=512mcatalina.sh下为：Java代码 JAVA_OPTS=\"$JAVA_OPTS -server -XX:PermSize=128M -XX:MaxPermSize=512m\" JAVA_OPTS=\"$JAVA_OPTS -server -XX:PermSize=128M -XX:MaxPermSize=512m\" 第三种：⽆法创建新的线程。 这种现象⽐较少见，也⽐较奇怪，主要是和jvm与系统内存的⽐例有关。 这种怪事是因为JVM已经被系统分配了⼤量的内存（⽐如1.5G），并且它⾄少要占⽤可⽤内存的⼀半。有⼈发现，在线程个数很多的情况下，你分配给JVM的内存越多，那么，上述错误发⽣的可能性就越⼤。 原因分析 （从这个blog中了解到原因：）：中了解到原因：）： 每⼀个32位的进程最多可以使⽤2G的可⽤内存，因为另外2G被操作系统保留。这⾥假设使⽤1.5G给JVM，那么还余下500M可⽤内存。这500M内存中的⼀部分必须⽤于系统dll的加载，那么真正剩下的也许只有400M，现在关键的地⽅出现了：当你使⽤Java创建⼀个线程，在JVM的内存⾥也会创建⼀个Thread对象，但是同时也会在操作系统⾥创建⼀个真正的物理线程（参考JVM规范），操作系统会在余下的 400兆内存⾥创建这个物理线程，⽽不是在JVM的1500M的内存堆⾥创建。在jdk1.4⾥头，默认的栈⼤⼩是256KB，但是在jdk1.5⾥头，默认的栈⼤⼩为1M每线程，因此，在余下400M的可⽤内存⾥边我们最多也只能创建400个可⽤线程。 这样结论就出来了，要想创建更多的线程，你必须减少分配给JVM的最⼤内存。还有⼀种做法是让JVM宿主在你的JNI代码⾥边。 给出⼀个有关能够创建线程的最⼤个数的估算公式： （MaxProcessMemory - JVMMemory - ReservedOsMemory） / （ThreadStackSize） = Number of threads 对于jdk1.5⽽⾔，假设操作系统保留120M内存： 1.5GB JVM： （2GB-1.5Gb-120MB）/（1MB） = ~380 threads 1.0GB JVM： （2GB-1.0Gb-120MB）/（1MB） = ~880 threads 在2000/XP/2003的boot.ini⾥头有⼀个启动选项，好像是：/PAE /3G ，可以让⽤户进程最⼤内存扩充⾄3G，这时操作系统只能占⽤最多1G的虚存。那样应该可以让JVM创建更多的线程。 因此这种情况需要结合操作系统进⾏相关调整。 因此：我们需要结合不同情况对tomcat内存分配进⾏不同的诊断才能从根本上解决问题。 检测当前JVM内存使⽤情况： System.out.println(\"JVM MAX MEMORY: \" + Runtime.getRuntime().maxMemory()/1024/1024+\"M\"); System.out.println(\"JVM IS USING MEMORY:\" + Runtime.getRuntime().totalMemory()/1024/1024+\"M\");System.out.println(\"JVM IS FREE MEMORY:\" + Runtime.getRuntime().freeMemory()/1024/1024+\"M\"); 这三个⽅法都是说JVM的内存使⽤情况⽽不是操作系统的内存； maxMemory()这个⽅法返回的是java虚拟机（这个进程）能构从操作系统那⾥挖到的最⼤的内存，以字节为单位，如果在运⾏java程序的时候，没有添加-Xmx参数，那么就是64兆，也就是说maxMemory()返回的⼤约是64*1024*1024字节，这是java虚拟机默认情况下能从操作系统那⾥挖到的最⼤的内存。如果添加了-Xmx参数，将以这个参数后⾯的值为准，例如java -cp ClassPath -Xmx512m ClassName，那么最⼤内存就是512*1024*0124字节。 totalMemory()这个⽅法返回的是java虚拟机现在已经从操作系统那⾥挖过来的内存⼤⼩，也就是java虚拟机这个进程当时所占⽤的所有内存。如果在运⾏java的时候没有添加-Xms参数，那么，在java程序运⾏的过程的，内存总是慢慢的从操作系统那⾥挖的，基本上是⽤多少挖多少，直挖到maxMemory()为⽌，所以totalMemory()是慢慢增⼤的。如果⽤了-Xms参数，程序在启动的时候就会⽆条件的从操作系统中挖-Xms后⾯定义的内存数，然后在这些内存⽤的差不多的时候，再去挖。 freeMemory()是什么呢，刚才讲到如果在运⾏java的时候没有添加-Xms参数，那么，在java程序运⾏的过程的，内存总是慢慢的从操作系统那⾥挖的，基本上是⽤多少挖多少，但是java虚拟机100％的情况下是会稍微多挖⼀点的，这些挖过来⽽⼜没有⽤上的内存，实际上就是freeMemory()，所以freeMemory()的值⼀般情况下都是很⼩的，但是如果你在运⾏java程序的时候使⽤了-Xms，这个时候因为程序在启动的时候就会⽆条件的从操作系统中挖-Xms后⾯定义的内存数，这个时候，挖过来的内存可能⼤部分没⽤上，所以这个时候freeMemory()可能会有些--------------------解决⽅案--------------------------JVM堆⼤⼩的调整 Sun HotSpot 1.4.1使⽤分代收集器，它把堆分为三个主要的域：新域、旧域以及永久域。Jvm⽣成的所有新对象放在新域中。⼀旦对象经历了⼀定数量的垃圾收集循环后，便获得使⽤期并进⼊旧域。在永久域中jvm则存储class和method对象。就配置⽽⾔，永久域是⼀个独⽴域并且不认为是堆的⼀部分。 下⾯介绍如何控制这些域的⼤⼩。可使⽤-Xms和-Xmx 控制整个堆的原始⼤⼩或最⼤值。 下⾯的命令是把初始⼤⼩设置为128M： java –Xms128m –Xmx256m为控制新域的⼤⼩，可使⽤-XX:NewRatio设置新域在堆中所占的⽐例。 下⾯的命令把整个堆设置成128m，新域⽐率设置成3，即新域与旧域⽐例为1：3，新域为堆的1/4或32M：java –Xms128m –Xmx128m –XX:NewRatio =3可使⽤-XX:NewSize和-XX:MaxNewsize设置新域的初始值和最⼤值。 下⾯的命令把新域的初始值和最⼤值设置成64m:java –Xms256m –Xmx256m –Xmn64m 永久域默认⼤⼩为4m。运⾏程序时，jvm会调整永久域的⼤⼩以满⾜需要。每次调整时，jvm会对堆进⾏⼀次完全的垃圾收集。 使⽤-XX:MaxPerSize标志来增加永久域搭⼤⼩。在WebLogic Server应⽤程序加载较多类时，经常需要增加永久域的最⼤值。当jvm加载类时，永久域中的对象急剧增加，从⽽使jvm不断调整永久域⼤⼩。为了避免调整，可使⽤-XX:PerSize标志设置初始值。 下⾯把永久域初始值设置成32m，最⼤值设置成64m。 java -Xms512m -Xmx512m -Xmn128m -XX:PermSize=32m -XX:MaxPermSize=64m 默认状态下，HotSpot在新域中使⽤复制收集器。该域⼀般分为三个部分。第⼀部分为Eden，⽤于⽣成新的对象。另两部分称为救助空间，当Eden充满时，收集器停⽌应⽤程序，把所有可到达对象复制到当前的from救助空间，⼀旦当前的from救助空间充满，收集器则把可到达对象复制到当前的to救助空间。From和to救助空间互换⾓⾊。维持活动的对象将在救助空间不断复制，直到它们获得使⽤期并转⼊旧域。使⽤-XX:SurvivorRatio可控制新域⼦空间的⼤⼩。 同NewRation⼀样，SurvivorRation规定某救助域与Eden空间的⽐值。⽐如，以下命令把新域设置成64m，Eden占32m，每个救助域各占16m：java -Xms256m -Xmx256m -Xmn64m -XX:SurvivorRation =2 如前所述，默认状态下HotSpot对新域使⽤复制收集器，对旧域使⽤标记－清除－压缩收集器。在新域中使⽤复制收集器有很多意义，因为应⽤程序⽣成的⼤部分对象是短寿命的。理想状态下，所有过渡对象在移出Eden空间时将被收集。如果能够这样的话，并且移出Eden空间的对象是长寿命的，那么理论上可以⽴即把它们移进旧域，避免在救助空间反复复制。但是，应⽤程序不能适合这种理想状态，因为它们有⼀⼩部分中长寿命的对象。最好是保持这些中长寿命的对象并放在新域中，因为复制⼩部分的对象总⽐压缩旧域廉价。为控制新域中对象的复制，可⽤-XX:TargetSurvivorRatio控制救助空间的⽐例（该值是设置救助空间的使⽤⽐例。如救助空间位1M，该值50表⽰可⽤500K）。该值是⼀个百分⽐，默认值是50。当较⼤的堆栈使⽤较低的sruvivorratio时，应增加该值到80⾄90，以更好利⽤救助空间。⽤-XX:maxtenuring threshold可控制上限。 为放置所有的复制全部发⽣以及希望对象从eden扩展到旧域，可以把MaxTenuring Threshold设置成0。设置完成后，实际上就不再使⽤救助空间了，因此应把SurvivorRatio设成最⼤值以最⼤化Eden空间，设置如下： java … -XX:MaxTenuringThreshold=0 –XX:SurvivorRatio＝50000 …垃圾回收描述： 垃圾回收分多级，0级为全部(Full)的垃圾回收，会回收OLD段中的垃圾；1级或以上为部分垃圾回收，只会回收Young中的垃圾，内存溢出通常发⽣于OLD段或Perm段垃圾回收后，仍然⽆内存空间容纳新的Java对象的情况。当⼀个URL被访问时，内存申请过程如下： A. JVM会试图为相关Java对象在Eden中初始化⼀块内存区域B. 当Eden空间⾜够时，内存申请结束。否则到下⼀步 C. JVM试图释放在Eden中所有不活跃的对象（这属于1或更⾼级的垃圾回收）；释放后若Eden空间仍然不⾜以放⼊新对象，则试图将部分Eden中活跃对象放⼊Survivor区/OLD区 D. Survivor区被⽤来作为Eden及OLD的中间交换区域，当OLD区空间⾜够时，Survivor区的对象会被移到Old区，否则会被保留在Survivor区E. 当OLD区空间不够时，JVM会在OLD区进⾏完全的垃圾收集（0级） F. 完全垃圾收集后，若Survivor及OLD区仍然⽆法存放从Eden复制过来的部分对象，导致JVM⽆法在Eden区为新对象创建内存区域，则出现”out of memory错误” Java堆相关参数： ms/mx：定义YOUNG+OLD段的总尺⼨，ms为JVM启动时YOUNG+OLD的内存⼤⼩；mx为最⼤可占⽤的YOUNG+OLD内存⼤⼩。在⽤户⽣产环境上⼀般将这两个值设为相同，以减少运⾏期间系统在内存申请上所花的开销。 NewSize/MaxNewSize：定义YOUNG段的尺⼨，NewSize为JVM启动时YOUNG的内存⼤⼩；MaxNewSize为最⼤可占⽤的YOUNG内存⼤⼩。在⽤户⽣产环境上⼀般将这两个值设为相同，以减少运⾏期间系统在内存申请上所花的开销。 PermSize/MaxPermSize：定义Perm段的尺⼨，PermSize为JVM启动时Perm的内存⼤⼩；MaxPermSize为最⼤可占⽤的Perm内存⼤⼩。在⽤户⽣产环境上⼀般将这两个值设为相同，以减少运⾏期间系统在内存申请上所花的开销。SurvivorRatio：设置Survivor空间和Eden空间的⽐例例： MEM_ARGS=\"-Xms512m -Xmx512m -XX:NewSize=256m -XX:MaxNewSize=256m -XX:PermSize=128m -XX:MaxPermSize=128m -XX:SurvivorRatio=6\"在上⾯的例⼦中：YOUNG+OLD: 512MYOUNG: 256MPerm: 128M Eden: YOUNG*6/(6+1+1)=192MSurvivor: YOUNG/(6+1+1)=32M Java堆的总尺⼨=YOUNG+OLD+Perm=640M 因篇幅问题不能全部显示，请点此查看更多更全内容