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