（1）GC_调优老年代
CMS是低响应时间的，并发的一个垃圾回收器 ，有这样一个缺点，因为在垃圾回收的同时，其他的用户线程也在运行，就会产生新的垃圾这个新的垃圾称为浮动垃圾，如果浮动垃圾产生了又导致内存不足问题就大了就会造成CMSD并发失败，CMS的垃圾回收器就不能正常工作了，就会退化为串行SerialOld的老年代垃圾回收器，效率就低了
先不要尝试老年代调优，可能没有发生Full GC，即使发生了Full GC也要尝试先调试新生代大小，幸存区大小啊，幸存区的晋升阈值啊，容量等等等这些手段用了，还是经常发生Full GC再来看看老年代的调优
当老年代发生Full GC时我们观察老年代是由于多大的内存导致了Full GC的发生，可以在原有Full GC时内存的基础上调大四分之一到三分之一
下面的那个参数：控制老年代内存达到总内存多少的时候触发CMS垃圾回收，值越低触发垃圾回收的时机越早，一般设置为75-80%之间
（2）GC调优_案例1
案例1程序运行期间GC非常的频繁尤其是Minar GC gc特别频繁，说明控件紧张，如果是新生代空间紧张当业务的高峰期来了，大量的对象被创建，很快 新生代内存很快被占满了，造成幸存空间紧张了导致晋升阈值降低，生命周期很短的对象也会晋升到老年代去，这样情况进一步导致老年代存放很多大量生命周期很短的对象，容易触发老年代的Full GC
如果是新生代的内存设置小了， 内存优化从新生代开始，增大新生代的内存，增大了幸存区的空间以及晋升阈值这样尽可能把生命周期很短的对象留在新生代，不要晋升到老年代，就解决老年代的Full 的发生
（3）GC调优_案例2
第二个案例是采用的是CMS但是当发生了Full GC 暂停时间特别长，我们可以去查看GC日志，查看那个阶段耗费的时间较长，通过查看GC日志呢可以把每一阶段的耗费时间在GC日志了里找到，
可以看待重新标记阶段占用大量的时间
我们知道CMS的初始标记跟并发标记时间还是很快的，比较慢的是重新标记那一块，重新标记的时候需要扫描整个堆内存，不仅扫描老年代也要扫描新生代，如果高峰期的时候，新生代的对象比较多，那么扫描时间就会变得非常的多 ，那么在重新标记之前，把新生的对象先做一次垃圾回收，减少新生代对象的数量这样就可以减少重新标记的时间啊
需要设置下面的这个参数在重新标记之前对新生代做一次垃圾的清理，减少重新标记的时间
（4）GC调优_案例3
案例三也是采用CMS，但是它是在老年代相当充裕的情况下发生了Full GC ，CMS呢可能是由于空间不足导致并发失败或者空间碎片比较多都会产生Full GC,但是通过日志并没有发现并发失败或者碎片过多导致的错误提示说明了老年代的空间是充裕的，不是由于老年代的空间不足导致的Full
GC，发现jdk是1.7，1.7的采用的是永久代作为方法区的实现，永久代的空间不足也会导致Full GC
1.8采用元空间，元空间就不是由java这边来控制了元空间采用操作系统的元空间，空间的容量是比较充裕的不会发生元空间的空间不足问题
1.7呢如果元空间设置小了，就会触发整个堆的一次Full GC，这样就定位了是由于元空间的不足导致的Full GC,所以就可以增大元空间的初始值和最大值，保证Full GC的发生
