is Go maps sensitive to data races?

This is a creation in Article, where the information may have evolved or changed.

Panic messages from unexpected program crashes is often reported on the Go issue tracker. An overwhelming number of these panics is caused by data races, and an overwhelming number of those reports centre around Go ' s built in map type.

Unexpected fault address 0x0fatal error:fault[signal 0x7 code=0x80 addr=0x0 pc=0x40873b]goroutine 97699 [Running]:runtim E.throw (0x17f5cc0, 0x5)    /usr/local/go/src/runtime/panic.go:527runtime.sigpanic ()    /usr/local/go/src/ Runtime/sigpanic_unix.go:21runtime.mapassign1 (0x12c6fe0, 0xc88283b998, 0xc8c9b63c68, 0XC8C9B63CD8)    /usr/local /go/src/runtime/hashmap.go:446

Why are this? Why are a map commonly involved with a crash? Is Go ' s map implementation inherently fragile?

To cut to the chase:no, there are nothing wrong with Go's map implementation. But if there was nothing wrong with the implementation, why does maps and panic reports commonly find themselves in close Pro Ximity?

There is three reasons that I can think of.

Maps is often used for shared state

Maps is fabulously useful data structures and this makes them perfect for tasks such as a shared cache of precomputed dat A or a lookup table of outstanding requests. The common theme here is the map is being used to store data shared acrossmultiple goroutines.

Maps is more complex structures

Compared to the other built in data types like channels and slices, Go maps is more complex-they aren ' t just views onto A backing array of elements. Go maps contain significant internal, and map iterators ( for k, v := range m ) contain even more.

Go Maps is not goroutine safe, you must use a sync.Mutex , sync.RWMutex or other memory barrier primitive to ensure reads and writes a Re properly synchronised. Getting your locking wrong would corrupt the internal structure of the map.

Maps move Things

Of all of Go's built in data structures, maps is the only ones that move data internally. When you insert or delete entries, the map could need to rebalance itself to retain its O (1) guarantee. This is what map values is not addressable.

Without proper synchronisation different CPUs would have different representations of the map ' s internal structure in their Caches. Although the language lawyer would tell you a program with a data race exhibits undefined behaviour, it's easy-to-see How has a stale copy of a map ' s internal structure can leads to following a stale pointer to oblivion.

Use the race detector

Go ships with a data race detector this works on Windows, Linux, FreeBSD and OSX. The race detector would spot this issue, and many more.

Please use the it when testing your code.