How to recover from concurrent map writes?

Recovering doesn’t work here because what you experience is not a panicing state.

Go 1.6 added a lightweight concurrent misuse of maps detection to the runtime:

The runtime has added lightweight, best-effort detection of concurrent misuse of maps. As always, if one goroutine is writing to a map, no other goroutine should be reading or writing the map concurrently. If the runtime detects this condition, it prints a diagnosis and crashes the program. The best way to find out more about the problem is to run the program under the race detector, which will more reliably identify the race and give more detail.

What you experience is an intentional crash by the runtime, it’s not the result of a panic() call that a recover() call in a deferred function could stop.

There’s nothing you can do to stop that except prevent the concurrent misuse of maps. If you would leave your app like that and it wouldn’t crash, you could experience mysterious, undefined behavior at runtime.

Leave a Comment