GC调优是最后要做的工作，GC调优的目的可以总结为下面两点：
减少对象晋升到老年代的数量
减少FullGC的执行时间
通过监控排查问题及验证优化结果，可以分为：
命令监控：jps、jinfo、jstack、jmap、jstat、jhat
图形化监控：
阿里巴巴开源的 Java 诊断工具：Arthas（阿尔萨斯）：
如果GC执行时间满足下列所有条件，就没有必要进行GC优化了：
Minor GC执行非常迅速（50ms以内）
Minor GC没有频繁执行（大约10s执行一次）
Full GC执行非常迅速（1s以内）
Full GC没有频繁执行（大约10min执行一次）
案例参考：
CMS调优
Java中9种常见的CMS GC问题分析与解决
常见场景分析 动态扩容引起的空间震荡现象
服务刚刚启动时 GC 次数较多，最大空间剩余很多但是依然发生 GC，这种情况我们可以通过观察 GC 日志或者通过监控工具来观察堆的空间变化情况即可。GC Cause 一般为 Allocation Failure，且在 GC 日志中会观察到经历一次 GC ，堆内各个空间的大小会被调整，如下图所示：
原因分析
在 JVM 的参数中 -Xms 和 -Xmx 设置的不一致，在初始化时只会初始 -Xms 大小的空间存储信息，每当空间不够用时再向操作系统申请，这样的话必然要进行一次 GC。另外，如果空间剩余很多时也会进行缩容操作，JVM 通过 -XX:MinHeapFreeRatio 和 -XX:MaxHeapFreeRatio 来控制扩容和缩容的比例，调节这两个值也可以控制伸缩的时机。
解决方案
尽量将成对出现的空间大小配置参数设置成固定的，如 -Xms 和 -Xmx，-XX:MaxNewSize 和 -XX:NewSize，-XX:MetaSpaceSize 和 -XX:MaxMetaSpaceSize 等。不过在不追求停顿时间的情况下震荡的空间也是有利的，可以动态地伸缩以节省空间，例如作为富客户端的 Java 应用。
显式GC的去和留现象
手动调用 System.gc 方法会引发一次 STW 的 Full GC，对整个堆做收集，可以在 GC 日志中的 GC Cause 中确认。同时JVM提供-XX:+DisableExplicitGC 参数可以避免这种 GC。那么有没有必要启用该参数呢？
去留分析
首先需要了解下DirectByteBuffer，它有着零拷贝等特点，被 Netty 等各种 NIO 框架使用，会使用到堆外内存。它的 Native Memory 的清理工作是通过 sun.misc.Cleaner 自动完成的，是一种基于虚引用PhantomReference的清理工具，比普通的 Finalizer 轻量些。而为 DirectByteBuffer 分配空间过程中会显式调用 System.gc ，希望通过 Full GC 来强迫已经无用的 DirectByteBuffer 对象释放掉它们关联的 Native Memory。
如果通过-XX:+DisableExplicitGC关闭显式GC，DirectByteBuffer分配空间中System.gc将失效，这时如果很长一段时间没有做过GC或者只做了Young GC，则不会触发Cleaner 的工作，Native Memory得不到及时释放，有可能发生内存泄漏。
所以一般建议保留显式GC，但需要规范使用，避免频繁GC带来的性能开销。可通过-XX:+ExplicitGCInvokesConcurrent 和 -XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses 参数来将 System.gc 的触发类型从 Foreground 改为 Background，同时 Background 也会做 Reference Processing，这样的话就能大幅降低了 STW 开销，同时也不会发生 NIO Direct Memory OOM。
MetaSpace 区 OOM现象
JVM 在启动后或者某个时间点开始，MetaSpace 的已使用大小在持续增长，同时每次 GC 也无法释放，调大 MetaSpace 空间也无法彻底解决。
原因分析
Java 7 之前字符串常量池被放到了 Perm 区，所有被 intern 的 String 都会被存在这里，由于 String.intern 是不受控的，所以 -XX:MaxPermSize 的值也不太好设置，经常会出现 java.lang.OutOfMemoryError: PermGen space 异常。但在 Java 7 之后常量池等字面量（Literal）、类静态变量（Class Static）、符号引用（Symbols Reference）等几项被移到 Heap 中，PermGen 也被移除，取而代之的是 MetaSpace。在最底层，JVM 通过 mmap 接口向操作系统申请内存映射，每次申请 2MB 空间，这里是虚拟内存映射，不是真的就消耗了主存的 2MB，只有之后在使用的时候才会真的消耗内存。申请的这些内存放到一个链表中 VirtualSpaceList，作为其中的一个 Node。
关键原因就是 ClassLoader 不停地在内存中 load 了新的 Class ，一般这种问题都发生在动态类加载等情况上。
解决方案