寫在前面

jmap和jhat可以幫助我們觀察線上JVM中的物件分布，了解到你的系統平時運行程序中，到底哪些物件占據了主角位置，他們占據了多少記憶體空間，

1、使用jmap了解系統運行時的記憶體區域

有時可能我們會發現JVM新增物件的速度很快，然后就想要去看看，到底什么物件占據了那么多的記憶體，

如果發現有的物件在代碼中可以優化一下創建的時機，避免那種物件對記憶體占用過大，那么也許甚至可以去反過來優化一下代碼，

當然，其實如果不是出現OOM那種極端情況，也并沒有那么大的必要去著急優化代碼，

先看一個命令： jmap -heap PID

這個命令可以列印出來一系列的資訊，列印出來堆記憶體相關的一些引數設定，然后就是當前堆記憶體里的一些基本各個區域的情況比如Eden區總容量、已經使用的容量、剩余的空間容量，兩個Survivor區的總容量、已經使用的容量和剩余的空間容量，老年代的總容量、已經使用的容量和剩余的容量，

2、使用jmap了解系統運行時的物件分布

其實jmap命令比較有用的一個使用方式，是如下的： jmap -histo PID

這個命令會列印出來類似下面的資訊：

他會按照各種物件占用記憶體空間的大小降序排列，把占用記憶體最多的物件放在最上面，

所以如果你只是想要簡單的了解一下當前jvm中的物件對記憶體占用的情況，只要直接用jmap -histo命令即可，非常好用，你可以快速了解到當前記憶體里到底是哪個物件占用了大量的記憶體空間，

3、使用jmap生成堆記憶體轉儲快照

但是如果你僅僅只是看一個大概，感覺就只是看看上述那些物件占用記憶體的情況，感徑訓不夠，想要來點深入而且仔細點的，那就可以用jmap命令生成一個堆記憶體快照放到一個檔案里去，用如下的命令即可：

jmap -dump:live,format=b,file=dump.hprof PID

這個命令會在 當前目錄下生成一個dump.hrpof檔案，這里是二進制的格式 ，你不能直接打開看的，他把這一時刻JVM堆記憶體里所有物件的快照放到檔案里去了，

4、使用jhat在瀏覽器中分析堆轉出快照

接著就可以使用jhat去分析堆快照了， jhat內置了web服務器，他會支持你通過瀏覽器來以圖形化的方式分析堆轉儲快照，

使用如下命令即可啟動jhat服務器，還可以指定自己想要的http埠號，默認是7000埠號：

jhat dump.hprof -port 7000

接著你就在瀏覽器上訪問當前這臺機器的7000埠號，就可以通過圖形化的方式去分析堆記憶體里的物件分布情況了，

5、案例實戰

5.1、模擬代碼的JVM引數設定

接著我們會用一段程式來模擬出那種頻繁Full GC的一個場景，此時JVM引數如下所示：

-XX:NewSize=104857600 -XX:MaxNewSize=104857600 -XX:InitialHeapSize=209715200 
-XX:MaxHeapSize=209715200 -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=15 
-XX:PretenureSizeThreshold=20971520 -XX:+UseParNewGC -XX:+UseConcMarkSweepGC 
-XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:gc.log

“-XX:PretenureSizeThreshold”，把大物件閾值修改為了20MB，避免我們程式里分配的大物件直接進入老年代，

5.2、示例程式

public class Demo {

    public static void main(String[] args) throws Exception {
            Thread.sleep(30000);
          while(true) {
              loadData();
          }
    }

    public static void loadData() throws InterruptedException {
        byte[] data = null;
        for (int i = 0; i < 4; i++) {
            data = new byte[10 * 1024 * 1024];
        }
        data = null;

        byte[] data1 = new byte[10 * 1024 * 1024];
        byte[] data2 = new byte[10 * 1024 * 1024];

        byte[] data3 = new byte[10 * 1024 * 1024];
        data3 = new byte[10 * 1024 * 1024];

        Thread.sleep(1000);
    }
}

大概意思其實就是，每秒鐘都會執行一次loadData()方法，他會分配4個10MB的陣列，但是都立馬成為垃圾，但是會有data1和data2 兩個10MB的陣列是被變數參考必須存活的，此時Eden區已經占用了六七十MB空間了，接著是data3變數依次指向了兩個10MB的數組，這是為了在1s內觸發Young GC的，

5.3、通過jstat觀察程式的運行狀態

程式運行起來之后，突然在一秒內就發生了一次Young GC，這是為什么呢？

很簡單，按照我們上述的代碼，他一定會在一秒內觸發一次Young GC的， Young GC過后，我們發現S1U，也就是一個Survivor區中有79B3K的存活物件，這應該就是那些未知物件了，

然后我們明顯看到在OU中多出來了30MB左右的物件，因此可以確定，在這次Young GC的時候，有30MB的物件存活了，此時因為Survivor區域放不下，所以直接進入老年代了，

很明顯每秒會發生一次Young GC，都會導致20MB~30MB左右的物件進入老年代，因為每次Young GC都會存活下來這么多物件，但是Survivor區域是放不下的，所以都會直接進入老年代，

此時看到老年代的物件占用從30KB一路到60MB左右，此時突然在60MB之后下一秒，明顯發生了一次Full GC，對老年代進行了垃圾回收，因為此時老年代重新變成30MB了，

幾乎是每秒新增80MB左右，觸發每秒1次Young GC，每次Young GC后存活下來20MB~30MB的物件，老年代每秒新增20MB~30MB的物件，觸發老年代幾乎三秒一次Full GC，Young GC太頻繁，而且每次GC后存活物件太多，頻繁進入老年代，頻繁觸發老年代的GC，

對于YoungGC和FullGC的耗時？

18次Young GC，結果耗費了170毫秒，平均下來一次Young GC要5毫秒左右，但是9次Full GC才耗費10毫秒，平均下來一次Full GC才耗費1毫秒，這是為什么呢？

很簡單，按照上述程式，每次Full GC都是由Young GC觸發的，因為Young GC過后存活物件太多要放入老年代，老年代記憶體不夠了觸發Full GC，所以必須得等Full GC執行完畢了，Young GC才能把存活物件放入老年代，才算結束，這就導致Young GC也是速度非常慢，

5.4、對JVM性能進行優化

最大的問題就是每次Young GC過后存活物件太多了，導致頻繁進入老年代，頻繁觸發Full GC，

我們只需要調大年輕代的記憶體空間，增加Survivor的記憶體即可，看如下JVM引數：

-XX:NewSize=209715200 -XX:MaxNewSize=209715200 -XX:InitialHeapSize=31457280 
-XX:MaxHeapSize=314572800 -XX:SurvivorRatio=2 -XX:MaxTenuringThreshold=15 
-XX:PretenureSizeThreshold=20971520 -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:gc.log

我們把堆大小調大為了300MB，年輕代給了200MB，同時“-XX:SurvivorRatio=2”表明，Eden:Survivor:Survivor的比例為2:1:1，

所以Eden區是100MB，每個Survivor區是50MB，老年代也是100MB，

接著我們用這個JVM引數運行程式，用jstat來監控其運行狀態如下：