如何在多goroutine场景下正确停止Go语言的time.Timer？

先聊聊你这段代码里的几个潜在坑：

• 全局变量竞态风险：timer是全局变量，A和B在不同goroutine里直接操作它却没有同步机制，很容易出现A调用timer.Stop()时timer还是nil，或者B刚完成赋值的中间状态，直接导致panic或者无效的停止操作。
• 忽略Stop的返回值：timer.Stop()的返回值非常关键——返回true表示timer还没触发就被成功停止，返回false表示timer已经触发过或者已经被停止过。忽略它的话，你没法判断是否需要清理通道里的残留值，后续可能出现误触发的问题。
• Goroutine泄漏：当你在A里停止timer后，B里的select会一直阻塞在<-timer.C上（因为Stop不会关闭通道），这个goroutine会一直挂着，造成资源泄漏。
• 旧timer通道残留值干扰新timer：如果Stop的时候timer已经触发，但通道里的值还没被读取，这个值会留在通道里，后续新timer的C可能会被这个旧值“误触发”，导致业务逻辑出错。

下面是修正后的代码，我会逐段解释关键细节：

import (
    "sync"
    "time"
)

var (
    timer *time.Timer
    mu    sync.Mutex // 用互斥锁保护全局timer的并发读写
)

func A() {
    mu.Lock()
    defer mu.Unlock()

    if timer != nil {
        // 停止旧timer，根据返回值判断是否需要清理通道残留
        if !timer.Stop() {
            // Stop返回false，说明timer已触发，通道可能有残留值，用非阻塞select清理
            select {
            case <-timer.C:
            default:
                // 通道没值，直接跳过
            }
        }
        timer = nil // 清空旧timer引用，避免野指针
    }

    // 启动新goroutine执行B
    go B()
}

func B() {
    newTimer := time.NewTimer(100 * time.Millisecond)

    // 先加锁把新timer赋值给全局变量
    mu.Lock()
    timer = newTimer
    mu.Unlock()

    select {
    case <-newTimer.C:
        // 超时后执行业务逻辑，比如修改状态
        mu.Lock()
        // 额外判断：确保当前全局timer还是我们创建的这个newTimer（避免已经被A替换）
        if timer == newTimer {
            timer = nil
        }
        mu.Unlock()
        // 这里写你的业务操作代码
    }
}

核心优化点说明： #

• 用sync.Mutex做并发保护：所有对全局timer的读写操作都要加锁，彻底避免并发竞争带来的问题。
• 正确处理Stop返回值：当Stop()返回false时，用带default的select非阻塞读取通道残留值——既不会阻塞goroutine，又能清理掉旧值，避免干扰后续新timer。
• B中使用局部变量newTimer：在select监听时用局部的newTimer.C而非全局timer.C，因为全局timer可能已经被A替换成新的了，用局部变量能确保我们监听的是当前goroutine创建的那个timer的通道。
• 及时清理timer引用：不管是超时触发还是被提前停止，都在合适时机清空全局timer的引用，避免野指针和无效操作。

另外，如果你觉得这种方式有点繁琐，也可以试试time.AfterFunc，它可以直接在超时后执行指定函数，返回的Timer同样可以用来停止，核心的并发保护和Stop后清理逻辑是一致的。

内容的提问来源于stack exchange，提问作者lxyscls