[转]Go 的垃圾回收机制在实践中有哪些需要注意的地方？

来源：http://www.zhihu.com/question/21615032

不想看长篇大论的，这里先给个结论，go的gc还不完善但也不算不靠谱，关键看怎么用，尽量不要创建大量对象，也尽量不要频繁创建对象，这个道理其实在所有带gc的编程语言也都通用。

想知道如何提前预防和解决问题的，请耐心看下去。

先介绍下我的情况，我们团队的项目《仙侠道》在7月15号第一次接受玩家测试，这个项目的服务端完全用Go语言开发的，游戏数据都放在内存中由go 管理。

在上线测试后我对程序做了很多调优工作，最初是稳定性优先，所以先解决的是内存泄漏问题，主要靠memprof来定位问题，接着是进一步提高性能，主要靠cpuprof和自己做的一些统计信息来定位问题。

调优性能的过程中我从cpuprof的结果发现发现gc的scanblock调用占用的cpu竟然有40%多，于是我开始搞各种对象重用和尽量避免不必要的对象创建，效果显著，CPU占用降到了10%多。

但我还是挺不甘心的，想继续优化看看。网上找资料时看到GOGCTRACE这个环境变量可以开启gc调试信息的打印，于是我就在内网测试服开启了，每当go执行gc时就会打印一行信息，内容是gc执行时间和回收前后的对象数量变化。

我惊奇的发现一次gc要20多毫秒，我们服务器请求处理时间平均才33微秒，差了一个量级别呢。

于是我开始关心起gc执行时间这个数值，它到底是一个恒定值呢？还是更数据多少有关呢？

我带着疑问在外网玩家测试的服务器也开启了gc追踪，结果更让我冒冷汗了，gc执行时间竟然达到300多毫秒。go的gc是固定每两分钟执行一次，每次执行都是暂停整个程序的，300多毫秒应该足以导致可感受到的响应延迟。

所以缩短gc执行时间就变得非常必要。从哪里入手呢？首先，可以推断gc执行时间跟数据量是相关的，内网数据少外网数据多。其次，gc追踪信息把对象数量当成重点数据来输出，估计扫描是按对象扫描的，所以对象多扫描时间长，对象少扫描时间短。

于是我便开始着手降低对象数量，一开始我尝试用cgo来解决问题，由c申请和释放内存，这部分c创建的对象就不会被gc扫描了。

但是实践下来发现cgo会导致原有的内存数据操作出些诡异问题，例如一个对象明明初始化了，但还是读到非预期的数据。另外还会引起go运行时报申请内存死锁的错误，我反复读了go申请内存的代码，跟我直接用c的malloc完全都没关联，实在是很诡异。

我只好暂时放弃cgo的方案，另外想了个法子。一个玩家有很多数据，如果把非活跃玩家的数据序列化成一个字节数组，就等于把多个对象压缩成了一个，这样就可以大量减少对象数量。

我按这个思路用快速改了一版代码，放到外网实际测试，对象数量从几百万降至几十万，gc扫描时间降至二十几微秒。

效果不错，但是要用玩家数据时要反序列化，这个消耗太大，还需要再想办法。

于是我索性把内存数据都改为结构体和切片存放，之前用的是对象和单向链表，所以一条数据就会有一个对象对应，改为结构体和结构体切片，就等于把多个对象数据缩减下来。

结果如预期的一样，内存多消耗了一些，但是对象数量少了一个量级。

其实项目之初我就担心过这样的情况，那时候到处问人，对象多了会不会增加gc负担，导致gc时间过长，结果没得到答案。

现在我填过这个坑了，可以确定的说，会。大家就不要再往这个坑跳了。

如果go的gc聪明一点，把老对象和新对象区别处理，至少在我这个应用场景可以减少不必要的扫描，如果gc可以异步进行不暂停程序，我才不在乎那几百毫秒的执行时间呢。

但是也不能完全怪go不完善，如果一开始我早点知道用GOGCTRACE来观测，就可以比较早点发现问题从而比较根本的解决问题。但是既然用了，项目也上了，没办法大改，只能见招拆招了。

总结以下几点给打算用go开发项目或已经在用go开发项目的朋友：
1、尽早的用memprof、cpuprof、GCTRACE来观察程序。
2、关注请求处理时间，特别是开发新功能的时候，有助于发现设计上的问题。
3、尽量避免频繁创建对象(&abc{}、new(abc{})、make())，在频繁调用的地方可以做对象重用。
4、尽量不要用go管理大量对象，内存数据库可以完全用c实现好通过cgo来调用。

手机回复打字好累，先写到这里，后面再来补充案例的数据。

数据补充：

图1，7月22日的一次cpuprof观测，采样3000多次调用，数据显示scanblock吃了43.3%的cpu。

图2，7月23日，对修改后的程序做cpuprof，采样1万多次调用，数据显示cpu占用降至9.8%

数据1，外网服务器的第一次gc trace结果，数据显示gc执行时间有400多ms，回收后对象数量1659922个：

gc13(1): 308+92+1 ms , 156 -> 107 MB 3339834 -> 1659922 (12850245-11190323) objects, 0(0) handoff, 0(0) steal, 0/0/0 yields

数据2，程序做了优化后的外网服务器gc trace结果，数据显示gc执行时间30多ms，回收后对象数量126097个：

gc14(6): 16+15+1 ms, 75 -> 37 MB 1409074 -> 126097 (10335326-10209229) objects, 45(1913) handoff, 34(4823) steal, 455/283/52 yields

示例1，数据结构的重构过程：

最初的数据结构类似这样

// 玩家数据表的集合
type tables struct {tableA *tableAtableB *tableBtableC *tableC// ...... 此处省略一大堆表
}// 每个玩家只会有一条tableA记录
type tableA struct {fieldA intfieldB string
}// 每个玩家有多条tableB记录
type tableB struct {xxoo intooxx intnext *tableB  // 指向下一条记录
}// 每个玩家只有一条tableC记录
type tableC struct {id intvalue int64
}

最初的设计会导致每个玩家有一个tables对象，每个tables对象里面有一堆类似tableA和tableC这样的一对一的数据，也有一堆类似tableB这样的一对多的数据。

假设有1万个玩家，每个玩家都有一条tableA和一条tableC的数据，又各有10条tableB的数据，那么将总的产生1w (tables) + 1w (tableA) + 1w (tableC) + 10w (tableB)的对象。

而实际项目中，表数量会有大几十，一对多和一对一的表参半，对象数量随玩家数量的增长倍数显而易见。

为什么一开始这样设计？

1、因为有的表可能没有记录，用对象的形式可以用 == nil 来判断是否有记录
2、一对多的表可以动态增加和删除记录，所以设计成链表
3、省内存，没数据就是没数据，有数据才有对象

改造后的设计：

// 玩家数据表的集合
type tables struct {tableA tableAtableB []tableBtableC tableC// ...... 此处省略一大堆表
}// 每个玩家只会有一条tableA记录
type tableA struct {_is_nil boolfieldA intfieldB string
}// 每个玩家有多条tableB记录
type tableB struct {_is_nil boolxxoo intooxx int
}// 每个玩家只有一条tableC记录
type tableC struct {_is_nil boolid intvalue int64
}

一对一表用结构体，一对多表用slice，每个表都加一个_is_nil的字段，用来表示当前的数据是否是有用的数据。

这样修改的结果就是，一万个玩家，产生的对象总量是 1w (tables) + 1w ([]tablesB)，跟之前的设计差别很明显。

但是slice不会收缩，而结构体则是一开始就占了内存，所以修改后会导致内存消耗增大。

参考链接：

go的gc代码，scanblock等函数都在里面：
http://golang.org/src/pkg/runtime/mgc0.c

go的runtime包文档有对GOGCTRACE等关键的几个环境变量做说明：
http://golang.org/pkg/runtime/

如何使用cpuprof和memprof，请看《Profiling Go Programs》：
http://blog.golang.org/profiling-go-programs

我做的一些小试验代码，优化都是基于这些试验的数据的，可以参考下：
https://github.com/realint/labs/tree/master/src

[转]Go 的垃圾回收机制在实践中有哪些需要注意的地方？相关推荐

详解JVM内存管理与垃圾回收机制2 - 何为垃圾
随着编程语言的发展,GC的功能不断增强,性能也不断提高,作为语言背后的无名英雄,GC离我们的工作似乎越来越远.作为Java程序员,对这一点也许会有更深的体会,我们不需要了解太多与GC相关的知识,就能很 ...
python有向图_Python 中的垃圾回收机制
一.概述 python采用的是引用计数机制为主,标记-清除和分代收集(隔代回收)两种机制为辅的策略. 现在的高级语言如java,c#等,都采用了垃圾收集机制,而不再是c,c++里用户自己管理维护内存的 ...
面试必会系列 - 1.6 Java 垃圾回收机制
本文已收录至 Github(MD-Notes),若博客中有图片打不开,可以来我的 Github 仓库:https://github.com/HanquanHq/MD-Notes,涵盖了互联网大厂面试必 ...
详解JVM内存管理与垃圾回收机制5 - Java中的4种引用类型
在Java语言中,除了基础数据类型的变量以外,其他的都是引用类型,指向各种不同的对象.在前文我们也已经知道,Java中的引用可以是认为对指针的封装,这个指针中存储的值代表的是另外一块内存的起始地址(对 ...
.NET垃圾回收机制转
在.NET Framework中,内存中的资源(即所有二进制信息的集合)分为"托管资源"和"非托管资源".托管资源必须接受.NET Framework的CLR( ...
go语言垃圾回收机制详解
Golang GC 垃圾回收机制详解独一无二的小个性 https://blog.csdn.net/u010649766/article/details/80582153 摘要在实际使用 go 语言 ...
深入理解Java虚拟机——JVM垃圾回收机制和垃圾收集器详解
一:概述说起垃圾回收(Garbage Collection,GC),很多人就会自然而然地把它和Java联系起来.在Java中,程序员不需要去关心内存动态分配和垃圾回收的问题,顾名思义,垃圾回收就是释 ...
Python 内存管理与垃圾回收机制
python python内存的泄露和溢出前言一.内存泄露和溢出二.垃圾回收机制 1.引用计数机制 2.标记清除 3.分代回收三.垃圾回收总结前言虽然在做科研的路上并没有遇到内存方面的问 ...
通过强弱软虚四种引用进一步了解垃圾回收机制
在Java对象里,有强弱软虚四种引用,它们都和垃圾回收流程密切相关,在项目里,我们可以通过合理地使用不同类型的引用来优化代码的内存使用性能. 指向通过new得到的内存空间的引用叫强引用.比如有Stri ...

[转]Go 的垃圾回收机制在实践中有哪些需要注意的地方？

[转]Go 的垃圾回收机制在实践中有哪些需要注意的地方？相关推荐

最新文章

热门文章