Go 中的 Goroutine + Channel 真的能减少并发 Bug 吗？

Go 目前正在通过新的并发原语（concurrency primitives）goroutine 和 channel 试图简化并发编程并减少报错。但是，实际情况怎么样呢？两位来自宾夕法尼亚州立大学和普渡大学的研究员 Yiying Zhang [1] 和 Linhai Song [2] 对 Go 中的 并发 bug 在真实场景的情况 [3] 进行了研究。（PDF 可以下载：https://songlh.github.io/paper/go-study.pdf）

共享内存与 channel 的对比

该研究首先分析了 Go 并发原语在用 Go 构建的大项目中的使用分布情况，包括共享内存类型（Mutex，RWMutex，atomic 和 condition 变量）和新的并发类型 channel：

从上图来看，各种并发原语在各个项目中使用分布情况在时间的跨度上基本稳定，因此该研究的结论可能在接下来的几年中仍然有效。基于此，研究员们系统分析了以下流行 Go 项目中的并发 bug 以及它们的原因和修复方式：

taxonomy

研究发现

这项研究发现，大多数开发人员认为 channel 不会像其他常用同步方法那样不可靠，但其实并不是这样：

结论2：与通常的看法相反，消息传递比共享内存可能导致更多的阻塞 bug 。希望大家注意消息传递带来的潜在危险，我们也会进一步研究该领域中的错误检测机制。

尽管如此，该研究也表明 channel 的前景很好：

发现9：共享内存同步仍然是主要的非阻塞性 bug 的修复方法，但是 channel 不仅被广泛地用于修复与 channel 相关的 bug，而且还用于修复共享内存的 bug。

这项研究清楚地表明，新的原语不会减少并发环境中的 bug。但是，如果更好地了解 channel 和 goroutines，可以避免大多数这类问题：

发现6：我们研究中的大多数阻塞 bug（传统的共享内存 bug 和消息传递 bug）都可以通过简单的解决方案来解决。

例如 Docker 中的这个问题：

data-race

运行 go vet 命令可以避免上面这种错误。

对Go生态系统的贡献

在研究期间，研究员们还发现有可能开发出更好的静态代码检查器：

结论3： 由于 Go 中的阻塞 bug 的原因与其修复方法密切相关，并且修复方法不复杂，开发出全自动或半自动化的工具来修复 Go 的阻塞 bug 是很有希望的。

根据 Go 社区多年来的经验，运行时的检测工具也可以得到改进：

结论4：仅仅用死锁检测器在运行时检测 Go 阻塞 bug 不是很有效。未来的研究应侧重于构建新颖的阻塞 bug 检测技术，例如，结合使用静态和动态阻塞模式的检测。

基于以上这些发现，项目负责人 Ziheng Liu 带领研究员们开始研究新的代码分析器。以 SSA [4] 软件包为基础，该新式代码分析器通过在 GraphQL  Go 项目中发现了 bug [5] 证明了它的有效性。这个新式代码分析器预计于2020年1月发布。

有关该研究的更多信息，请访问该研究文献 Github [6] 地址。

via: https://medium.com/a-journey-with-go/go-concurrency-bugs-in-go-7d3677a1f2a2

作者： Vincent Blanchon [7] 译者： zhiyu-tracy-yang [8] 校对： zhoudingding [9]

本文由 GCTT [10] 原创编译， Go 中文网 [11] 荣誉推出

参考资料