一、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 所做的替換。

持久代中存的內容：

1. JVM中類的元數據在Java堆中的存儲區域。
2. Java類對應的HotSpot虛擬機中的內部表示。
3. 類的層級信息，字段，名字。
4. 方法的編譯信息及字節碼。
5. 變量
6. 常量池和符號解析

元空間的特點：

1. 充分利用了Java語言規範中的好處：類及相關的元數據的生命周期與類加載器的一致。
2. 每個加載器有專門的存儲空間
3. 只進行線性分配
4. 不會單獨回收某個類
5. 省掉了GC掃描及壓縮的時間
6. 元空間裏的對象的位置是固定的
7. 如果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之後的局部變量都清除再來看結果：

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

-------------------- END ---------------------

最後附上作者的微信公眾號地址和博客地址

Herrt灬淩夜：https://www.cnblogs.com/wuyx/

常用的JVM配置參數