What do sync.Map's LoadOrStore and LoadAndDelete guarantee that a Load followed by a Store cannot?

## The race a compound operation removes The interesting operations on a shared map are rarely single reads or writes; they are *compound*: "insert this if it is not already there", "take the value out and remove it". Doing those as two calls on a concurrent map is not safe just because each call is safe on its own. Between your `Load` and your `Store`, any number of other goroutines can run. Concretely, in a registry of live client connections keyed by connection id: ```go if _, ok := conns.Load(id); !ok { conns.Store(id, newMeta) // another goroutine may have stored here already } ``` Two goroutines can both observe `ok == false` and both proceed to `Store`. There is no crash and no error — the map ends up holding whichever wrote last, while the other goroutine walks away believing its own object is the registered one. The bug shows up much later as metadata that does not match the connection, or as a resource that is never released because the object holding it was orphaned. ## LoadOrStore ```go actual, loaded := conns.LoadOrStore(id, meta) ``` The map performs the check and the insert as one indivisible step: - If the key was **present**, nothing is stored; `actual` is the value that was already there and `loaded` is `true`. - If the key was **absent**, your `meta` is stored; `actual` is your `meta` and `loaded` is `false`. Every concurrent caller therefore agrees on one winner, and every loser is handed the winner's value. The pattern is: ```go meta := &connMeta{user: user, since: time.Now()} actual, loaded := conns.LoadOrStore(id, meta) if loaded { meta = actual.(*connMeta) // someone registered first; use theirs } ``` Read `loaded` as "was it already there", not "did my store succeed" — inverting that is the single most common mistake with this method. ### The eager-argument trap `LoadOrStore` takes a *value*, not a function. Go evaluates arguments before the call, so `conns.LoadOrStore(id, expensiveThing())` builds the expensive thing every single time, even when the key already exists and the value is thrown away immediately. If constructing that value is merely a small struct, the waste is a garbage-collected allocation and nobody cares. If it opens a file, dials a connection or starts a goroutine, the loser has just leaked a real resource, and you must explicitly release the object you built when `loaded` comes back `true`. When the construction genuinely must happen only once, store a cheap placeholder that performs the expensive work behind its own one-time initialisation, rather than trying to make `LoadOrStore` lazy. ## LoadAndDelete ```go v, loaded := conns.LoadAndDelete(id) if loaded { // exactly this caller owns the teardown of v } ``` Removal and retrieval happen together. If a client disconnects and, at the same moment, a timeout sweeper decides the same connection is idle, both may call `LoadAndDelete` on that id — and exactly one of them gets `loaded == true`. That boolean is a hand-off token: whoever holds it is responsible for closing the connection, flushing its buffered state, decrementing a gauge, or whatever teardown must happen once and only once. Written with `Load` followed by `Delete`, both goroutines could see the value and both run the teardown; written with plain `Delete`, neither knows whether it was the one that removed anything. ## The conditional variants `Swap(key, value) (previous, loaded)` unconditionally replaces and gives you what was there. `CompareAndSwap(key, old, new) bool` replaces only if the current value equals `old`, and `CompareAndDelete(key, old) bool` deletes only under the same condition — the compare-and-set idiom, applied per key, for when you must not clobber a value that changed since you read it. Both compare with `==`, so the old value must be of a comparable type. ## Where the atomicity stops These guarantees are strictly **per key**. Nothing in `sync.Map` makes a pair of keys move together, so "remove connection A and add connection B as one unit" is not something the type can express; if you need an invariant across keys, you need your own lock around both operations, and at that point you are back to a plain map with a lock — which is often the honest answer.