java JVM虚拟机选项 Xms Xmx PermSize MaxPermSize 的区别

Eclipse崩溃，错误提示：
MyEclipse has detected that less than 5% of the 64MB of Perm 
Gen (Non-heap memory) space remains. It is strongly recommended
that you exit and restart MyEclipse with new virtual machine memory
paramters to increase this memory.   Failure to do so can result in
data loss. The recommended Eclipse memory parameters are: 
eclipse.exe -vmargs -Xms128M -Xmx512M -XX:PermSize=64M -XX:MaxPermSize=128M

1.参数的含义

-vmargs -Xms128M -Xmx512M -XX:PermSize=64M -XX:MaxPermSize=128M
-vmargs 说明后面是VM的参数，因此后面的其实都是JVM的参数了
-Xms128m JVM初始分配的堆内存
-Xmx512m JVM最大容许分配的堆内存，按需分配
-XX:PermSize=64M JVM初始分配的非堆内存
-XX:MaxPermSize=128M JVM最大容许分配的非堆内存，按需分配

咱们首先了解一下JVM内存管理的机制，而后再解释每一个参数表明的含义。

1)堆(Heap)和非堆(Non-heap)内存

 按照官方的说法：“Java 虚拟机具备一个堆，堆是运行时数据区域，全部类实例和数组的内存均今后处分配。堆是在 Java 虚拟机启动时建立的。”“在JVM中堆以外的内存称为非堆内存(Non-heap memory)”。
 能够看出JVM主要管理两种类型的内存：堆和非堆。简单来讲堆就是Java代码可及的内存，是留给开发人员使用的；非堆就是JVM留给本身用的，
 因此方法区、JVM内部处理或优化所需的内存(如JIT编译后的代码缓存)、每一个类结构(如运行时常数池、字段和方法数据)以及方法和构造方法的代码都在非堆内存中。 

堆内存分配

 JVM初始分配的堆内存由-Xms指定，默认是物理内存的1/64；JVM最大分配的堆内存由-Xmx指定，默认是物理内存的1/4。默认空余堆内存小于40%时，JVM就会增大堆直到-Xmx的最大限制；
 空余堆内存大于70%时，JVM会减小堆直到-Xms的最小限制。所以服务器通常设置-Xms、-Xmx 相等以免在每次GC 后调整堆的大小。
 说明：若是-Xmx 不指定或者指定偏小，应用可能会致使java.lang.OutOfMemory错误，此错误来自JVM，不是Throwable的，没法用try...catch捕捉。 

非堆内存分配

 JVM使用-XX:PermSize设置非堆内存初始值，默认是物理内存的1/64；由XX:MaxPermSize设置最大非堆内存的大小，默认是物理内存的1/4。（还有一说：MaxPermSize缺省值和-server -client选项相关，
 -server选项下默认MaxPermSize为64m，-client选项下默认MaxPermSize为32m。这个我没有实验。）
 上面错误信息中的PermGen space的全称是Permanent Generation space，是指内存的永久保存区域。尚未弄明白PermGen space是属于非堆内存，仍是就是非堆内存，但至少是属于了。
XX:MaxPermSize设置太小会致使java.lang.OutOfMemoryError: PermGen space 就是内存益出。 PermSize和MaxPermSize指明虚拟机为java永久生成对象（Permanate generation）如，class对象、方法对象这些可反射（reflective）对象分配内存限制，这些内存不包括在Heap（堆内存）区之中。
说说为何会内存益出： 
（1）这一部份内存用于存放Class和Meta的信息，Class在被 Load的时候被放入PermGen space区域，它和存放Instance的Heap区域不一样。 
（2）GC(Garbage Collection)不会在主程序运行期对PermGen space进行清理，因此若是你的APP会LOAD不少CLASS 的话,就极可能出现PermGen space错误。
  这种错误常见在web服务器对JSP进行pre compile的时候。  

2)JVM内存限制(最大值)

1.首先JVM内存限制于实际的最大物理内存，假设物理内存无限大的话，JVM内存的最大值跟操做系统有很大的关系。简单的说就32位处理器虽然可控内存空间有4GB,可是具体的操做系统会给一个限制，
 这个限制通常是2GB-3GB（通常来讲Windows系统下为1.5G-2G，Linux系统下为2G-3G），而64bit以上的处理器就不会有限制了。

2. 为何有的机器我将-Xmx和-XX:MaxPermSize都设置为512M以后Eclipse能够启动，而有些机器没法启动？
 经过上面对JVM内存管理的介绍咱们已经了解到JVM内存包含两种：堆内存和非堆内存，另外JVM最大内存首先取决于实际的物理内存和操做系统。因此说设置VM参数致使程序没法启动主要有如下几种缘由：
1) 参数中-Xms的值大于-Xmx，或者-XX:PermSize的值大于-XX:MaxPermSize；
2) -Xmx的值和-XX:MaxPermSize的总和超过了JVM内存的最大限制，好比当前操做系统最大内存限制，或者实际的物理内存等等。说到实际物理内存这里须要说明一点的是，
 若是你的内存是1024MB，但实际系统中用到的并不多是1024MB，由于有一部分被硬件占用了。

3. 为什么将上面的参数写入到eclipse.ini文件Eclipse没有执行对应的设置？
 那为何一样的参数在快捷方式或者命令行中有效而在eclipse.ini文件中是无效的呢？这是由于咱们没有遵照eclipse.ini文件的设置规则：
参数形如“项 值”这种形式，中间有空格的须要换行书写，若是值中有空格的须要用双引号包括起来。好比咱们使用-vm C:/Java/jre1.6.0/bin/javaw.exe参数设置虚拟机，
在eclipse.ini文件中要写成这样：
-vm 
C:/Java/jre1.6.0/bin/javaw.exe 
-vmargs 
-Xms128M 
-Xmx512M 
-XX:PermSize=64M 
-XX:MaxPermSize=128M 
实际运行的结果能够经过Eclipse中“Help”-“About Eclipse SDK”窗口里面的“Configuration Details”按钮进行查看。
另外须要说明的是，Eclipse压缩包中自带的eclipse.ini文件内容是这样的：
-showsplash 
org.eclipse.platform 
--launcher.XXMaxPermSize 
256m 
-vmargs 
-Xms40m 
-Xmx256m 
其中–launcher.XXMaxPermSize（注意最前面是两个链接线）跟-XX:MaxPermSize参数的含义基本是同样的，我以为惟一的区别就是前者是eclipse.exe启动的时候设置的参数，
然后者是eclipse所使用的JVM中的参数。其实两者设置一个就能够了，因此这里能够把–launcher.XXMaxPermSize和下一行使用#注释掉。

4. 其余的启动参数。 若是你有一个双核的CPU，也许能够尝试这个参数:
-XX:+UseParallelGC
让GC能够更快的执行。（只是JDK 5里对GC新增长的参数）

补充：
　　若是你的WEB APP下都用了大量的第三方jar，其大小超过了服务器jvm默认的大小，那么就会产生内存益出问题了。
解决方法： 设置MaxPermSize大小 
能够在myelipse里选中相应的服务器好比tomcat5，展开里面的JDK子项页面，来增长服务器启动的JVM参数设置：
-Xms128m 
-Xmx256m 
-XX:PermSize=128M 
-XX:MaxNewSize=256m 
-XX:MaxPermSize=256m
或者手动设置MaxPermSize大小,好比tomcat，
修改TOMCAT_HOME/bin/catalina.bat，在echo "Using CATALINA_BASE: $CATALINA_BASE"上面加入如下行： 
JAVA_OPTS="-server -XX:PermSize=64M -XX:MaxPermSize=128m

建议：

一、将相同的第三方jar文件移置到tomcat/shared/lib目录下，这样能够减小jar 文档重复占用内存

二、慎用最小限制选项Xms,PermSize以节约系统资源。

REF：

关于诡异的堆内存占用很小，但整个 jvm 却耗费了大量的内存：

native heap是不属于JVM堆直接管理的，可是产生natvie heap对象的引用类又出如今JVM的heap中，而且长期得不到gc处理。Sun JVM  GC的标准针对的是Java Heap，而在同事出现的那个场景里，Java Heap占用很少一直没有到GC边界，所以GC好久才会运行一次，致使出现了大量的Native Heap被占用而GC却不运行。

附：一些JVM参数设置、分析

参数名称	含义	默认值
-Xms	初始堆大小	物理内存的1/64(<1GB)	默认(MinHeapFreeRatio参数能够调整)空余堆内存小于40%时，JVM就会增大堆直到-Xmx的最大限制.
-Xmx	最大堆大小	物理内存的1/4(<1GB)	默认(MaxHeapFreeRatio参数能够调整)空余堆内存大于70%时，JVM会减小堆直到 -Xms的最小限制
-Xmn	年轻代大小(1.4or lator)		注意：此处的大小是（eden+ 2 survivor space).与jmap -heap中显示的New gen是不一样的。 整个堆大小=年轻代大小 + 年老代大小 + 持久代大小. 增大年轻代后,将会减少年老代大小.此值对系统性能影响较大,Sun官方推荐配置为整个堆的3/8
-XX:NewSize	设置年轻代大小(for 1.3/1.4)
-XX:MaxNewSize	年轻代最大值(for 1.3/1.4)
-XX:PermSize	设置持久代(perm gen)初始值	物理内存的1/64
-XX:MaxPermSize	设置持久代最大值	物理内存的1/4
-Xss	每一个线程的堆栈大小		JDK5.0之后每一个线程堆栈大小为1M,之前每一个线程堆栈大小为256K.更具应用的线程所需内存大小进行 调整.在相同物理内存下,减少这个值能生成更多的线程.可是操做系统对一个进程内的线程数仍是有限制的,不能无限生成,经验值在3000~5000左右 通常小的应用， 若是栈不是很深， 应该是128k够用的 大的应用建议使用256k。这个选项对性能影响比较大，须要严格的测试。（校长） 和threadstacksize选项解释很相似,官方文档彷佛没有解释,在论坛中有这样一句话:"” -Xss is translated in a VM flag named ThreadStackSize” 通常设置这个值就能够了。
-XX:ThreadStackSize	Thread Stack Size		(0 means use default stack size) [Sparc: 512; Solaris x86: 320 (was 256 prior in 5.0 and earlier); Sparc 64 bit: 1024; Linux amd64: 1024 (was 0 in 5.0 and earlier); all others 0.]
-XX:NewRatio	年轻代(包括Eden和两个Survivor区)与年老代的比值(除去持久代)		-XX:NewRatio=4表示年轻代与年老代所占比值为1:4,年轻代占整个堆栈的1/5 Xms=Xmx而且设置了Xmn的状况下，该参数不须要进行设置。
-XX:SurvivorRatio	Eden区与Survivor区的大小比值		设置为8,则两个Survivor区与一个Eden区的比值为2:8,一个Survivor区占整个年轻代的1/10
-XX:LargePageSizeInBytes	内存页的大小不可设置过大， 会影响Perm的大小		=128m
-XX:+UseFastAccessorMethods	原始类型的快速优化
-XX:+DisableExplicitGC	关闭System.gc()		这个参数须要严格的测试
-XX:MaxTenuringThreshold	垃圾最大年龄		若是设置为0的话,则年轻代对象不通过Survivor区,直接进入年老代. 对于年老代比较多的应用,能够提升效率.若是将此值设置为一个较大值,则年轻代对象会在Survivor区进行屡次复制,这样能够增长对象再年轻代的存活 时间,增长在年轻代即被回收的几率 该参数只有在串行GC时才有效.
-XX:+AggressiveOpts	加快编译
-XX:+UseBiasedLocking	锁机制的性能改善
-Xnoclassgc	禁用垃圾回收
-XX:SoftRefLRUPolicyMSPerMB	每兆堆空闲空间中SoftReference的存活时间	1s	softly reachable objects will remain alive for some amount of time after the last time they were referenced. The default value is one second of lifetime per free megabyte in the heap
-XX:PretenureSizeThreshold	对象超过多大是直接在旧生代分配	0	单位字节 新生代采用Parallel Scavenge GC时无效 另外一种直接在旧生代分配的状况是大的数组对象,且数组中无外部引用对象.
-XX:TLABWasteTargetPercent	TLAB占eden区的百分比	1%
-XX:+CollectGen0First	FullGC时是否先YGC	false

并行收集器相关参数

-XX:+UseParallelGC	Full GC采用parallel MSC (此项待验证)		选择垃圾收集器为并行收集器.此配置仅对年轻代有效.即上述配置下,年轻代使用并发收集,而年老代仍旧使用串行收集.(此项待验证)
-XX:+UseParNewGC	设置年轻代为并行收集		可与CMS收集同时使用 JDK5.0以上,JVM会根据系统配置自行设置,因此无需再设置此值
-XX:ParallelGCThreads	并行收集器的线程数		此值最好配置与处理器数目相等 一样适用于CMS
-XX:+UseParallelOldGC	年老代垃圾收集方式为并行收集(Parallel Compacting)		这个是JAVA 6出现的参数选项
-XX:MaxGCPauseMillis	每次年轻代垃圾回收的最长时间(最大暂停时间)		若是没法知足此时间,JVM会自动调全年轻代大小,以知足此值.
-XX:+UseAdaptiveSizePolicy	自动选择年轻代区大小和相应的Survivor区比例		设置此选项后,并行收集器会自动选择年轻代区大小和相应的Survivor区比例,以达到目标系统规定的最低相应时间或者收集频率等,此值建议使用并行收集器时,一直打开.
-XX:GCTimeRatio	设置垃圾回收时间占程序运行时间的百分比		公式为1/(1+n)
-XX:+ScavengeBeforeFullGC	Full GC前调用YGC	true	Do young generation GC prior to a full GC. (Introduced in 1.4.1.)

CMS相关参数

-XX:+UseConcMarkSweepGC	使用CMS内存收集		测试中配置这个之后,-XX:NewRatio=4的配置失效了,缘由不明.因此,此时年轻代大小最好用-Xmn设置.???
-XX:+AggressiveHeap			试图是使用大量的物理内存 长时间大内存使用的优化，能检查计算资源（内存， 处理器数量） 至少须要256MB内存 大量的CPU／内存， （在1.4.1在4CPU的机器上已经显示有提高）
-XX:CMSFullGCsBeforeCompaction	多少次后进行内存压缩		因为并发收集器不对内存空间进行压缩,整理,因此运行一段时间之后会产生"碎片",使得运行效率下降.此值设置运行多少次GC之后对内存空间进行压缩,整理.
-XX:+CMSParallelRemarkEnabled	下降标记停顿
-XX+UseCMSCompactAtFullCollection	在FULL GC的时候， 对年老代的压缩		CMS是不会移动内存的， 所以， 这个很是容易产生碎片， 致使内存不够用， 所以， 内存的压缩这个时候就会被启用。 增长这个参数是个好习惯。 可能会影响性能,可是能够消除碎片
-XX:+UseCMSInitiatingOccupancyOnly	使用手动定义初始化定义开始CMS收集		禁止hostspot自行触发CMS GC
-XX:CMSInitiatingOccupancyFraction=70	使用cms做为垃圾回收 使用70％后开始CMS收集	92	为了保证不出现promotion failed(见下面介绍)错误,该值的设置须要知足如下公式CMSInitiatingOccupancyFraction计算公式
-XX:CMSInitiatingPermOccupancyFraction	设置Perm Gen使用到达多少比率时触发	92
-XX:+CMSIncrementalMode	设置为增量模式		用于单CPU状况
-XX:+CMSClassUnloadingEnabled

辅助信息

-XX:+PrintGC			输出形式: [GC 118250K->113543K(130112K), 0.0094143 secs] [Full GC 121376K->10414K(130112K), 0.0650971 secs]
-XX:+PrintGCDetails			输出形式:[GC [DefNew: 8614K->781K(9088K), 0.0123035 secs] 118250K->113543K(130112K), 0.0124633 secs] [GC [DefNew: 8614K->8614K(9088K), 0.0000665 secs][Tenured: 112761K->10414K(121024K), 0.0433488 secs] 121376K->10414K(130112K), 0.0436268 secs]
-XX:+PrintGCTimeStamps
-XX:+PrintGC:PrintGCTimeStamps			可与-XX:+PrintGC -XX:+PrintGCDetails混合使用 输出形式:11.851: [GC 98328K->93620K(130112K), 0.0082960 secs]
-XX:+PrintGCApplicationStoppedTime	打印垃圾回收期间程序暂停的时间.可与上面混合使用		输出形式:Total time for which application threads were stopped: 0.0468229 seconds
-XX:+PrintGCApplicationConcurrentTime	打印每次垃圾回收前,程序未中断的执行时间.可与上面混合使用		输出形式:Application time: 0.5291524 seconds
-XX:+PrintHeapAtGC	打印GC先后的详细堆栈信息
-Xloggc:filename	把相关日志信息记录到文件以便分析. 与上面几个配合使用
-XX:+PrintClassHistogram	garbage collects before printing the histogram.
-XX:+PrintTLAB	查看TLAB空间的使用状况
XX:+PrintTenuringDistribution	查看每次minor GC后新的存活周期的阈值		Desired survivor size 1048576 bytes, new threshold 7 (max 15) new threshold 7即标识新的存活周期的阈值为7。

行为参数：参考：JAVA启动参数大全之三：非Stable参数

参数及其默认值	描述
-XX:-DisableExplicitGC	禁止调用System.gc()；但jvm的gc仍然有效
-XX:+MaxFDLimit	最大化文件描述符的数量限制
-XX:+ScavengeBeforeFullGC	新生代GC优先于Full GC执行
-XX:+UseGCOverheadLimit	在抛出OOM以前限制jvm耗费在GC上的时间比例
-XX:-UseConcMarkSweepGC	对老生代采用并发标记交换算法进行GC
-XX:-UseParallelGC	启用并行GC
-XX:-UseParallelOldGC	对Full GC启用并行，当-XX:-UseParallelGC启用时该项自动启用
-XX:-UseSerialGC	启用串行GC
-XX:+UseThreadPriorities	启用本地线程优先级

推荐阅读：

JVM调优-解决native heap持续增加

http://sw1982.iteye.com/blog/724626

JNI——当心，内存怪兽出没

http://ayufox.iteye.com/blog/723896

JVM系列三:JVM参数设置、分析

http://www.cnblogs.com/redcreen/archive/2011/05/04/2037057.html

解码OutOfMemoryError：PermGen Space

http://www.importnew.com/8133.html

对页游《小兵大战》服务器 Direct Memory 内存溢出的排错过程总结

http://blog.csdn.net/jiangguilong2000/article/details/9282693