排查到的问题:
新生代增长速度很快, 几分钟累计了近百GB, 导致YGC 发生频繁, 越 20-30秒一次. 仅仅如此也就算了，但是当新生代慢了后，ygc后老年代大小迅速暴增，几次ygc后，老年代爆满，触发fgc，依然无法清理老年代。
猜测:
1.可能存在内存泄漏，导致大量内存无法回收
2.代码新建对象过快，且释放过慢，导致还没释放就fgc然后卡死了
收集数据:
1.开启gc日志打印，并制定保存文件
2.启动代码
3.通过jinfo查看gc实时信息，等待几次ygc
4.将打印的gc日志复制一份，下载到本地，并使用jmap对堆内存进行dump后下载到本地，若内存过大可考虑调整jvm参数缩小堆大小，相应的dump文件也会变小
分析:
1.使用在线网站 gceasy.io 对gc日志分析，这个分析主要用于优化，对于问题的排查只有大方向上的作用
2.使用MAT分析dump文件(不建议使用jVisvualVM)，可查看耗内存最多的对象所属的类，由此切入，可找到内存泄漏代码处(我就是这样发现的)(才怪，我是对涉及代码一一排除，百度相关内存泄漏问题，才查出来的)
总结:
以排查异常，内存泄漏而言，使用jmap生成dump配合MAT分析堆对象情况，容易找到问题(不要学我用笨方法找)
以优化配置为由，对于gc日志，分析gc发生频率，耗时的统计数据来微调配置，用gceasy.io加gc日志是比较适合的。
思考点:
使用jVisvualVM时，有个VisvualGC可以查看随时间变化的堆的各个区的内存大小变化，而服务器在远程，比较难连接上jVisvualVM，所以无法查看这个变化数据
但是，我们通过jinfo照样可以采集实时变化数据，时候可以通过保存jinfo的信息，对其进行分析，然后一键显示随时间变化的图表动画。
