定时器在使用timer.Reset()时无法按预期工作

哈喽！今天心血来潮给大家带来了《定时器在使用timer.Reset()时无法按预期工作》，想必大家应该对Golang都不陌生吧，那么阅读本文就都不会很困难，以下内容主要涉及到，若是你正在学习Golang，千万别错过这篇文章~希望能帮助到你！

我一直在尝试运行我的第一个“go 例程”示例，当我让它运行时，它不会按照 go 文档中规定的带有 timer.reset() 函数的方式工作。

就我而言，我相信我这样做的方式很好，因为我实际上并不关心 chan 缓冲区中有什么（如果有的话）。这样做的目的是，如果 case _, ok := <-watcher.events: 上发生任何事情，则触发 case <-tmr.c: ，然后一切都会安静至少一秒钟。这样做的原因是 case _, ok := <-watcher.events: 可以间隔一微秒到几十个事件，我只关心它们全部完成并且事情再次稳定下来。

但是我担心按照文档所说的“必须这样做”的方式进行操作是行不通的。如果我知道做得更好，我会说文档是有缺陷的，因为它假设缓冲区中有东西，而实际上可能没有，但我不知道做得足够好，有信心做出这样的决定，所以我希望一些专家出来那里可以启发我。

下面是代码。我没有将其放在演示中，因为我必须进行一些清理（删除对程序其他部分的调用），并且我不确定如何使其对文件系统更改做出反应以显示其工作。 p>

我已经在代码中清楚地标记了哪些替代方案有效，哪些无效。

func (pm *PluginManager) LoadAndWatchPlugins() error {

  // DOING OTHER STUFF HERE

    fmt.Println(`m1`)

    done := make(chan interface{})
    terminated := make(chan interface{})

    go pm.watchDir(done, terminated, nil)
    fmt.Println(`m2.pre-10`)

    time.Sleep(10 * time.Second)

    fmt.Println(`m3-post-10`)

    go pm.cancelWatchDir(done)
    fmt.Println(`m4`)

    <-terminated
    fmt.Println(`m5`)

    os.Exit(0) // Temporary for testing

    return Err
}

func (pm *PluginManager) cancelWatchDir(done chan interface{}) {
    fmt.Println(`t1`)

    time.Sleep(5 * time.Second)
    fmt.Println()
    fmt.Println(`t2`)

    close(done)
}

func (pm *PluginManager) watchDir(done <-chan interface{}, terminated chan interface{}, strings <-chan string) {

  watcher, err := fsnotify.NewWatcher()
    if err != nil {
        Logger("watchDir::"+err.Error(), `plugins`, Error)
    }

    //err = watcher.Add(pm.pluginDir)
    err = watcher.Add(`/srv/plugins/`)
    if err != nil {
        Logger("watchDir::"+err.Error(), `plugins`, Error)
    }

    var tmr = time.NewTimer(time.Second)
    tmr.Stop()

    defer close(terminated)
    defer watcher.Close()
    defer tmr.Stop()
    for {
        select {
        case <-tmr.C:
            fmt.Println(`UPDATE FIRED`)
            tmr.Stop()

        case _, ok := <-watcher.Events:
            if !ok {
                return
            }

            fmt.Println(`Ticker: STOP`)
            /*
             *  START OF ALTERNATIVES
             *
             *  THIS IS BY EXAMPLE AND STATED THAT IT "MUST BE" AT:
             *      https://golang.org/pkg/time/#Timer.Reset
             *
             *  BUT DOESN'T WORK
             */
            if !tmr.Stop() {
                fmt.Println(`Ticker: CHAN DRAIN`)
                <-tmr.C // STOPS HERE AND GOES NO FURTHER
            }
            /*
             *  BUT IF I JUST DO THIS IT WORKS
             */
            tmr.Stop()
            /*
             *  END OF ALTERNATIVES
             */

            fmt.Println(`Ticker: RESET`)
            tmr.Reset(time.Second)

        case <-done:
            fmt.Println(`DONE TRIGGERED`)
            return
        }
    }
}

解决方案

除了 icza said（q.v.）之外，请注意 documentation 说：

例如，假设程序尚未收到来自 t.c 的信息：

if !t.stop() {
        <-t.c
}

这不能与来自计时器通道的其他接收同时完成。

有人可能会说这不是一个很好的例子，因为它假设计时器在您调用 t.stop 时正在运行。但它确实继续提到，如果已经有一些现有的 goroutine 正在或可能正在从 t.c 读取数据，那么这是一个坏主意。

（reset 文档重复了所有这些，并且顺序有点错误，因为 reset 在 stop 之前排序。）

本质上，整个区域有点fraught。没有很好的通用答案，因为从t.stop返回到你的调用期间至少有三种可能的情况：

• 没有人正在收听该频道，并且频道中现在没有定时器滴答声。如果计时器在调用 t.stop 之前已停止，通常会出现这种情况。如果计时器已经停止，t.stop 始终返回 false。
• 没有人正在收听该频道，频道中现在有计时器滴答声。当计时器正在运行但 t.stop 无法阻止其触发时，总是会出现这种情况。在这种情况下，t.stop 返回 false。当计时器正在运行但在您调用 t.stop 之前触发时，也会出现这种情况，因此它自行停止，因此 t.stop 无法停止它并返回 false。
• 其他人正在收听该频道。

在最后一种情况下，您不应该执行任何操作。在第一种情况下，您不应该执行任何操作。在第二种情况下，您可能希望从通道接收以便将其清除。这就是他们的例子的目的。

有人可能会说：

if !t.stop() {
        select {
        case <-t.c:
        default:
        }
}

是一个更好的例子。它执行一次非阻塞尝试，该尝试将消耗计时器滴答（如果存在），如果没有计时器滴答，则不执行任何操作。无论调用 t.stop 时计时器是否实际运行，这都有效。事实上，如果 t.stop 返回 true，它甚至可以工作，尽管在这种情况下，t.stop 停止了计时器，因此计时器从未设法将计时器滴答放入通道中。 （因此，如果通道中存在数据，则它必然是先前清除通道失败所遗留的。如果不存在此类错误，则尝试接收也就不必要了。）

但是，如果其他人（其他一些 goroutine）正在或可能正在读取该通道，那么您根本不应该执行此操作。尽管调用了 stop，但无法知道谁（您或他们）将获得通道中可能存在的任何计时器滴答声。

同时，如果您不再使用计时器，那么在通道中留下一个计时器滴答声（如果有的话）相对无害。当通道本身被垃圾收集时，它也会被垃圾收集。当然，这是否明智取决于您对计时器所做的事情，但在这些情况下，只需调用 t.stop 并忽略其返回值就足够了。

您创建一个计时器并停止它立即：

var tmr = time.newtimer(time.second)
tmr.stop()

这没有任何意义，我认为这只是你的一次“意外”。

但更进一步，在循环内部：

case _, ok := <-watcher.events:

当发生这种情况时，您声称这不起作用：

if !tmr.Stop() {
            fmt.Println(`Ticker: CHAN DRAIN`)
            <-tmr.C // STOPS HERE AND GOES NO FURTHER
        }

Timer.Stop() 文档表明，如果此调用停止计时器，则返回 true；如果计时器已停止（或过期），则返回 false。但是你的计时器在创建后就已经停止了，所以 tmr.stop() 正确返回 false ，所以你进入 if 并尝试从 tmr.c 接收，但由于计时器“长时间”停止，所以什么都不会在其通道上发送，因此这是一个阻塞（永远）操作。

如果您是使用 timer.stop() 显式停止计时器的人，则推荐的用于耗尽其通道的“模式”没有任何意义，并且不适用于第二个 timer.stop()称呼。

理论要掌握，实操不能落！以上关于《定时器在使用timer.Reset()时无法按预期工作》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！