随着应用程序的复杂性和负载的不断增加，对JVM进行调优，也是保障系统稳定性的一个重要方向。
需要注意，调优并非首选方案，一般来说解决性能问题还是要从应用程序本身入手（业务日志，慢请求等），只有在必要时才对jvm进行调优（gc日志和监控异常）。
下面会提供一个线上案例，说明gc调优的重要性。
02_jvm性能调优_垃圾收集器的实现-CSDN博客
调优关注指标
吞吐量
程序运行过程中执行两种任务，执行业务代码的任务和执行垃圾回收的任务；
吞吐量计算公式：CPU在用户应用程序的运行时间/(CPU在用户应用程序的运行时间+CPU在垃圾回收程序的运行时间)
简单理解就是，吞吐量大，意味着应用程序运行的时间越多，执行业务的任务越多。
那么吞吐量多大合适呢，对于我们业务系统来说，肯定是越大越好了，但吞吐量太大会导致什么问题呢？
停顿时间
因为JVM在进行垃圾回收的时候，有些特有的阶段需要停止业务程序的运行，只有这样它才能准确的找到所有可达的节点，确定哪些是垃圾对象并进行清理。
例如：gc停顿100ms，意味着在这100ms内应用程序无法运行。注意这里的停顿时长，只是JVM停止业务程序执行垃圾回收任务的时长，并不是总的垃圾回收时间（有的收集器是一个回收阶段是有多个停顿的）
堆内存大小
当gc完成后，通常会释放一大块内存空间，所以如果频繁的gc，但可用内存没有下降的趋势（或趋势比较小），通常暗示有内存泄漏的问题。
以上三者的关系
这3个指标不可能同时达到，因为他们是一个不可能的关系。
内存变大，要回收的东西肯定变多，停顿时间肯定也会延长。
吞吐量增加，必然要减少垃圾回收的频率，频率降低，垃圾回收停顿的时间也会延长。
停顿时间减少，需要增加gc的频率，导致吞吐量下降。
因此，目前的调优方向主要是吞吐量和暂停时间。（我们的目标是停顿时间竟可能小的情况下，达到最大的吞吐量）
案例-停顿时间过高
系统配置2c12g，默认使用并行回收器。
通过下图的监控，可以发现，gc频率低，但停顿时间比较长（通常停顿时间尽量不要超过300ms）
因为行回收器会导致暂停时间变长，可以考虑更换垃圾收集器（G1） -XX:+UseG1GC -XX:MaxGCPauseMillis=300 ，通过设置合理的暂停时间，减低停顿时间。
为什么没有使用cms呢？
