Постмортемы дедлоков: инверсия порядка локов, канал под мьютексом и чтение дампа горутин

Форма A: инверсия порядка локов

Форма из Hook, она же классика. Два лока, два пути в коде, противоположные порядки:

func Transfer(from, to *Account) { // путь 1: from → to
	from.mu.Lock()
	defer from.mu.Unlock()
	to.mu.Lock() // горутина 412 ждёт здесь, держа from.mu
	defer to.mu.Unlock()
	// ...
}

func Audit(a, b *Account) { // путь 2 берёт ту же пару в обратном порядке
	b.mu.Lock()
	a.mu.Lock() // горутина 9817 ждёт здесь, держа b.mu
	// ...
}

Каждая горутина держит то, что нужно другой: цикл длины два, замороженный навсегда — у sync.Mutex нет ни таймаута, ни учёта владельца. Окно крошечное (обе должны быть посреди захвата в одни и те же микросекунды), поэтому такое и доезжает до прода: переживает ревью, тесты и месяцы эксплуатации, пока интерливинг не сложится. Лечится не хитростью, а конвенцией: определите один глобальный порядок локов и берите их в этом порядке на каждом пути. Для динамических пар вроде аккаунтов — порядок по внутреннему ключу: if from.ID > to.ID { from, to = to, from } перед захватом — и запишите конвенцию там, где о неё споткнётся следующий инженер.

Форма B: операция с каналом под мьютексом

func (s *Store) Flush() {
	s.mu.Lock()
	defer s.mu.Unlock()
	s.events <- snapshot(s.data) // отправка под s.mu — а получателю...
}

func (s *Store) consume() {
	for ev := range s.events {
		s.mu.Lock() // ...нужен s.mu, прежде чем он сможет принять СЛЕДУЮЩЕЕ
		apply(ev)
		s.mu.Unlock()
	}
}

Flush отправляет, держа лок; потребителю тот же лок нужен для обработки. Один буферный слот люфта — и в каждом демо это работает, пока буфер не окажется полон ровно в момент, когда потребитель между приёмом и локом. Тогда Flush ждёт потребителя, потребитель ждёт мьютекс — цикл замкнулся. Правило обобщается за пределы каналов: никогда не выполняйте блокирующую операцию — отправку или приём канала, I/O, RPC, Wait — держа мьютекс. Мьютекс — для наносекундных правок памяти; всё, что может припарковать горутину, превращает критическую секцию в узел графа ожидания, от которого другие горутины, возможно, уже зависят. Скопируйте данные под локом, отпустите, потом отправляйте.

Форма C: злоупотребление WaitGroup

Третий постмортем тоньше, потому что это гонка, иногда носящая костюм дедлока:

var wg sync.WaitGroup
for _, job := range jobs {
	go func() {
		wg.Add(1) // НЕВЕРНО: гонка с wg.Wait ниже
		defer wg.Done()
		process(job)
	}()
}
wg.Wait() // может увидеть счётчик == 0 до того, как выполнится хоть один Add

Add обязан произойти до того, как Wait сможет наблюдать счётчик — то есть до оператора go, в порождающей горутине. В записи выше исход решает планировщик: если Wait выполнится раньше, чем детей запланируют, он увидит ноль и вернётся — работа молча потеряна, или хуже: main выходит, и детей снимают посреди записи. Зеркальный вариант вместо этого дедлочится: ребёнок зовёт wg.Wait() (или шлёт в небуферизованный канал, читаемый после Wait), пока родитель держит то, что нужно ребёнку. Родная классика из той же семьи: передача WaitGroup по значению (Done копии никогда не дойдёт до оригинала — Wait блокируется навсегда) и повторное использование WaitGroup для второй волны до возврата первого Wait. Копию ловит go vet; гонку Add-с-Wait надёжно метит -race.

Инструментарий обнаружения

Знаменитая fatal error: all goroutines are asleep - deadlock! в сервисах почти бесполезна: она срабатывает, лишь когда каждая горутина заблокирована на видимых рантайму операциях — один живой accept-цикл или тикер глушит её. Продовые дедлоки частичны, и инструмент — goroutine-профиль:

import _ "net/http/pprof"

// живой дамп со стеками и длительностями ожидания:
//   curl localhost:6060/debug/pprof/goroutine?debug=2
//
// goroutine 412 [sync.Mutex.Lock, 16 minutes]:   ← длительность = улика
//   main.Transfer ... transfer.go:42
// goroutine 9817 [sync.Mutex.Lock, 16 minutes]:
//   main.Audit ... audit.go:31
// 9412 @ ... sync.Mutex.Lock main.(*Handler).Charge   ← кластер жертв

Читайте как детектив, в три прохода. Первый — размеры кластеров (debug=1 группирует одинаковые стеки): 9 412 горутин на одной строке Lock — куча жертв, называющая спорный лок. Второй — длительности ожидания (debug=2): многоминутные semacquire или chan send отделяют дедлок от обычной контеншн, которая крутится. Третий — найти держателей: одна-две горутины, заблокированные на другом локе, чем кластер, — они держат то, чего хочет кластер, и хотят того, что держит друг друга; их два стека — ваш цикл, с файлом и строкой. Дополните набор: go test -race для гоночных родственников (форма C), go vet для копий WaitGroup и mutex-профиль (runtime.SetMutexProfileFraction + /debug/pprof/mutex), чтобы видеть, как контеншн трендится к обрыву, прежде чем вы с него упадёте. Вместе три прохода превращают загадочный таймаут в файл и строку за десять минут — без рестарта процесса и без потери улик.

Профилактика: скучные правила, переживающие три часа ночи

Каждое правило ниже — один из трёх постмортемов, вывернутый наизнанку. Держите критические секции крошечными — лок, правка памяти, анлок; вычисления и I/O снаружи. Никогда не блокируйтесь под мьютексом: ни операций с каналами, ни RPC, ни Wait — копия под локом, действие после освобождения. Один задокументированный порядок локов на пакет (или порядок по внутреннему ключу для динамических пар), принуждаемый на ревью, потому что никакой инструмент не принудит его за вас. Add до go и никогда внутри ребёнка; WaitGroup только по указателю; -race в CI всегда — он ловит форму C и сотню родственников. И держите net/http/pprof подключённым в проде до инцидента: дедлок, который можно сдампить одним curl, — диагноз за 5 минут, а тот же дамп после рестарта не показывает вообще ничего.