[使用Golang时遇到的一些坑 - PaaS小魔仙 - 博客园]

使用Golang时遇到的一些坑 - PaaS小魔仙 - 博客园

1、 【致命】不是所有Panic都能捕获

我们知道Golang给开发人员提供recover()机制,对堆栈异常(panic)进行捕获并自定义其处理逻辑。下面举个例子:

构造一个除0的异常场景:

输出结果:

我们看到程序正常退出,没有异常,说明recover()按照预期捕获到panic异常;但不是所有panic都能通过recover()捕捉到的,比如:并发操作map实例。

构造并发操作map的场景:

输出结果:

以上结果可知,我们不能单纯依靠recover()解决函数内部所有panic异常,应该做到以下几点:

a) 通过编写代码校验,防止能预期到的panic,比如:空指针引用的指针判断。

b) 对于无法预期的panic,使用recover()捕获并加以处理。

c) 使用map时,必须要考虑是否存在并发读写场景,存在时,应使用ConcurrentMap组件或自己加sync.RWMutex进行加锁保护。

相关参考:

关于并发读写map导致的panic无法使用recover()捕获,是Go1.6增加的一个特性,https://golang.org/doc/go1.6#runtime;

当然这个并非是唯一一个无法通过recover()捕获的场景,还有可能Go本身的bug,https://github.com/golang/go/issues/21717;这个Bug在Go1.9.2才修复

2、 【严重】小心Map的内存泄露

大部分Golang程序做业务缓存实现时,都使用了map,看以下代码片段,简单模拟了这种使用场景:

增加环境变量GODEBUG=gctrace=1,运行可见,即使代码逻辑清空了map,但进程内存使用并没有像预期那样“实报实销”:

应如何解决:定期替换成新的map,释放旧的map对象。

3、 【提示】不是每次Map遍历都能得到相同排序的集合

经常遇到一些业务场景,需要将map的所有元素打印输出,在Golang里面实现是非常简单的,一个for range就可以实现,但结果却有点出人意料:

输出结果:

两次遍历的结果均不相同,这是为什么呢?这是Golang故意增加的一个随机数导致的,https://blog.golang.org/go-maps-in-action;所以如果对结果一致性有要求的业务逻辑,就不能简单的遍历map了,可以这样实现:

4、 【严重】客户端执行Response.Body.Close()后HTTP连接真的关闭了吗?

按照官方文档对标准库中的http client包的说明,在使用时需要主动调用Response.Body.Close()将连接关闭,但并不说明只要写了这句话就能关闭连接的。看看以下场景:

执行后,统计了下连接数,发现大量TIME_WAIT连接没有按预期回收,看来Response.Body.Close()没生效。

我们把代码调整如下:

再看看连接数统计:

为什么?以上是个较为特殊的场景,业务只关心请求的响应码,并不关心响应体,所以没有加入读取resp.Body的代码。可以看到此时关闭Body读取数据通道,会导致Golang底层没有真正关闭连接。要解决这个这种场景出现的连接泄露问题,需要在Close前额外加入io.Copy(ioutil.Discard, resp.Body),来完成TCP响应体读取流程。

Go语言未来的前景很不错,而在国内的大厂中,华为云对此的支持还是可以的,在其微服务应用平台、微服务引擎中开放了Go语言的服务框架。

目前,华为云有一个关于微服务的活动,有想应用服务微服务化需求的朋友可以考虑试用一下!

https://activity.huaweicloud.com/cse/index.html?dfk


原网址: 访问