与 Python 等其他语言相比，golang 中的 WaitGroup 是否倒退了一步？

Question

我对 golang 很陌生，我正在尝试 goroutine，虽然并发运行很容易，但我对 golang 使用WaitGroup.据我所知，goroutine 需要引用 WaitGroup 对象才能调用Done()，这意味着，我必须要么让 goroutine 接受一个WaitGroup对象，要么让WaitGroup对象成为 goroutine 的全局对象。但是在 Python 等其他语言中，您称之为thread.join()，“控制”部分位于线程代码之外。就像我说的，我对 golang 很陌生，我不知道为什么它是这样设计的，有人可以对这方面有所了解吗？更新：我希望争论不是基于“Goroutine vs Thread”，在一天结束时，他们都试图实现（某种）“并发”，我的问题更多是关于控制程序流程。

Answer 1

hobbs 和 creker 的回答尤其出色，但我觉得还有很多话要说。

有一个非常普遍的概念，即 WaitGroup 是管理多个 goroutines的方式——它肯定是常用的，在许多情况下甚至是惯用的。你知道吗？能够调用 thread.join() 确实可能比处理 WaitGroups 更好，因为它只是在等待之前启动的一堆线程/goroutines。

但有这么多到比Go的并发模型。

Goroutines 专门设计为没有所有权、层次结构或句柄的概念。他们独立、平等并负责结束自己的执行。这与强大的并发原语相结合，赋予 Go 模型几乎无与伦比的灵活性。

因此，如果您发现自己几乎每次使用 goroutine 时都在使用 WaitGroup，那么您可能没有在建模和构建程序时利用并发性- 更有可能您只是在使用 goroutine 来并行化计算。

为了更直接地回答您的问题，与 thread.join() 之类的东西相比，WaitGroups 相当原始，但是原始的低级构建块对于 Go 的并发模型更有用。毕竟，goroutines 不是线程，它们的使用方式并不完全相同。

Answer 2

为什么它是这样设计的

这实际上已经被 golang 团队解释了很多次——为什么我们不能杀死 goroutines，为什么它们没有我们可以读取的 ID，为什么我们不能像线程的Join.

它被解释了多次，但我只能找到这个。基本上，作者不希望你依赖线程局部性——锁定特定的线程/goroutine，只为它拥有一个本地存储等等。当你没有任何方法知道你实际上在哪个 goroutine 中运行您被迫以真正并发的方式设计您的应用程序。您的代码由真正独立的部分组成，这些部分同时运行，它们并不关心具体如何。您不在乎哪个 goroutine 接收您的代码，也不在乎哪个操作系统线程正在运行您的代码。这就是通道、选择和其他原语的用武之地。它们可以帮助您以这种方式构建应用程序。而且我相信它不会就此止步。

Answer 3

不，这只是不同的事情做不同的事情。它们甚至没有真正的可比性，因为 aWaitGroup本质上等待多个事物（并且可以在其生命周期内添加事物）而 python 线程join总是只等待那一件事。

也就是说，Go 的库更多地是为您提供做更高级的事情所需的原始东西，而 Python 的库更多的是“包含电池”的理念。使用 Go 给你的东西，你可以创建一个有点像 python 的类型Thread。这可能不是使用 Go 的最佳方式，但如果您愿意，可以使用工具来完成它。然而，标准库不会对这样的事情进行标准化。