在无限循环中使用goroutine：是明智的选择吗？

本文探讨了在无限循环中使用 goroutine 的可行性，并提供了一种替代方案。作者认为，无限循环本身并不存在问题，但建议避免在循环中创建只传递一个值的通道。相反，作者提供了示例代码，展示了如何使用通道、goroutine 和 select 来处理未知数量的输入。此外，文章强调了关闭通道和退出工作协程的重要性，以避免内存泄漏和确保所有结果都已接收。

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

// 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，其中在映射中进行了一些更改，它将发送消息，在 main 中它将打印并等待另一个修改消息，这样下去间隔 2 秒，直到键盘中断或处理传递给 goroutine 的数据后进行一些逻辑。

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

解决方案

无限循环本身并没有什么问题。当循环退出条件需要太多命令才能轻松放入 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{ "bye": "space", "including": "moon" },
    map[string]string{ },
    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 goroutine 中使用了一个潜在的无限循环，其中有 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 中记录。但是使用 inflight 计数器可以确保我得到他们的结果，即使他们没有机会观察通道的关闭。当应用程序随着时间的推移继续运行多批工作人员时，关闭通道和退出工作人员更有意义 - 如果我们没有向他们发出关闭通知，但随后创建了更多工作人员，这将导致内存泄漏，因为这些工作人员将继续等待永远不会到来的输入。或者，使用同一组工作人员来处理多批请求也很常见。

今天带大家了解了的相关知识，希望对你有所帮助；关于Golang的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~