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

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性能与使用问题。总结来说：

通过sharding分区减少contention是优化常用手段 做的再快也不可能比什么也不做更快，减少不必要操作比优化这个操作有效 多用Go内建的benchmark功能，数据为导向的做决策 官方提倡的东西肯定有他的道理，但在合适的情况下，需懂得如何无视某些官方的提倡

后续将再推出针对Go内存性能优化的文章，敬请期待。在阅读完此干货软文后，也请大家访问Dragonboat项目并点star支持！谢谢阅读。

（编辑：ASP站长网）