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

问题描述

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

// 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的数据后出现某种逻辑为止。

我在某处觉得这不是有效的方法。所以我的问题是将goroutine放置在无限for循环中是否可以，还是有更有效的方法呢？

解决方法

无限循环本身没有什么问题。当循环退出条件需要太多命令以轻松放入for条件时，我经常使用{...}构造。

基于我的$GOPATH/src/github.com/目录，这显然是一个不完整的示例集，我看到了除我自己之外的数百种此类用法。仅github.com/docker/docker似乎就使用了454个这样的无限循环。

不太恰当的想法是在仅传递一个值的循环中创建通道。如果goroutine始终仅返回一个值，则该返回值的存在足以表明该goroutine已完成。尽可能重用频道，如果以后要发送更多数据，请不要关闭频道。

很显然，就您而言，goroutine毫无意义，仅出于教育目的。但是，如果您愿意的话，请考虑一下：

package main

import (
  "log"
)

func doStuff(datachan <-chan map[string]string,reschan chan<- int) {
  for {
    data,ok := <-datachan
    if !ok {
      log.Print("Channel closed.")
      break
    }
    log.Printf("Data had %d length: %+v",len(data),data)
    reschan<-len(data)
  }
  return
}

const workers = 3

func main() {
  var datachan = make(chan map[string]string)
  var reschan = make(chan int)
  var inflight = 0
  var inputs = []map[string]string {
    map[string]string{ "hi": "world" },map[string]string{ "bye": "space","including": "moon" },map[string]string{ },}
  // an inline funciton definition can change inflight within main()'s scope
  processResults := func (res int) {
    log.Printf("Main function got result %d",res)
    inflight--
  }
  // start some workers
  for i := 0; i < workers; i++{
    go doStuff(datachan,reschan)
  }
  for _,data := range inputs {
      //Select allows reading from reschan if datachan is not available for
      // writing,thus freeing up a worker to read from datachan next loop
      written := false
      for written  != true {
        select {
          case res := <-reschan:
            processResults(res)
          case datachan <- data:
            inflight++
            written = true
        }
      }
  }
  close(datachan)
  for inflight > 0 {
    processResults(<-reschan)
  }
}

输出：

2020/10/31 13:15:08 Data had 1 length: map[hi:world]
2020/10/31 13:15:08 Main function got result 1
2020/10/31 13:15:08 Data had 0 length: map[]
2020/10/31 13:15:08 Main function got result 0
2020/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 0
2020/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 2
2020/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 2

在这里，我添加了一些结构来说明for {和close(chan)的一些更常见用法。

我在 worker 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%20follows.）

close(chan)通常用于告知频道读者该频道将不再有可用数据。

    data,ok := <-datachan

第二个值（布尔值）将告诉我们是读取data还是通道实际上已关闭并耗尽。因此，这是确保我们已处理完所有通道的接收器部分。

因为我使用select，所以这段代码可以处理一组静态的inputs任意长度的代码。这些通道均未缓冲-读取器必须正在读取，写入器才能写入。因此，在尝试向该阅读器发送另一个数据输入之前，我需要确保从工作人员接收任何结果。使用select变得很简单：在首先准备好任何通道的情况下，操作都会成功（如果两个通道均已就绪，则随机选择一个选项-在这种情况下可以正常使用）。

总之，

for {，close(chan)和select在向goroutine工人布尔发送未知数量的输入时可以很好地协同工作。

一些最后的笔记。在现实世界中，通常会使用https://gobyexample.com/waitgroups来代替手动完成所有操作。这个概念大体上是相同的，但是要跟踪事物并产生更清晰的代码要少得多。我自己实现了它，所以概念很清楚。

最后，您会注意到没有任何保证可以保证辅助程序在程序结束之前可以看到关闭的通道。实际上，从技术上讲，可能不是所有goroutine都会记录“ closed channel”消息。但是使用inflight计数器可以确保我得到他们的结果，即使他们没有机会观察通道的关闭也是如此。当应用程序将随着时间的推移继续运行多个批次的工作程序时，关闭通道并退出工作程序更有意义-如果我们不给他们通知关闭的消息，但是后来又创建了更多工作程序，则将导致内存泄漏，因为这些工作程序会继续等待永远不会出现的输入。或者，对多批请求使用同一组工作程序也很常见。

channels concurrency concurrency go goroutine