Горутины и планировщик: дешёвые стеки, GMP и утечки, переживающие запрос

Почему горутина стоит ~2 КБ, а поток — мегабайты

Поток ОС дорог по двум статьям: его стек резервируется заранее (8 МБ виртуальной памяти по умолчанию на Linux — проверьте ulimit -s), а каждая блокировка/пробуждение — это переключение контекста в ядре, примерно 1–2 мкс плюс загрязнение кэшей. Горутина стартует со стеком ~2 КБ, который рантайм растит и сжимает по требованию: пролог каждой функции проверяет запас, и при переполнении рантайм выделяет сегмент побольше и копирует стек целиком (непрерывные стеки, с Go 1.4 — указатели внутрь стека переписываются при копировании). Переключение между горутинами — обмен регистров в пользовательском пространстве, порядка десятков наносекунд, без ядра. Этот разрыв в три порядка — вся суть: 10 000 потоков — инцидент, 10 000 горутин — обычный вторник. Честная цена: горутины невидимы для ОС, поэтому системные инструменты (top, счётчики потоков) ничего не скажут о их количестве — это знает только рантайм.

GMP: как планировщик на самом деле размещает работу

Планировщик рантайма жонглирует тремя сущностями. G — горутина: стек плюс сохранённые регистры. M — поток ОС, которым владеет рантайм. P — процессор: токен планирования с локальной очередью G; их ровно GOMAXPROCS (по умолчанию — число ядер CPU, а с Go 1.25 значение по умолчанию учитывает и cgroup-лимиты CPU в контейнерах — до этого под с квотой 2 CPU на 64-ядерной ноде получал GOMAXPROCS=64 и сам себя троттлил; классическим фиксом был automaxprocs от Uber). Чтобы исполнять Go-код, M обязан держать P. Хореография такая:

• Новая G попадает в локальную очередь текущего P (256 слотов); переполнение сливается в глобальную очередь.
• Простаивающий P с пустой очередью крадёт половину очереди случайного другого P — work stealing держит ядра занятыми без центрального лока.
• Когда G блокируется в сисколле, её M застрял в ядре — и рантайм передаёт P другому M (припаркованному или новому), а остальные G продолжают работать. Поэтому одно медленное чтение с диска не останавливает остальные 9 999 горутин.
• Блокировка на канале или мьютексе ещё дешевле: G паркуется внутри рантайма (ни один поток не блокируется вовсе), а M берёт следующую G из очереди.

// Наблюдаем за механикой: горутина на задачу, ограничена ядрами GOMAXPROCS.
func main() {
	fmt.Println("GOMAXPROCS =", runtime.GOMAXPROCS(0)) // 0 = читать, не устанавливать

	var wg sync.WaitGroup
	for i := 0; i < 100_000; i++ { // 100k горутин: ~200 МБ стеков — нормально
		wg.Add(1)
		go func(id int) {
			defer wg.Done()
			work(id) // рантайм планирует их по GOMAXPROCS P
		}(i)
	}
	wg.Wait()
	fmt.Println("still alive:", runtime.NumGoroutine()) // должно быть ~1
}

Вытеснение: кооперативное до 1.14, потом сигналы

До Go 1.14 планировщик был кооперативным: горутина уступала только в точках вызова функций (где живёт проверка стека). Плотный цикл — for { x++ } — не уступал никогда: он мог навечно занять P, заморить stop-the-world фазу сборщика мусора и подвесить программу. С Go 1.14 наблюдающий поток рантайма (sysmon) замечает G, работающую дольше ~10 мс, и шлёт её M сигнал (SIGURG на Unix); обработчик прерывает горутину на ближайшей безопасной инструкции. Циклы без вызовов больше не могут заклинить рантайм. Оставшаяся острая грань: вытеснение всё равно не мгновенно и не бесплатно — CPU-bound горутина получает кванты ~10 мс, поэтому 8 горячих циклов при GOMAXPROCS=8 всё равно заставят каждую чувствительную к задержке горутину ждать своей очереди. Тяжёлой по CPU работе место в ограниченном пуле, а не в безлимитных go.

Режим отказа: утечки горутин и pprof как перепись населения

Утечка горутины — это горутина, которая никогда не возобновится: заблокирована на канале, в который никто не отправит, на приёме, который никто не закроет, на ctx.Done(), который она не слушает, или на мьютексе, который держит уже завершившаяся горутина. Сборщик мусора не может её собрать — припаркованная горутина является GC-корнем (объектом, от которого сборщик мусора начинает обход и который никогда не освобождает), поэтому весь её стек и всё, на что он ссылается, остаётся живым. Утечки накапливаются: одна на неудачный запрос, умноженная на миллион запросов, — это наклонная из вступления. Обнаружение — goroutine-профиль:

import _ "net/http/pprof" // открывает /debug/pprof/ на дефолтном mux

// затем: go tool pprof http://localhost:6060/debug/pprof/goroutine
// или:   curl localhost:6060/debug/pprof/goroutine?debug=1
// Вывод группирует горутины по одинаковому стеку — утечка видна как
// один стек с огромным счётчиком, например:
//   1184202 @ 0x43a1c5 ... chan receive
//     github.com/acme/gw/internal/fanout.collect+0x9e

Читайте его как гистограмму: тысячи горутин, припаркованных на одной и той же строке, означают, что тот, кто их порождает, не позаботился об их выходе. Лекарство структурное, а не косметическое — каждый go должен отвечать на вопрос «как эта горутина завершится?»: контекст, на который она делает select, канал, который закроют, WaitGroup, которую кто-то ждёт. Выведите runtime.NumGoroutine() на дашборд; счётчик, который только растёт, — утечка в процессе. Честные числа: припаркованная горутина стоит ~2–4 КБ стека плюс всё, что захватило её замыкание (часто это и есть настоящая цена — захваченный буфер в 64 КБ превращает миллион утечек в 64 ГБ).