Why is holding a sync.Mutex while sending on a channel a deadlock risk in Go?

## The mechanism in one sentence A goroutine that blocks on a channel operation keeps everything it holds. `sync.Mutex` has no notion of releasing on wait, no lock-with-timeout, and no reentrancy; the lock stays owned by a goroutine that is parked and running nothing. Combine that with a channel operation whose counterpart needs the same lock and you have a two-party cycle where one edge is a lock and the other is a channel. ## The shape ``` func (s *store) Publish(e Event) { s.mu.Lock() defer s.mu.Unlock() // held to the end of the function s.seq++ e.Seq = s.seq s.out <- e // parks here, still holding s.mu } func (s *store) Seq() int { s.mu.Lock() // the consumer calls this and never gets it defer s.mu.Unlock() return s.seq } ``` The consumer goroutine receives from `s.out` in a loop and calls `s.Seq()` for each event. The moment the channel is full (or is unbuffered and the consumer happens to be inside `Seq`), the producer parks on the send holding `s.mu`, and the consumer parks on `s.mu` inside `Seq`. Neither will ever move. ## Why it is so easy to write Three things conspire: 1. **`defer mu.Unlock()` is the recommended idiom** — and it should be, because it survives early returns and panics. But it also means the critical section is the whole rest of the function. When someone later adds a send, a `select`, a network call or a `Wait` at the bottom of that function, they have extended the lock across a potentially unbounded wait without touching the locking code at all. 2. **The consumer's dependency on the lock is usually indirect** — it is not `mu.Lock()` in the receive loop, it is a call to an accessor three frames down that happens to take the same mutex. 3. **It is load-dependent.** With a buffered channel and a fast consumer, the send never blocks and the code is correct for months. It wedges the first time the consumer is slow, which is precisely when the system is under stress. ## Why nothing rescues you There is no lock-wait timeout in `sync.Mutex` and no cycle detection anywhere in the Go runtime or toolchain. The process is not idle either: the HTTP listener keeps accepting, health checks keep passing, other goroutines keep running. So the failure presents as "one feature stopped working" plus a slowly growing goroutine count, not as a crash. `go vet` will not see it, and the race detector answers a different question entirely — it finds unsynchronised accesses that actually executed, not blocking cycles. ## The fixes, in order of preference **Shrink the critical section.** Take the lock, do the small piece of shared-state work, release it, then perform the blocking operation. Written out, this means giving up `defer` for that function or splitting it in two: a small locked helper that returns what you need, and an unlocked body that sends. The rule that generalises: *never perform an operation with an unbounded wait while holding a lock* — a channel send or receive, a `select` without `default`, a `Wait`, a network round trip, or a call into code you do not control. **Bound the wait.** Replace a naked send with a `select` over the send and `<-ctx.Done()`, or a `default` branch that drops or applies backpressure to the caller. This turns a permanent block into a policy decision you have to name: drop the event, block the caller, or fail the request. **Change the ownership model.** If the state and the channel always travel together, consider giving the state to a single owner goroutine and letting other goroutines talk to it over a channel, so there is no mutex to hold. This is the "share by communicating" shape, and it removes the lock edge of the cycle rather than shortening it. **What is not a fix:** enlarging the buffer. It converts a deterministic deadlock into one that needs a slow consumer to appear — a strictly worse bug, because it will now happen in production and not in your test. It is fine to buffer for throughput; it is not a correctness argument. ## Reviewing for it The review heuristic is mechanical enough to apply quickly: find every `Lock()`, then read forward to the matching `Unlock()` (with `defer`, that is the end of the function) and look for anything that can block. If you find one, ask which goroutine completes it and whether that goroutine can reach the same lock. Most of the time the answer takes ten seconds, and when it does not, that is exactly the code worth arguing about.