golang 中 map 的并发问题

資深大佬 : ksedz 4

golang 中的 map 并发访问会报错，一般建议是使用读写锁。

我有两个场景不太适合使用读写锁，求问有什么好的解决方案：

1. 并发写入不同的 key，读取和写入肯定不会同时进行
实际场景是每个协程维护一个会话信息，会话之间肯定不会冲突，会话内也不会并发读写。协程内的局部变量可以解决这个问题，但我想汇总协程内的信息，就需要使用 map 了。

2. 大量的并发写入，少量的读取
这个和上面是同一个业务，要对不同会话内的不同类型事件次数进行统计，然后定时打印到控制台。说这是少量的读取也不太合适，因为写入前还要查询原值，但也不是读写锁更适合的读多写少的情况。这里可能是 map 实现本身的问题了，求问有什么更优的数据结构或算法处理这一问题，可以做到高效的原子性的 increase 1 ？

大佬有話說 (14)

資深大佬 : abbycin

换 tbb

主資深大佬 : ksedz

@abbycin 谢谢提示。搜了下，是 C++的方案？改动有点大，我先找找其他解决方案。

資深大佬 : jingniao

map 的 value 弄成结构体指针？

資深大佬 : qianlv7

分桶，每个桶单独加锁

資深大佬 : teawithlife

可以换自带的 sync.Map
唯一坑的地方是没有 Len()方法，也就是说如果你需要获取 Map 中的元素个数，得自己遍历一遍数个数。不过看你的使用场景，应该不需要 Len()方法

資深大佬 : foam

第 2 个场景不要加锁了，太重。用 atomic 包的 cas，其实就是乐观锁。加上 for 重试，保证写入。

資深大佬 : fiypig

sync.Map

資深大佬 : fighterlyt

看来上边的人都没找到的具体的问题，map 不支持并发读写的根本原因是** 使用一个有空间大小的结构表示一个无限大小的结构**。这样必然伴随着内存的重新分配和对应的复制问题。所以不管读写是否为同一个 key，总是需要加锁。针对第二个问题，两个 map 就 ok 了，可以用同一把锁,1 个 map[string]***，1 个 map[string]int64

資深大佬 : wysnylc

对着 java concurrenthashmap 实现一遍

資深大佬 : dongisking

golang 并发访问会报错？

資深大佬 : zhs227

@dongisking 准确的说是会 panic，程序直接退出。一般用 sync.map 或者是加锁。

資深大佬 : reus

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.

資深大佬 : keepeye

1. 用 sync.Map
2. 用第三方封装过的 map，分 bucket 的，但还是加锁的思路
3. 自己封装一层，通过 channel 的去限制并发读写 map

資深大佬 : dafsic

给你看看我用的方法，不说多好，反正我一直这样用 https://www.v2ex.com/t/596606#reply18