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

Question

我对golang非常陌生，我正在尝试goroutine，虽然并发运行很容易，但golang使用WaitGroup“连接线程”的方式有点惊讶。在

据我所知，goroutine需要引用WaitGroup对象来调用Done()，这意味着，我必须使goroutine接受WaitGroup对象，或者使{}对象成为goroutine的全局对象。在

但是在Python等其他语言中，调用thread.join()，“控制”部分位于线程代码之外。在

就像我说的，我对高朗很陌生，我不知道为什么它是这样设计的，有人能解释一下这个方面吗？在

更新： 我希望这场争论不是基于“Goroutine vs Thread”，最终他们都试图实现（某种程度上的）“并发”，我的问题更多的是关于程序流的控制。在

Answer 1

霍布斯和克里克的回答尤其出色，但我觉得还有更多的话要说。在

WaitGroup是管理多个goroutine的一种非常常见的概念，它当然是常用的，甚至在许多情况下都是惯用的。你知道吗？能够打电话螺纹连接（）可能确实比处理WaitGroups要好，因为它只是等待前面启动的一堆线程/goroutine。在

但是，togo的并发模型远不止于此。在

goroutine是专门为而不是设计的拥有所有权、层次或句柄的概念。他们是独立的，平等的，有责任结束自己的处决。这与强并发原语相结合，使Go的模型具有几乎无与伦比的灵活性。在

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

为了更直接地回答你的问题，WaitGroups与螺纹连接（），但是原始的低级构建块在Go的并发模型中更有用。毕竟，goroutine不是线程，它们的使用方式也不完全相同。在

Answer 2

why it was designed this way

golang团队已经解释了很多次了-为什么我们不能杀死goroutine，为什么它们没有我们可以读取的ID，为什么我们不能像thread的Join那样显式地等待goroutine。在

解释了多次，但我只能找到this。基本上，作者不希望你依赖于线程的局部性——锁定一个特定的线程/goroutine，只为它提供一个本地存储等等。当你没有任何方法知道你实际上在运行哪个goroutine时，你就不得不以一种真正一致的方式来设计你的应用程序。您的代码是由真正独立的并发运行的片段组成的，它们并不关心具体如何运行。你不在乎哪个goroutine获取你的代码，也不在乎哪个操作系统线程在运行你的代码。这就是通道、选择和其他原语的来源。它们帮助您以这种方式构建应用程序。我相信这不会就此结束。在

Answer 3

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

也就是说，Go的库更多的是为您提供完成更高级的事情所需的原始事物，而Python的库则更多的是一种“包含电池”的理念。使用Go提供的功能，您可以创建一个相当类似于pythonThread的类型。也许这并不是最好的利用围棋的方法，但是如果你想的话，你可以使用这些工具。然而，标准库不会对这种事情进行标准化。在