在 goroutines 中启动 goroutines 是否可以接受？

Question

我现在正在学习 Go，我的第一个项目是一个简单的 ping 脚本。本质上，我想 ping 一堆 url，并在每个响应时等待 XXX 秒，然后再次 ping。这是删减的代码：

func main() {
    //  read our text file of urls
    f, err := ioutil.ReadFile(urlFile)
    if err != nil {
        log.Print(err)
    }

    urlStrings := []string{}
    urlStrings = strings.Split(string(f), "\n")

    for _, v := range urlStrings {
        go ping(v)
    }

    //  output logs to the terminal
    //  channel is global
    for i := range c {
        fmt.Println(i)
    }
}

func ping(url string) {
    //  for our lag timer
    start := time.Now()

    //  make our request
    _, err := http.Get(url)

    if err != nil {
        msg := url + " Error:" + err.Error()

        fmt.Println(msg)

        c <- msg
        reportError(msg)
    } else {
        lag := time.Since(start)
        var msg string

        //  running slow
        if lag > lagThreshold*time.Second {
            msg = url + " lag: " + lag.String()
            reportError(msg)
        }

        msg = url + ", lag: " + lag.String()
        c <- msg
    }

    time.Sleep(pingInterval * time.Second)
    go ping(url) // is this acceptable?
}

在我的 Get 请求中，我之前调用了 defer res.Body.Close() ，但在应用程序运行一段时间后，这令人恐慌。我假设在 goroutine 被垃圾收集并且 res 不再存在之前，延迟无法调用响应上的 Close()。

这让我想到，如果在 goroutine 中调用 goroutine 是最佳实践，或者我是否会导致函数永远不会退出，那么只有在 goroutine 被垃圾回收后才会调用 defer。

Answer 1

没关系。从另一个 goroutine 调用一个 goroutine 是完全可以接受的。调用的 goroutine 仍然会退出，新的 goroutine 会继续愉快的进行。

Answer 2

从一个 goroutine 中扩展一个新的 goroutine 本身就很好。

但我怀疑这是解决您的问题的最简单和最干净的解决方案。 我猜你的第一个版本做了显而易见的事情，并在一个无限循环中对每个 URL 进行 ping 操作。并且这会影响延迟：一旦函数返回，就会执行延迟调用。 （这与 goroutine 蜂鸣“垃圾收集无关；实际上 goroutines 刚刚结束，没有被收集）。在一个无限循环中，你永远不会返回，你只是累积永远不会执行的延迟调用。因此你永远不会关闭所有打开的res.Body 并且您的内存不足/无论如何都会出现恐慌。

defer res.Body.Close 是一个很好的习惯用法，但不是在无限循环中。

我会尝试你的第一个版本，并在 nil 错误路径上直接执行 res.Body.Close。