Golang Go语言中 map 的并发问题
Golang Go语言中 map 的并发问题
golang 中的 map 并发访问会报错，一般建议是使用读写锁。
我有两个场景不太适合使用读写锁，求问有什么好的解决方案：
1. 并发写入不同的 key，读取和写入肯定不会同时进行
实际场景是每个协程维护一个会话信息，会话之间肯定不会冲突，会话内也不会并发读写。协程内的局部变量可以解决这个问题，但我想汇总协程内的信息，就需要使用 map 了。
2. 大量的并发写入，少量的读取
这个和上面是同一个业务，要对不同会话内的不同类型事件次数进行统计，然后定时打印到控制台。说这是少量的读取也不太合适，因为写入前还要查询原值，但也不是读写锁更适合的读多写少的情况。这里可能是 map 实现本身的问题了，求问有什么更优的数据结构或算法处理这一问题，可以做到高效的原子性的 increase 1 ？
更多关于Golang Go语言中 map 的并发问题的实战系列教程也可以访问 https://www.itying.com/category-94-b0.html
可以换自带的 sync.Map
唯一坑的地方是没有 Len()方法，也就是说如果你需要获取 Map 中的元素个数，得自己遍历一遍数个数。不过看你的使用场景，应该不需要 Len()方法
看来上边的人都没找到的具体的问题，map 不支持并发读写的根本原因是** 使用一个有空间大小的结构表示一个无限大小的结构**。这样必然伴随着内存的重新分配和对应的复制问题。所以不管读写是否为同一个 key，总是需要加锁。针对第二个问题，两个 map 就 ok 了，可以用同一把锁,1 个 map[string]***，1 个 map[string]int64
sync.Map 就是为这种场景定制的
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.
在Go语言中，map 是一种内置的数据结构，用于存储键值对。然而，map 并不是线程安全的，即多个goroutine同时读写同一个map时，会导致未定义行为，如程序崩溃或数据损坏。
要处理map的并发问题，有几种常见的解决方案：
-
使用互斥锁（Mutex）： 使用
sync.Mutex或sync.RWMutex来保护对map的访问。这种方式简单直接，但可能会引入额外的锁竞争，影响性能。 -
使用
sync.Map： Go标准库提供了sync.Map，它内部实现了复杂的并发控制机制，可以安全地在多个goroutine之间共享。sync.Map提供了Store、Load、Delete、LoadOrStore和Range等方法，适合读多写少的场景。 -
使用原子操作： 对于某些简单的场景，可以使用
sync/atomic包提供的原子操作来更新map中的值，但这通常只适用于值类型为简单数值类型的场景，且需要小心处理键的并发访问问题。 -
避免共享： 如果可能，尽量避免多个goroutine共享同一个
map。可以通过设计将数据分区存储在不同的map中，每个map只由一个goroutine访问，从而避免并发问题。
总之，处理map的并发问题需要根据具体场景选择合适的策略，既要保证线程安全，又要尽量提高性能。
