Go1.6与JVM CMS的垃圾回收对比

自从Go1.5引入了真正的并发GC后, Go1.6进一步进行了优化,使得Go在上百G级的堆大小时依然能将STW时间控制在20ms以内:
Go1.6与JVM CMS的垃圾回收对比_第1张图片

而Java8的G1收集器,默认参数下在100G以上的heap下,会造成秒级的STW。虽然可以通过-XX:MaxGCPauseMillis调整,但是是以牺牲大量吞吐量为代价。这里浅析一下Go能做到比G1更短的STW的原因。

轮流挂起协程

JVM的CMS收集器在工作时,大致分为4个阶段:

  1. 初始标记
  2. 并发标记
  3. 重新标记
  4. 并发清除

其中1, 3 是需要STW的阶段,CMS的停顿也是由这2个阶段引发的。Go1.5中的CMS也分为这些阶段,其中1, 3同样需要STW。那为什么Go会停顿时间更少呢?原因是,Go的CMS在第3阶段并不是挂起所有goroutine,而是轮流挂起。如此一来,3阶段就不会造成整个程序的停顿,从而就没有算入到STW时间之中。

Go触发GC的时机

Go的gc触发条件也与JVM的gc有很大区别。JVM通常是堆的使用到达某一阀值,或发生new操作失败时gc。而Go则是当从上次gc以来,新创建的对象大小等于上次gc以后存活下来的对象时触发gc. 这样,每次gc的压力就不会像JVM那么大,STW时间理所当然会短很多,但也牺牲了吞吐量。

Go比Java产生更少的内存垃圾

Go的对象(即struct类型)是可以分配在栈上的。Go会在编译时做静态逃逸分析(Escape Analysis), 如果发现某个对象并没有逃出当前作用域,则会将对象分配在栈上而不是堆上,从而减轻了GC压力。其实JVM也有逃逸分析,但与Go不同的是Java无法在编译时做这项工作,分析是在运行时完成的,这样做一是会占用更多的CPU时间,二是不可能会把所有未逃逸的对象都优化到栈中。

到目前为止,Go的运行效率并没有因为执行的是本地机器码而体现出比Java更好的性能优势,我想这并不怪go, 而是JVM在JIT的帮助下其性能已经非常好了。虽然如此,Go的优化空间会比JVM更大。相信未来Go的性能会不断提升,终究会超过JVM。

你可能感兴趣的:(jvm,Go)