Go 1.4+垃圾收集器计划与路线图

自从Go语言于2009年11月对外宣布以来，短短几年时间，这门语言发展迅猛，性能也在不断提升，而垃圾收集器的改进正是其中的重要一环。 在[Go 1.1](http://golang.org/doc/go1.1)中，Go语言引入了并行垃圾收集器，可以减少程序在多CPU上运行时的延迟；同时垃圾收集也更为精确了，以牺牲较少的CPU时间为代价，换来了堆内存的显著减少。到了今年6月份发布的[Go 1.3](http://golang.org/doc/go1.3)中，精确性有所改进，又实现了检查栈上的值时的精确性。 那后续版本中，垃圾收集器会有怎样的变化呢？Richard L. Hudson近日撰文介绍了[Go 1.4+垃圾收集器的计划和路线图](http://golang.org/s/go14gc)。 文中指出，计划于2015年6月发布的Go 1.5的GC的目标是减少延迟，从而使Go语言能够满足对响应时间要求比较高的系统。该版本希望将GC延迟限制在10ms以内，而且每50ms保证Go应用代码有40ms以上的执行时间。实现上将考虑一种混合式的Stop-the-World（STW）/并发垃圾收集器（CGC）。CGC的主要工作将在一个或多个专用的CPU上完成，而应用代码则在其他CPU上执行。 文中提到，用繁复的垃圾收集术语来讲，现在为Go 1.5提议的垃圾收集器是一种“非分代的、非移动的、并发的、三色的标记清除垃圾收集器”。像分代，JVM的Hotspot实现、Google的v8 JavaScript引擎等采用的就是分代垃圾收集技术。Hotspot中的堆区分为年轻代和老年代，不同的代会针对性地选择不同的收集算法。移动对象是复制类垃圾收集算法常用的一种操作，不过移动有一个缺点，需要修改指向被复制对象的所有指针。三色是GC跟踪过程中的一种标记策略，认定为活对象的标记为黑色，可能是死对象的标记为白色；可以参考这个[帖子](http://stackoverflow.com/questions/2364274/tri-color-incremental-updating-gc-does-it-need-to-scan-each-stack-twice)。正在处理或者需要重新处理的标记为灰色。标记完成之后，仍为白色的则是垃圾。具体算法，感兴趣的读者可以参考《The Garbage Collection Handbook: The Art of Automatic Memory Management》一书。低延迟意味着会影响吞吐量，但是影响程度如何，还有待观察。文中指出，随着CPU核数的增加，拿出一个或多个核来执行GC，应该不是很大的问题。 至于Go 1.6这个将于2015年12月发布的版本，其GC将根据1.5版本的经验、用户反馈和使用案例来改进。1.6版本很可能会加入指针碰撞分配（bump pointer allocation）和分代复制收集技术。 为配合垃圾收集器的改造，1.4版本中将去掉使用了Go指针及各种与并发或复制收集器不兼容的不安全指针结构的C运行时代码，用户也需要去掉其代码中的不兼容结构。 相关讨论可以参阅[golang-dev邮件列表](https://groups.google.com/forum/#!msg/golang-dev/pIuOcqAlvKU/C0wooVzXLZwJ)。HackerNews上的[讨论](https://news.ycombinator.com/item?id=8148666)也很热烈。有些网友介绍了实际使用体验。感兴趣的读者可以参考。