JVM调优，其实一直以来都是一个比较难搞的技术问题，平常咱们首要精力都是负责代码的编写，并没有过多重视和参加到线上环境的JVM调优傍边。而当某天机器的功能变差之后，大多都是先进行弹性扩容，然后就置之不理了。所以久而久之就容易忽略掉JVM的调优技术。
那么今日就让咱们回忆下，JVM调优进程中需求注意哪些点？
年青代和老时代的份额需求结合实践场景调整
咱们知道Java的内存模型中，最大的内存区域块叫做堆，而在Hotspot JDK8中选用分代收回类型废物收集器的时分，堆内部被区分为了年青代和老时代。
年青代：新创建的目标生存于此，内部区分为eden区和from survior，to survior区。
老时代：首要用于寄存经过年青代屡次收回（收回次数超越阈值即可提升）依然存活的目标，或者某些因其他特别原因提升的目标。
老时代它有个特色，便是目标比较稳定，所以针对这部分的GC进行调优或许难度比较高，咱们在对老时代进行重视的时分，更多是重视空间是否足够。
在Jvm的年青代里，有两个模块组成，分别是eden区和survior区域。年青代和老时代的全体内存布局如下所示：
在Hotspot版别的Jdk8中，年青代和老时代的默许份额是1:2,这个份额能够经过下列参数来进行控制。
–XX:NewRatio=2（这儿意思是年青代占据了1/3的堆内存空间,老时代占比是年青代的两倍）
看到这儿 或许你会想，那不如将年青代的内存设置大一些，这样是不是能够削减minior gc的次数呢？不过这样也会导致老时代的内存不行用，所以这个得结合实践测验得出最佳的份额。假如你拿不定主意，我主张运用默许的份额就好了。
假如你在实践测验中，发现了比默许值更好的份额设置，能够参考运用以下几个参数：
-Xms128M ：设置堆内存最小值
-Xmx128M ：设置堆内存最大值
-XX:NewSize=64M ：设置New区最小值
-XX:MaxNewSize=64 ：设置New区最大值
-XX:NewRatio=2 ：设置Old区与New区的份额
-Xmn64M ：设置New区巨细，等价于-XX:NewSize=64M 与-XX:MaxNewSize=64M两个参数，此值一旦设置则–XX:NewRatio无效。
这儿不是太推荐运用NewSize和MaxNewSize两个参数，主张运用Xmn区代替它们。这样能够在一开端就将年青代的巨细分配到最大，削减这个内存扩容的进程消耗。可是这儿也要看实践的机器内存是否严重。
另外在GC里边有一条很重要的实战调优经验总结是这样说的： 由于老时代的GC本钱一般都会比年青代的本钱要高许多，所以主张适当地经过Xmn指令区设置年青代的巨细，最大限度的下降目标提升到老时代的状况。
合理设置Eden区和Survivor区份额
这两个区域都存在于年青代里边，能够经过下列参数来进行它们巨细份额的设置：
-XX:SurvivorRatio=2 (表明eden区巨细是survivor区巨细的2倍)
一般JDK8里边，默许的这个份额是1:8（单个survivor:eden），这个份额其实是JDK开发者经过了众多实战之后，才设置的值，所以假如没有经过实践压测的话，不主张随便调整这个份额。为什么这么说呢，这儿我总结了两个原因：
不要设置过高的eden区空间虽然年青代目标的寄存空间许多，可是survivor的空间会很少，很或许导致从eden区提升到survivor区的目标，没有足够的空间寄存，然后直接进入了老时代。
不要设置过低的eden区巨细
首先eden区的空间缺乏，会导致minior gc的频频发生，一起survivor区也会导致空间过剩，内存浪费。
怎么结合事务场景进行堆内存的分配
前边咱们提到了合理的分配eden区和survivor区的份额很重要，为了让咱们愈加深入的去了解这儿面的重要性，我经过一个事例和咱们进行GC调优的剖析。
假定咱们有一个高并发的音讯中台服务，专门提供了用户基础信息的crud操作。预估上线后的qps大约会在6000+左右，预计上线后布置的服务节点是2core/4gb，16台，那么此刻要怎么进行jvm的参数评价。
这儿咱们能够剖析下，假定是6000+请求分配到了16个节点上，那么大约便是每个节点承载400左右的qps。这儿由于音讯中台底层会有比较多的数据库查询，所以存储部分做了分库分表，而且大部分状况会走缓存处理。
假定咱们的音讯目标Message为：
public class MessagePO {
private Long id;
private String sid;
private Long userId;
private String content;
private Integer type;
private Integer readStatus;
private Integer replyStatus;
private String ext;
private Date sendTime;
private Date updateTime;
private Long receiveId;
//getter setter省略}
这儿咱们能够模拟下这个目标的存储内容，然后进行巨细预估：
public static void main(String[] args) throws IllegalAccessException {
MessagePO messagePO = new MessagePO();
messagePO.setUserId(10012L);
messagePO.setReadStatus(1);
messagePO.setReceiveId(12389L);
messagePO.setReplyStatus(1);
messagePO.setContent("这是一条测验语句");
messagePO.setExt("{"key":"value"}");
messagePO.setSid("981hhdkahnhiodqw012");
messagePO.setSendTime(new Date());
messagePO.setUpdateTime(new Date());
messagePO.setId(191912342L);
messagePO.setType(1);
System.out.println(messagePO);
ClassIntrospector ci = new ClassIntrospector();
System.out.println(ci.introspect(new Short((short) 1)).getDeepSize()); //16字节
System.out.println(ci.introspect(messagePO).getDeepSize()); //912字节
System.out.println(ci.introspect(new Integer((short) 1)).getDeepSize()); //16字节
System.out.println(ci.introspect(new Long((short) 1)).getDeepSize()); //24字节
}
运用工具预估单个messagePO目标的巨细在912byte左右，这儿咱们预估它有1kb左右。那么面临单个节点400qps的访问，一秒钟单是MessagePO目标或许便是400kb起步，再加上或许会有其他一些杂七杂八的其他目标发生，这儿咱们暂时能够预估个10倍的量。（这儿的10倍要结合事务场景去计算）。最终咱们其实还需求考虑到代码里边是否会有运用List这种数据结构的状况，假如有，或许还得翻个10倍，也便是40mb/s的目标发生速率。
而这些新发生的目标，大多数都是用完就废的状态，所以基本上熬不过一轮Minior GC。可是在进行Minior GC的时分，目标或许还存在引用的或许（例如有些方法执行到了一半），Minior GC每次收回后会有部分的目标或许会存活下来，然后进入到survivor区中。
而之前咱们说了，服务的节点总内存是4gb，那么jvm的堆内存能够分配大约60%的空间（预留一部分是元空间和线程内存等），也便是2.5gb左右。所以此刻能够尝试分配参数是：
- -Xms2560m-Xmx2560m-Xmn1024m
这个参数能够分配给了年青代1gb左右的巨细，依照默许的份额来算便是eden区780mb，两个survivor区合并起来260mb左右，即单个survivor区为130mb。这也就意味着，依照咱们上边预期的状况来想，40mb/s的目标发生速率，大约20秒能够占满eden区，依照计算，大约会有95%的目标被收回，大约剩余35mb左右的目标放入到survivor区中。
目前从理论层面来看好像全部都还挺正常的，可是不要忘了，实践仍是需求经过压测去验证的。假定哪天咱们的事务场景变化了，程序员在代码中用了许多的List去寄存目标，那么GC的状况或许就不像你想的那么简略了。
例如某天，当你发现上了一个需求之后，线上的老时代GC开端变得频频了，可是代码里边也没有什么问题，那么这个时分，会有一种或许便是由于你的survivor区过小，导致目标在进行minior gc之后存活的目标体积大于survivor区的一半，从而导致了目标的直接提升。
而这种时分，你能够结合事务场景进行调优剖析，例如下降老时代的巨细份额，添加survivor区的巨细。
当然上边我说的这些都是需求你结合事务场景去剖析的，这儿我仅仅给了一个思路，全体思路我总结下来，大约便是：合理分配eden区和survivor区，尽量不要让目标进入老时代。
运用CMS废物收集器的时分注意老时代的内存紧缩频率
在老时代中，CMS默许会先选用符号铲除算法进行内存的收回，每次老时代进行full gc的时分，会有一个计数器在做累加。
当老时代的full gc 超越了必定次数之后，就会进行一次内存紧缩。这个内存紧缩能够削减内存碎片的存在，具体经过下列参数进行控制
-XX:CMSFullGCsBeforeCompaction=10
这个数值默许是0，也便是说 每次老时代的full gc执行之后，都会触发一次内存碎片的紧缩，在进行内存紧缩的进程中，会延伸GC的时刻。所以这个参数我觉得是能够进行调优的，不过要结合实战进行调整。
合理设置CMS废物收集器在老时代的收回频率
-XX:CMSInitiatingOccupancyFraction 表明触发 CMS GC 的老时代运用阈值，一般设置为 70~80（百分比），设置太小会添加 CMS GC 发现的频率，设置太大或许会导致并发模式失败或提升失败。默许为 -1，表明 CMS GC 会由 JVM 主动触发。
-XX:+UseCMSInitiatingOccupancyOnly 表明 CMS GC 只根据 CMSInitiatingOccupancyFraction 触发，假如未设置该参数则 JVM 只会根据 CMSInitiatingOccupancyFraction 触发第一次 CMS GC ，后续仍是会主动触发。主张一起设置这两个参数。
CMSInitiatingOccupancyFraction默许是92%，所以运用cms废物收集器，默许老时代的收回是十分少的，而假如当内存到达了92%份额的占用，那么此刻就会触发CMS废物收集器的收回流程。
假如此刻发现内存空间缺乏了，就会进入运用Serial Old收集器来进行收回的环节，这一阶段的功能就很差了，所以这一点也是CMS废物收集器存在的一个风险隐患，极点场景下或许会有长时刻的stw。
容器化布置中的JVM参数需求注意哪些点
在HotSpot类型的Java程序中，JVM的内存巨细一般会是（堆巨细+栈空间 * 线程数+元空间+其他内存），所以假如仅仅装备了Xmx（最大堆内存）参数其实仍是不行的。
其实Java程序默许发动的堆巨细是操作系统内存巨细的1/4；能够经过参数 -XshowSettings:vm -version 来查看。假如咱们将程序布置到了容器节点里边的话，可是不想装备xmx类型的参数，这个时分能够用UseCGroupMemoryLimitForHeap来设置，运用了该参数后能够使Java应用在发动的时分，能够读取到容器节点内的内存巨细。这样就不必忧虑JVM内存巨细超越容器的cgoup内存占用巨细了，而被误杀。可是运用该参数的利用率会很低。
当然假如你不太信任主动挡机制的话，安全起见能够运用手动挡方法设置Xmx内存参数。（主动挡）
