0

我正在编写一个 Go 程序来监视文件并在其中一个文件发生更改时运行系统命令。到目前为止，它运作良好。我对我的主要“无限”循环有疑问，因为我不希望它占用所有系统 CPU 资源：

runtime.GOMAXPROCS(1)
for {
    updatedFiles, _ := GetWatchMap(config)
    if !reflect.DeepEqual(filesToWatch, updatedFiles) {
        start := time.Now()
        _, _ = colorstring.Println(fmt.Sprintf(" [yellow] ⬇ Update detected[white] at [green]%s[white] > updating...", start.Format("15:04:05")))
        _, _ = Update(config)
        end := time.Now()
        elapsed := end.Sub(start)
        _, _ = colorstring.Println(fmt.Sprintf("  [green]✅  Done![white] in [yellow]%.2f[white] second(s).", elapsed.Seconds()))
        filesToWatch = updatedFiles
    } else {
        time.Sleep(config.SleepTime)
    }
}

所以，我所做的是设置 GOMAXPROCS，所以它只使用“1 CPU/Core”，并且我在 else 分支中添加了一个可配置的睡眠时间。

如果没有睡眠时间，htop 显示该进程占用了 100% 的 CPU 时间（我猜它是一个核心的 100%？）无论我是否调用runtime.GOMAXPROCS(1)。

如果我在我的机器（MacMini i7，12 核）上使用 30 毫秒的睡眠时间，htop 会报告进程的 CPU 利用率为 20%，这看起来不错，但我想这会因运行程序的计算机而异。

这里的最佳做法是什么？

4

1 回答 1

3

GOMAXPROCS 并不像您认为的那样。从包运行时文档：

GOMAXPROCS 变量限制了可以同时执行用户级 Go 代码的操作系统线程的数量。代表 Go 代码在系统调用中可以阻塞的线程数没有限制；这些不计入 GOMAXPROCS 限制。

它限制了操作系统线程。如果您的代码不使用可以调度到操作系统线程的 goroutines，那么限制线程数实际上什么也做不了。只需删除 GOMAXPROCS 的东西，它什么都不做。（如果您将 GOMAXPROCS 设置为 12，您将最多有 12 个 OS 线程实际执行 goroutine 代码；如果您只有一个 goroutine，则限制它可以运行的 OS 线程数是 noop。）

您所能做的就是不像使用 time.Sleep() 那样忙循环。根据您的要求，您可以定期调用实际代码，例如通过 time.Ticker。没有单一的“最佳实践”（除了不摆弄 GOMAXPROCS）。

于 2020-05-07T12:17:08.883 回答