在上一篇中我們介紹的有引數的設定，那我們要了解不同的引數對於程式的影響和對於調優的影響，這個時候我們就需要檢視gc日誌來看我們設定的引數是否合理，這一章節中我們就來檢視gc日誌

一、新生代和老年代的比值對效能的影響

 Map map = new HashMap<>();
        for (int i = 0; i < 10; i++) {
            byte[] b = new byte[1024*1024];
            map.put(i,b);
        }
        System.out.println
 
(map);
-Xmx10M -Xms10M -verbose:gc -XX:+PrintGCDetail  -XX:PrintHeapAtGC  -Xloggc:ggc.log

- 1、我們首先來看一個問題：yong = eden+survivor from + survivor to的，但是 2048+512+512 > 2560

解釋如下：新生代的可用空間：eden+survivor from，是的 to不屬於可用空間，在一次MinorGC之後，eden和from中還活著的物件會被全部複製到to中，然後from和to的角色互換，即可用空間只是eden+from

• 2、第二個問題，我們可以看到在 before gc前，from和to都是 0%，而old區則為85%，為何新生代的from和to都是0%呢？

解釋如下：我們每次產生的物件的大小都是1m的物件，當物件過大時，會直接進入老年代

• 3、有很多的博文都是介紹XX:SurvivorRation的預設值為8，我的上一篇博文中也是這樣來寫的，但是我們可以看到這裡的比值很顯然不是8，

解釋如下：在我們不斷上調Xmx和Xms的時候，這個比值近似8

針對問題2，我們現在做一些改動，現在只是生成10M大小的物件，單個物件的大小是1M，顯然我們是需要調整Xmn和SurvivorRation的比例的

二、設定Xmn和SurvivorRation的比值

-Xmx10M -Xms10M -Xmn6M -XX:SurvivorRatio=
 
4 -verbose:gc -XX:+PrintGCDetails -XX:+PrintHeapAtGC -Xloggc:gcc.log

即：堆區20m ，新生代6M，Eden：surviror = 4 ，即eden=4096：from=1024：to=1024

我們可以看到，在 before gc前，物件都存在於eden區，

在 after gc之後，我們可以看到，一部分物件存在於from區了，說明我們的調整是有效的

下一篇我們將會討論一下jvm的垃圾回收機制，這一篇估計會比較麻煩 ，但是閱讀垃圾回收的策略，你會發現其實挺好玩的