对JVM的调优，需要大量的场景以及经验，本篇主要是从一个理论的角度，粗浅地

对堆这边不太熟悉的同学，可以先参考我的这一篇文章说说java中的堆区

我把堆区的主要结构以及参数放在下面，这样可以参照着图来看：

一、如何设置最大年龄

每发生一次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的频率。