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()捕获,是 Go 1.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连接真的关闭了吗?
按照官方文档对标准库中的httpclient包的说明,在使用时需要主动调用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
以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网
猜你喜欢:- 记vue使用swiper插件遇到的坑
- 使用Spring Data Jpa遇到问题汇总
- 总结:使用MyBatis Generator时遇到的坑
- nagios使用nrpe监控磁盘遇到的问题
- 使用Hibernate、JPA、Lombok遇到的有趣问题
- 在 forEach 中使用 async/await 遇到的问题
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。