[[396410]]

 對JVM的調優，需要大量的場景以及經驗，本篇主要是從一個理論的角度，粗淺地給大家介紹一下。

我把堆區的主要結構以及參數放在下面，這樣可以參照著圖來看：

一、如何設置最大年齡

每發生一次Young GC，就會將Eden區和當前的Survivor區的存活對象一次性地轉入到另外一個Survivor區中，并將之前的Eden區以及Survivor區清空。所以年輕代的存活對象，基本上就是在兩塊Survivor區中換來換去，每換一次，年齡增加1歲。當到達最大年齡時(最大年齡由-XX:MaxTenuringThreshold參數設置，默認15歲)，就會被轉移進老年代。

現在有這樣的一個場景，8歲的對象有1000個，過了一段時間后，15歲的對象有900個。可以觀察到，在8歲后，有90%的對象達到了默認的最大年齡，這些對象不停地在兩個Survivor區中換來換去，無疑增加了復制成本。因此，在這種情況下，我們大可以將最大年齡設置為8歲，達到8歲的對象，直接轉移至老年代，避免多次重復復制與浪費新生代空間。

二、Young GC頻繁怎么辦?

我們使用jstat -gcutil {pid} 1000，即每秒打印出GC的統計信息，其中YGC代表Young GC 發生的總次數。每秒刷新一次統計信息，如果此時發現YGC增加得很頻繁，比如一秒一次Young GC。

Young GC頻繁，代表著新對象的創建速度與新生代大小不匹配，要么是代碼中頻繁創建對象，要么就是新生代的空間太小。排查代碼是有必要的，但卻非常耗時。那么這一次，我們主要從調整新生代大小的方案入手。

我們大可以將新生代區增加為1.5倍(為什么是1.5倍，這只是一個試探的倍數)。如果之前Young GC的每隔1000ms發生一次，那么理論上現在的Young GC的發生間隔在1500ms左右，頻率有所降低，但是會不會導致每次Young GC的耗時增加為原來的1.5倍呢?

答案是不會的

Young GC主要是對新生代進行清理，首先對Eden區和一塊Survivor區的存活對象進行標記，然后一起復制另外一塊Survivor區中，最后直接清理Eden區和之前的Survivor區。可見，這里耗時最嚴重的環節是復制操作。

大概98%的對象都是在幾毫秒內死亡，即使將新生代擴充為原來的1.5倍，那么當下一次Young GC到來時，復制的對象總數遠小于之前的1.5倍，可能只是比之前多一點點，比如是1.15倍。

因此，將新生代擴容至原來的1.5倍，理論上，掃描新生代的時間將會變為原來的1.5倍，標記時間在[1，1.5)倍內，復制時間在[1，1.5)倍內，且這兩個時間遠小于1.5倍。對于虛擬機來說，復制的消耗成本遠大于掃描與標記操作。因此，擴容新生代后，Young GC不會顯著地按照線性增長。

如果保持整個堆的大小不變，那么擴容新生代后，勢必會壓縮老年代的空間，Major GC的頻率可能會增加。所以，還是需要找到一個臨界點，在能夠大幅度下降Young GC的頻率時，且只在小幅度內增加Major GC的頻率。