我试图在 Go 的标准库和许多其他类似于 Java 的 ConcurrentMap.computeIfAbsent 的缓存库中找到这个函数。 我在标准库中找到了 sync.Map ，它看起来像我正在寻找的东西。我想使用 sync.Map 作为并发映射。问题在于以下函数不像 Java 的 ConcurrentMap 那样提供延迟计算。

func (m *Map) LoadOrStore(key, value interface{}) (actual interface{}, loaded bool)

LoadOrStore returns the existing value for the key if present. Otherwise, it stores and returns the given value. The loaded result is true if the value was loaded, false if stored.

它是原子的，但是这个函数对我来说没有意义。我不明白它的用途，因为我是这门语言的新手。我不知道为什么第二个参数是一个值而不是一个函数。由于将急切地评估参数，所以我不知道每次重新计算值时这个函数有什么用。

如果函数签名像这样，IMO 会更有用

func (m *Map) LoadOrStore(key interface{}, f func() interface{}) (actual interface{}, loaded bool)

我的意思是，当我们已经有了值时，为什么还需要 map ？ 很确定我错过了什么。

让我详细说明一下。我不明白为什么函数将值作为参数而不是函数的原因，我很确定我错过了一些东西。我想以并发方式从 map 中获取值。当键不存在时，我想计算值并自动将其放入 map 中。我知道我不应该将它与 Java 中的 ConcurrentMap 进行比较，因为语言和范例不同，但是说出我来自哪里可能很有用，并且它可以使任何正在学习 Go 的人更好地理解它关于这个区别。

Java ConcurrentMap 中有类似的功能。

computeIfAbsent(K key, Function<? super K,? extends V> mappingFunction)

If the specified key is not already associated with a value (or is mapped to null), attempts to compute its value using the given mapping function and enters it into this map unless null.

问题是为什么LoadOrStore函数采用值而不是函数？任何关于为什么以这种方式设计 API 的见解将不胜感激。还有一种方法可以完成与我在 Java 中所做的相同的事情 computeIfAbsent不在 map 周围使用明确的锁？

已更新 我发现修改 sync.Map.LoadOrStore 以获取函数而不是值非常容易。

https://play.golang.org/p/VBIaS8ZV38o

但不确定它是否会按预期工作。

最佳答案

目的sync.Map 不是提供延迟值计算的方法，而是提供通用的map[interface{}]接口(interface){}并发使用安全 通过多个协程。如果没有额外/显式同步，go 中的 map 类型对于并发使用是不安全的。

这在sync.Map 的文档中有明确说明:

Map is like a Go map[interface{}]interface{} but is safe for concurrent use by multiple goroutines without additional locking or coordination. Loads, stores, and deletes run in amortized constant time.

The Map type is specialized. Most code should use a plain Go map instead, with separate locking or coordination, for better type safety and to make it easier to maintain other invariants along with the map content.

The Map type is optimized for two common use cases: (1) when the entry for a given key is only ever written once but read many times, as in caches that only grow, or (2) when multiple goroutines read, write, and overwrite entries for disjoint sets of keys. In these two cases, use of a Map may significantly reduce lock contention compared to a Go map paired with a separate Mutex or RWMutex.

至于为什么sync.Map有一个

LoadOrStore(key, value interface{}) (actual interface{}, loaded bool)

方法代替:

LoadOrComputeAndStore(key interface{}, f func() interface{}) (actual interface{}, loaded bool)

该问题是基于意见的，因此与 Stackoverflow 无关。但出于一个原因:前者更易于使用(当你已经有了值时，你不必使用函数文字)而后者并不总是需要的(即使在某些情况下确实很有用)。

请注意，我们可以轻松创建具有此“功能”的自定义同步映射:

type MyMap struct {
    sync.Map
}

func (m *MyMap) LoadOrComputeAndStore(key interface{}, f func() interface{}) (actual interface{}, loaded bool) {
    actual, loaded = m.Load(key)
    if loaded {
        return
    }
    return m.LoadOrStore(key, f())
}

使用示例:

m := &MyMap{Map: sync.Map{}}

f := func() interface{} {
    fmt.Println("calculating...")
    return "myvalue"
}
key := "mykey"

fmt.Println(m.LoadOrComputeAndStore(key, f))
fmt.Println(m.LoadOrComputeAndStore(key, f))

输出(在 Go Playground 上尝试):

calculating...
myvalue false
myvalue true

如输出所示，f() 仅被调用一次。第一次调用 m.LoadOrComputeAndStore() 调用 f()，并报告 loaded=false(因为 key 是尚未在 map 中)。第二次调用 m.LoadOrComputeAndStore() 不会调用 f()，并报告 loaded=true。

请注意，这是实现您想要的目标的“简单且充分”的方法。但它不是“防弹”，这意味着 LoadOrComputeAndStore() 的实现并不能保证 f() 只能被调用一次。这是因为它首先使用 Map.Load() 加载值。如果它发现它不在 map 中，那么它会调用 f()，在此期间，并发 goroutine 可能会执行相同的操作。因此，如果 f() 需要很长时间才能返回并且 map 被多个 goroutines 使用，则 f() 可能会被调用多次。如果需要保证避免多次 f() 调用，那么您应该使用显式 sync.RWMutex在 map 上。

总结一下:上面的示例实现在大多数情况下应该足够了，即当 f() 没有副作用时，您只需要 LoadOrComputeAndStore() 以避免由于执行时间长而不得不调用 f()。如果 f() 确实有一个不能重复的副作用，那么这个实现是不充分的，是需要手动锁定。

关于dictionary - Go中有类似Java的ConcurrentMap.computeIfAbsent的功能吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/49528232/