大规模Go项目几乎必踏的几个大坑 - 实例分享

Goroutine的最大卖点是量大价廉使用方便，一个程序里轻松开启万把个Goroutine基本都不用考虑其本身的代价......一切似乎很美好，直到系统内类型众多的Goroutine开始泄漏。也许是因为Goroutine的特性，它在Go程序里的使用的频度密度远超线程在Java/C++程序中情况，同时用户思维中Goroutine简单易用代价低的概念根深蒂固、与生俱来，无形中更容易放松对资源管理的考虑，因此更容易发生Goroutine泄漏情况。Dragonboat的经验是Goroutine泄漏的概率不比内存泄漏少。

Dragonboat从实现之初就开始使用Goroutine泄漏检查，具体的泄漏检查的实现是来自CockroachDB的一小段代码。效果方面，这个小工具发现过Dragonboat及其依赖的第三方库里多个goroutine泄漏问题，而使用上，在各内建的测试中，只需一行便能完成调用得到结果，绝对是费效比完美。

实现上它也特别简单，就是前后两次分别抓stacktrace，解析出进程里所有的Goroutine ID并对比是否测试运行结束后产生了多余的滞留在系统中的Goroutine。官方虽然不倡导对Goroutine ID做任何操作，但此类仅在测试中仅针对Goroutine泄漏的特殊场景的使用，应该不拘泥于该约束，这就如同官方不怎么推荐用sync/atomic一个道理。

总结

基于Dragonboat的几个具体例子，本文分享了几个常见的Go性能与使用问题。总结来说：

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!