Herry灬凌夜 轉自：https://www.cnblogs.com/wuyx/p/9627542.html

常用的JVM配置參數

一、Trace 跟蹤參數

　　在Eclipse中，如何打開GC的監控日志
　　　　選擇菜單欄Run -> Run Configurations -> Java Application -> 選擇自己的項目 -> 在右側找到Arguments選項卡 -> 在VM arguments中填寫參數，具體參數在下面會有說明。

　　　　根據右側Main的project和下面Main?class確定自己監控的main方法

　　　　在右側找到Arguments選項卡 -> 在VM arguments中填寫參數

?

• -verbose:gc(打開GC的跟蹤日志)

• -XX:+printGC(打開GC的log的開關，簡要日志)

　　　　上圖為我自己的一個小項目中的gc簡要的日志信息?其中 9865k?表示在堆中GC之前使用了9865k的空間，2891k?表示GC之后使用2891k的空間，剩空間為19456k ，本次GC使用的時間為0.0021802?secs

• ?-XX:+PrintGCDetails(打印GC的詳細信息)

　　　　上圖我們以第二條為例：PSYoungGen表示新生代 GC之前為9214k，GC之后為 1016K，新生代總大小為9216k，GC所使用的時間為0.0016505?secs。而后面的信息則為上面簡要信息中的內容。user 總計本次 GC 總線程所占用的總 CPU 時間 ，sys – OS 調用 or 等待系統時間，real – 應用暫停時間，如果GC 線程是 Serial Garbage Collector單線程的方式的話，? real time 等于user 和 system 時間之和.

?

（def new generation）新生代
（total 13824K）共有13824K空間可用，（used 11223K）有11223K被使用。
（eden space 12288k.91%）伊甸區 對象出生的地方有 12288K 的空間，有91%已經被占用
（from space 1536K，0%）s0區 1536K空間，被占用為0
（to space 1536K，0%）s0區 1536K空間，被占用為0
（tenured generation）老年代
（the space 5120K，0%）有5120K空間被占用為0
（compacting perm gen）永久代
（the space 12288k，1%）有12288K空間被占用為1%，在jdk5.0之后在串行GC下有一個永久區共享，打開共享之后一些基礎的java類可用被所有的jvm共同使用，所以被占用率較小.
（ro space 10240K，44%）只讀共享區間 有10240K空間 44%被占用
（rw space 12288K，52%）可讀可寫共享區間 有12288K空間，52%被占用

（而最后[]號中的3個值為地址值，分別表示當前內存區域的地址開始地址，當前地址，最大地址上限）

　　上圖為我自己獲取到的jvm日志信息，永久代被刪除，取而代之的是Metaspace?元數據區域，這是 java8?所做的替換。

持久代中存的內容：

JVM中類的元數據在Java堆中的存儲區域。

Java類對應的HotSpot虛擬機中的內部表示。

類的層級信息，字段，名字。

方法的編譯信息及字節碼。

變量

常量池和符號解析

元空間的特點：

充分利用了Java語言規范中的好處：類及相關的元數據的生命周期與類加載器的一致。

每個加載器有專門的存儲空間

只進行線性分配

不會單獨回收某個類

省掉了GC掃描及壓縮的時間

元空間里的對象的位置是固定的

如果GC發現某個類加載器不再存活了，會把相關的空間整個回收掉

• ?-XX:+PrintGCTimeStamps(打印GC發生的時間戳)

• -Xloggc:log/ge.log(指定GC.log的位置，以文件形式輸出)
• -XX:+PrintHeapAtGC（每一次GC后都打印出堆信息）

　　?Heap before GC 表示GC之前的堆信息
　　 Heap after GC 表示GC之后的堆信息

• -XX:+TraceClassLoading（監控類加載，可以在程序運行時檢出哪些類被加載了）

• -XX:+PrintClassHistogram（加入此參數，在運行時不會有其他東西輸出，但是在按下Ctrl+Break后可以打印出類的信息，類的直方圖）

　　上述4個列分別代表了（num）序號,（instances）實例數量,(bytes)總占用空間，（class name）類型
　　　　（[B）有890617個byte數組，占用了470266000的空間
　　　　（java.util.HashMap$Node）hashMap的結點有890643個占用21375432的空間

?

二、堆的分配參數

• -Xmx（最大堆的空間）
• -Xms（最小堆的空間）

System.out.println("系統最大使用空間：Xmx=" + Runtime.getRuntime().maxMemory()/1024.0/1024 + "M"); System.out.println("系統可用空間：free mem=" + Runtime.getRuntime().freeMemory()/1024.0/1024 + "M"); System.out.println("系統中分配到的空間：total mem=" + Runtime.getRuntime().totalMemory()/1024.0/1024 + "M");

　　?我們可以通過上述代碼來獲取系統中實際使用的空間大小。

　　我們可以看到，我的系統中最大堆空間為18.0M，系統分配到的空間為9.5M，是比較接近于我們自己設置的值，系統目前可用空間為7.9M，此時系統存在可用空間。
　　當我在我的系統中加入一行代碼，創建一個1M的byte數組

byte []b = new byte[1024*1024*1];

　　此時發現，系統可用空間整好少了1M，而總空間和系統中分配到的空間還是沒變的，如果我們的系統使用的空間是小于系統分配的空間時，系統分配空間會盡可能維持在最小空間10M附近，只有系統使用的空間大于10M后，系統分配空間才會去擴展。我們在代碼中創建一個10M的byte數組來看。

?

?　　此時，系統使用的空間肯定是大于10M的，所以我們的系統分配的空間已經擴展到了16M.如果我們創建一個大于20Mbyte的話就會發生OOM了，因為系統已經限制最大空間為20M。

?

• -Xmn (設置新生代的大小)
• -XX:NewRatio（設置新生代和老年代的比值，如果設置為4則表示（eden+from（或者叫s0）+to（或者叫s1））： 老年代 =1：4），即年輕代占堆的五分之一
• -XX:SurvivorRatio（設置兩個Survivor（幸存區from和to或者叫s0或者s1區）和eden區的比），8表示兩個Survivor：eden=2:8，即Survivor區占年輕代的五分之一

?　　??下面來看一個例子（jdk6）

//將jvm參數設置為-Xmx20m -Xms20m -Xmn1m -XX:+PrintGCDetails（將新生代的大小設置為1M） byte []b = null; for (int i = 0; i < 10; i++) {b = new byte[1024*1024*1]; }

?　? ?上圖為堆信息，沒有發生過GC，新生代只有896K，1Mbyte無法分配到新生區，所以所有的數據都被分配到老年代，老年代的內存被占用的為10240K正好是byte的大小。
　　我們將上述代碼的新生代的內存進行擴大，調整到15M -Xmx20m -Xms20m -Xmn15m -XX:+PrintGCDetails

?

　　我們發現修改新生代之后也沒有發生GC，而是將數據全部分配到了新生代13824K，老年代卻沒有使用。

　　我們將上述代碼的新生代的內存進行減小，調整到不大不小的位置，調整到7M -Xmx20m -Xms20m -Xmn7m -XX:+PrintGCDetails

　　此時發現GC被觸發了2次，第一次回收了3M左右，第二次回收了4M左右，此時發現新生代被使用1139K，老年代被使用2507K，因為form to（s0 s1）區域的大小為704K，不足1M所以才GC時還是有一部分數據被放入了老年代。

?　　接下來，我們將幸存代的大小進行調整from：to：endn=1：1：2，?-Xmx20m -Xms20m -Xmn7m XX:SurvivorRatio=2 -XX:+PrintGCDetails

?

　　此時幸存代可以正常使用，GC發生了3次。第一次回收了1M，第二次回收了3M，第三次回收了3M，新生代占用了3M，此時新產生的數據沒有進入到老年代。

?　? 接下來，繼續調整新生代和老年代的比例為1，?-Xmx20m -Xms20m??-XX:NewRatio=1?XX:SurvivorRatio=2 -XX:+PrintGCDetails

?

　　此時GC進行了2次回收第一次回收了3M，第二次回收了4M，還有3M在新生代，也沒有數據進入老年代，并且GC只執行了2次，所以對于上一種配置效率就有所提高，因為GC時很消耗效率的。幸存代空間越大，對系統資源的浪費還是挺嚴重的，所以合理的分配幸存代，堆系統的效率也會有很大的幫助。

?　　接下來，繼續調整幸存代的大小進行調整from：to：endn=1：1：3，?-Xmx20m -Xms20m??-XX:NewRatio=1?XX:SurvivorRatio=3 -XX:+PrintGCDetails，此時，from和to的幸存區有2M，而endn區有6M

　　此時GC只進行了1次，我們對幸存代的大小進行了合理的減小，這樣更有利于內存的合理使用。

• -XX:+HeapDumpOnOutOfMemoryError(將OOM時的堆信息導出到文件)
  如果系統出現OOM一般情況系統有可能會down掉，但是我們排查問題時需要場景重現是比較困難的，所以當我們輸出了OOM的異常時，就可以直接查看，找出導致OOM的原因
• -XX:+HeapDumpPath=XXXX(導出OOM堆信息文件的路徑)

• -XX:OnOutOfMemoryError(在系統出現OOM時，執行一個腳本，可以發送郵件，報警或者是重啟程序)
• -XX:PermSize（設置永久代的初始空間大小）
• -XX:MaxParmSize（設置永久代的最大空間）

　　　　在使用CGLIB等庫的時候，可能會產生大量的類，這些類就有可能會撐爆永久區導致OOM
　　　　我們來看下面實例：

for (int i = 0; i < 100000; i++) {CglibBean c = new CglibBean(new HashMap<String, String>()); }

　　當發生OOM時，我們發現永久區的空間已經是滿了，然后發生GC時永久區的內容也無法被回收，所以導致了OOM，此時新生代只占用了2%，老難帶占用了20%，而老年代使用率為99%.

總結：

• 根據實際事情調整新生代和幸存代的大小，因為各個系統的情況都不一樣，所以需要自己調試而找到一個相對較優的分配方案。
• 官方推薦新生代占堆的3/8
• 幸存代占新生代的1/10
• 在OOM時，及得Dump出堆，確保可以排查現場問題
• 在堆空間沒有使用完時也有可能會產生OOM，此時有可能是永久代被撐爆。

三、棧大小的分配

棧是每一個線程都有的，他是線程私有的一塊內存區域.棧中主要是由幀組成，而幀中是每個方法的局部變量表，操作數表，和指向常量池的引用和返回地址等組成。一般只有幾百K，但是它的大小決定了線程的多少和調用函數的深度，而且每個線程都有獨立的棧空間。

• -Xss（設置棧空間的大小）
  下面看一個簡單的例子：首先我們將棧空間設置為128K

private static int count = 0; public static void recursion(long a, long b, long c) {long e = 1, f = 2, g = 3, h = 4, i = 5, j = 6, k = 7, l = 8, m = 9;count ++;recursion(a, b, c); }public static void main(String[] args) {try {recursion(1, 2, 3);} catch (Throwable e) {System.out.println("deep of calling = " + count);e.printStackTrace();} }

　　此時只執行了323次的遞歸。

　　然后我們將棧空間擴大到256K再來看結果：

?

　? ? 此時遞歸執行竟然擴大到了1019，接近3倍，那么說明方法執行的深度由棧空間的大小所決定。

　　然后我們將局部變量e之后的局部變量都清除再來看結果：

?

　　我們發現，遞歸次數再次增加。此處說明方法執行的深度也由方法內局部變量表的個數所決定。

轉載于:https://www.cnblogs.com/xuningchuanblogs/p/11441520.html

總結

以上是生活随笔為你收集整理的JVM 参数(转)的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。