无限for循环内的goroutine。这是一个好习惯吗？

Question

所以我正在编写一段代码：

// Main

for {

    c := make(chan string)

    data := make(map[string]string)

    go doStuff(data,c)

    fmt.Println(<-c)

    time.Sleep(2*time.Second)

}

// doStuff

func doStuff(d map[string]string,ch chan string){

    defer close(ch)

    //Code to make changes to passed data

    ch <-"changes made"

}

它的作用是将映射和通道传递给goroutine，在其中对映射进行了一些更改，它将发送消息，并且在主程序中它将打印并等待另一个修改消息，并且间隔为处理传递给 goroutine 的数据后，直到键盘中断或某些逻辑 2 秒。

我在某个地方觉得这不是有效的方法。所以我的问题是在无限循环中放置一个 goroutine 是否可以，或者有没有更有效的方法来做到这一点？

Answer 1

无限循环本身并没有错。当循环退出条件需要太多命令才能轻松放入 for 条件时，我经常使用 for { ... } 构造。根据我的$GOPATH/src/github.com/目录，这显然是一个非常不完整的样本集，我看到了数百种超出我自己的这样的用途。github.com/docker/docker仅此一项似乎就使用了 454 个这样的无限循环。不太合适的是在循环中创建一个只传递一个值的通道的想法。如果你的 goroutine 总是只返回一个值，那么这个返回值的存在就足以表明 goroutine 已经完成。尽可能重复使用通道，如果您想稍后发送更多数据，请不要关闭它们。显然，在您的情况下，goroutine 无论如何都是毫无意义的，仅用于教育目的。但是考虑一下，如果你愿意的话：package mainimport (&nbsp; "log")func doStuff(datachan <-chan map[string]string, reschan chan<- int) {&nbsp; for {&nbsp; &nbsp; data, ok := <-datachan&nbsp; &nbsp; if !ok {&nbsp; &nbsp; &nbsp; log.Print("Channel closed.")&nbsp; &nbsp; &nbsp; break&nbsp; &nbsp; }&nbsp; &nbsp; log.Printf("Data had %d length: %+v", len(data), data)&nbsp; &nbsp; reschan<-len(data)&nbsp; }&nbsp; return}const workers = 3func main() {&nbsp; var datachan = make(chan map[string]string)&nbsp; var reschan = make(chan int)&nbsp; var inflight = 0&nbsp; var inputs = []map[string]string {&nbsp; &nbsp; map[string]string{ "hi": "world" },&nbsp; &nbsp; map[string]string{ "bye": "space", "including": "moon" },&nbsp; &nbsp; map[string]string{ "bye": "space", "including": "moon" },&nbsp; &nbsp; map[string]string{ },&nbsp; &nbsp; map[string]string{ },&nbsp; }&nbsp; // an inline funciton definition can change inflight within main()'s scope&nbsp; processResults := func (res int) {&nbsp; &nbsp; log.Printf("Main function got result %d", res)&nbsp; &nbsp; inflight--&nbsp; }&nbsp; // start some workers&nbsp; for i := 0; i < workers; i++{&nbsp; &nbsp; go doStuff(datachan, reschan)&nbsp; }&nbsp; for _, data := range inputs {&nbsp; &nbsp; &nbsp; //Select allows reading from reschan if datachan is not available for&nbsp; &nbsp; &nbsp; // writing, thus freeing up a worker to read from datachan next loop&nbsp; &nbsp; &nbsp; written := false&nbsp; &nbsp; &nbsp; for written&nbsp; != true {&nbsp; &nbsp; &nbsp; &nbsp; select {&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; case res := <-reschan:&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; processResults(res)&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; case datachan <- data:&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; inflight++&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; written = true&nbsp; &nbsp; &nbsp; &nbsp; }&nbsp; &nbsp; &nbsp; }&nbsp; }&nbsp; close(datachan)&nbsp; for inflight > 0 {&nbsp; &nbsp; processResults(<-reschan)&nbsp; }}输出：2020/10/31 13:15:08 Data had 1 length: map[hi:world]2020/10/31 13:15:08 Main function got result 12020/10/31 13:15:08 Data had 0 length: map[]2020/10/31 13:15:08 Main function got result 02020/10/31 13:15:08 Data had 0 length: map[]2020/10/31 13:15:08 Channel closed.2020/10/31 13:15:08 Main function got result 02020/10/31 13:15:08 Data had 2 length: map[bye:space including:moon]2020/10/31 13:15:08 Channel closed.2020/10/31 13:15:08 Main function got result 22020/10/31 13:15:08 Data had 2 length: map[bye:space including:moon]2020/10/31 13:15:08 Channel closed.2020/10/31 13:15:08 Main function got result 2for {在这里，我添加了一些结构来说明和的一些更常见的用法close(chan)。我在工作goroutines 中使用了一个潜在的无限循环，其中有 3 个（故意创建的比使用的多）。我数了数我给频道写了多少次，以确保我阅读了每一个回复。当主 goroutine 结束时，所有其他 goroutine 都会被毫不客气地杀死，所以我要确保让它们完成。计算结果是一种简单的方法。我还演示了正确使用close(chan). 虽然在使用后关闭通道（例如您所做的）是不正确的，但通常没有必要这样做，因为在所有对它们的引用无论如何都消失后，打开的通道将被垃圾收集。( https://stackoverflow.com/questions/8593645/is-it-ok-to-leave-a-channel-open#:~:text=It's%20OK%20to%20leave%20a,that%20no%20more% 20data%20 关注。）close(chan)通常用于告诉频道阅读器该频道上没有更多数据可用。&nbsp; &nbsp; data, ok := <-datachan第二个值，一个布尔值，将告诉我们是否读取data或通道实际上已关闭和耗尽。所以这是确保我们已经处理所有通道的接收器部分。因为我使用select，这段代码可以处理inputs任意长度的，带有一组静态工作人员。这些通道都没有缓冲 - 读者必须在阅读才能让作者写入。因此，在尝试向该阅读器发送另一个数据输入之前，我需要确保从工作人员那里收到任何结果。使用select使这变得微不足道：操作在首先准备好的任何通道上成功（如果两个通道都准备好，则随机选择一个选项 - 在这种情况下完美运行）。for {,close(chan)和select, 总之，在向 goroutine worker bools 发送未知数量的输入时，它们可以很好地协同工作。一些最后的笔记。在现实世界中，通常会使用https://gobyexample.com/waitgroups而不是手动实现这一切。这个概念大体上是相同的，但它更少跟踪事物并导致更清晰的代码。我自己实现了它，所以概念很清楚。最后，你会注意到在程序结束之前无法保证工作 goroutines 看到关闭的通道。实际上，从技术上讲，可能不会从所有 goroutine 中记录“关闭通道”消息。但是使用inflight计数器确保我得到了他们的结果，即使他们没有机会观察通道的关闭。当应用程序随着时间的推移继续运行多批工作人员时，关闭通道和退出工作人员更有意义 - 如果我们没有通知他们关闭，但后来创建了更多工作人员，这将导致内存泄漏，就像那些工作人员一样继续等待永远不会到来的输入。或者，对多批请求使用同一组工作人员并不罕见。