25

我现在正在学习 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 不再存在之前，defer 无法在响应上调用 Close()。

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

4

2 回答 2

32

没事儿。从另一个 goroutine 调用一个 goroutine 是完全可以接受的。调用的 goroutine 仍然会退出，新的 goroutine 将继续它的快乐方式。

于 2013-04-29T21:21:39.043 回答
11

从一个 goroutine 中跨越一个新的 goroutine 本身就很好。

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

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

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

于 2013-04-29T21:30:29.957 回答