Go 'fatal error: concurrent map writes' (also 'concurrent map read and map write'): why can't I recover() from it and how do I fix it?

Cause: Several goroutines used the same map at once and at least one of them wrote to it. Go maps are not safe for concurrent use; the Go blog states that what happens with simultaneous reads and writes is not defined. Since Go 1.6 the runtime does best-effort detection of this misuse, prints a diagnosis and crashes the program. It is a fatal error, not a panic, so recover() cannot catch it. Detection is best effort, so the absence of the message does not prove the code is safe. Fix (best first): 1. Guard the map with a mutex. Put a sync.RWMutex next to the map in a struct; take Lock/Unlock around writes and RLock/RUnlock around reads. Keep the lock for the whole read-modify-write sequence, not just individual operations. 2. Or make one goroutine the owner of the map and send requests to it over a channel, following 'share memory by communicating' from Effective Go. 3. sync.Map is safe without extra locking, but the docs say most code should use a plain map with explicit locking. Consider it only for write-once, read-many caches or goroutines that touch disjoint keys. 4. Don't copy a struct that contains a mutex after use; pass a pointer. 5. Read-only maps that are fully built before the goroutines start are fine without locking. Verify: Run go test -race ./... or go run -race, which reports the conflicting accesses with stack traces far more reliably than the runtime check, and run the test under load several times. Sources: https://go.dev/blog/maps https://go.dev/doc/go1.6 https://pkg.go.dev/sync https://go.dev/doc/faq