『每周译Go』Go sync.Once 的妙用

如果你曾用过 Go 中的 goroutines，你也许会遇到几个并发原语，如 sync.Mutex, sync.WaitGroup 或是 sync.Map，但是你听说过 sync.Once 么？

也许你听说过，那 go 文档是怎么描述它的呢？

Once 是只执行一个操作的对象。

听起来很简单，它有什么用处呢？

由于某些原因，sync.Once 的用法并没有很好的文档记录。在第一个.Do中的操作执行完成前，将一直处于等待状态，这使得在执行较昂贵的操作（通常缓存在 map 中）时非常有用。

原生缓存方式

假设你有一个热门的网站，但它的后端 API 访问不是很快，因此你决定将 API 结果通过 map 缓存在内存中。以下是一个基本的解决方案：

package main

type QueryClient struct {
    cache map[string][]byte
    mutex *sync.Mutex
}

func (c *QueryClient) DoQuery(name string) []byte {
    // 检查结果是否已缓存
    c.mutex.Lock()
    if cached, found := c.cache[name]; found {
        c.mutex.Unlock()
        return cached, nil
    }
    c.mutex.Unlock()

    // 如果未缓存则发出请求
    resp, err := http.Get("https://upstream.api/?query=" + url.QueryEscape(name))
    // 为简洁起见，省略了错误处理和 resp.Body.Close
    result, err := ioutil.ReadAll(resp)

    // 将结果存储在缓存中
    c.mutex.Lock()
    c.cache[name] = result
    c.mutex.Unlock()

    return result
}

看起来不错，对吧？

然而，如果有两个 DoQuery 同时进行调用会发生什么呢？竞争。两方缓存都无法命中，并且都会向 upstream.api 执行不必要的 HTTP 请求，而只有一个需要完成这个请求。

不美观但更好的缓存方式 我并没有进行统计，但我认为大家解决这个问题的另外一种方式是使用 channel、context 或 mutex。在这个例子中，可以将上文代码调整为：

package main

type CacheEntry struct {
    data []byte
    wait <-chan struct{}
}

type QueryClient struct {
    cache map[string]*CacheEntry
    mutex *sync.Mutex
}

func (c *QueryClient) DoQuery(name string) []byte {
    // 检查操作是否已启动
    c.mutex.Lock()
    if cached, found := c.cache[name]; found {
        c.mutex.Unlock()
        // 等待完成
        <-cached.wait
        return cached.data, nil
    }

    entry := &CacheEntry{
        data: result,
        wait: make(chan struct{}),
    }
    c.cache[name] = entry
    c.mutex.Unlock()

    // 如果未缓存，则发出请求
    resp, err := http.Get("https://upstream.api/?query=" + url.QueryEscape(name))
    // 为简洁起见，省略了错误处理和 resp.Body.Close
    entry.data, err = ioutil.ReadAll(resp)

    // 关闭 channel，传递操作完成信号
    // 立即返回
    close(entry.wait)

    return entry.data
}

这种方案不错，但代码的可读性受到了很大影响。cached.wait 进行了哪些操作不是很清晰，在不同情况下的操作流也并不直观。

使用 sync.Once

我们来尝试一下使用 sync.Once 方案：

package main

type CacheEntry struct {
    data []byte
    once *sync.Once
}

type QueryClient struct {
    cache map[string]*CacheEntry
    mutex *sync.Mutex
}

func (c *QueryClient) DoQuery(name string) []byte {
    c.mutex.Lock()
    entry, found := c.cache[name]
    if !found {
        // 如果在缓存中未找到，创建新的 entry
        entry = &CacheEntry{
            once: new(sync.Once),
        }
        c.cache[name] = entry
    }
    c.mutex.Unlock()

    // 现在，当我们调用 .Do 时，如果有一个正在同步进行的操作
    // 它将一直阻塞，直到完成（并填充 entry.data）
    // 或者如果操作之前已经完成过一次
    // 本次调用不会进行操作，也不会阻塞
    entry.once.Do(func() {
        resp, err := http.Get("https://upstream.api/?query=" + url.QueryEscape(name))
        // 为简洁起见，省略了错误处理和 resp.Body.Close
        entry.data, err = ioutil.ReadAll(resp)
    })

    return entry.data
}

以上就是 sync.Once 的方案，和之前的示例很相似，但现在更容易理解（至少在我看来）。只有一个返回值，且代码自上而下，非常直观，而不必像之前一样对 entry.wait channel 进行阅读和理解。

进一步阅读/其他注意事项 另一个类似于 sync.Once 的机制是 golang.org/x/sync/singleflight。singleflight 只会删除正在进行中的请求中的重复请求（即不会持久化缓存），但与 sync.Once 相比，singleflight 通过 context 实现起来可能更简洁（通过使用 select 和 ctx.Done()），并且在生产环境中，可以通过 context 取消这一点很重要。singleflight 实现的模式和 sync.Once 十分接近，但如果 map 中存有值，则会提前返回。

ianlancetaylor 建议结合 context 使用 sync.Once，方式如下：

c := make(chan bool, 1)
go func() {
    once.Do(f)
    c <- true
}()
select {
case <-c:
case <-ctxt.Done():
    return
}