gc调优我们到底在调整什么

java开发一般都会涉及到jvm调优，其中gc调优是个重点项。那gc调优调整的究竟是什么呢？准确来说是业务。下面围绕这个话题展开

起因

为什么说是业务呢，得从c，c++开始说起，如果说是用c/c++做开发，运行的效果是比较稳定的。毕竟没有gc这种问题，也就没有什么gc造成的停顿，没有响应。但是c/c++开发要比java慢，尤其是跨平台运行的程序，需要不停的做宏定义，区分系统的区别。包括开源的库还有框架，整体是比java少的。java的框架特别多，可以说如果面对的是比较成型的业务，那么基本就是java框架的应用，并不会自己重头来做。所以java开发效率上带来了极大的便利。 java的缺点也就是他的垃圾回收。java没有delete这样释放内存的操作，这个本来算是个有点，不需要过多的操心内存泄漏问题。他的结局方案是垃圾回收器。会导致带来的短暂停顿，然后jvm去做对象回收。

业务

虽然有以上的问题，但是业务场景确实是多样的，根据业务场景调优，这个才是我们要做的。业务场景大概能分为以下几种：

1. 任务型
2. 交互型

任务型 任务型主要是执行一段代码，一旦执行，不需要过多的交互。例如计算一个月的数据等等，大多数的表现都是计算出结果就完毕，一般就是希望全力跑出结果，对应到java里的部分就是在乎吞吐量。吞吐量就是业务执行时间/gc时间+业务执行时间。 任务型的情况，parallel gc基本就是唯一选择，我们只需要注意-XX:GCTimeRatio这个参数即可，公式为1/（1+N），默认为99，表示吞吐量gc只占用1%的时间，剩下99%都是业务执行。 交互型 交互型的一般表现为我们的网站这种，需要人参与的。这种情况下，响应速度就比较重要了，gc了5秒，那么jvm停顿5秒，这个显然是不能接受的。 一般首选cms。cms的优点是老年带回收时分多个步骤，只有初始标记和再次标记是stw的。其余的步骤，并不会导致jvm业务停顿，由于gc线程和业务线程并行在跑，响应也不会和没有gc时的一样好。 cms的问题在于浮动垃圾，最终会采取单线程回收老年代的情况，会有次回收导致时间特别长。 G1相对缓解了cms浮动垃圾的问题，他通过region管理堆，对象的分配可以规整管理。G1也有fullgc的问题。也需要合理的避免。

特例

上面说明了大多数场景的选择，但是具体还需要根据自己的场景来测试，例如虽然是个交互型，但是用的堆少，物理机的机器资源很多，那么这种场景下，parallel gc不一定比cms表现差，虽然他gc的时候整体停顿了，但是堆小，gc线程多。压测起来，qps比cms更好。

观察方式

gc的初步选择已经出来了，接下来需要调整具体的搭配的gc参数了。这时候就需要一个观察者，来看调整的参数知否有效。选择的方式有很多，比较建议prometheus的方案，主要是他是开源且简单搭建的，可以通过grafana把参考的指标都打出来。我们就可以通过查看曲线图等等，对参数调整的状态有一个比较直观的认知，这里不用通过日志来看，图像更直观一点，日志中的细节很多，但是随着时间线的对比确实是不直观。

小结

gc调优需要分析业务，资源，选择几种垃圾回收器的组合，然后通过类似prometheus这样的监控，来对比，gc各种参数，以及配套参数中的细节效果。

转载于:https://my.oschina.net/xpbob/blog/3065254