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

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

起因

为什么说是业务呢得从cc++开始说起如果说是用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各种参数以及配套参数中的细节效果。