Модуль: Concurrency · Уровень: Senior

TL;DR#

Горутина — это легковесный поток исполнения, управляемый рантаймом Go, а не ОС. Стартовый стек ~2 КБ, растёт/сжимается копированием. Создаётся через go f(), планируется на потоки ОС моделью GMP. Завершается при возврате из функции; неперехваченная паника в горутине роняет весь процесс.

Теория#

Что такое горутина под капотом#

Горутина представлена структурой runtime.g (файл src/runtime/runtime2.go). Это не поток ОС: множество горутин мультиплексируется на ограниченное число потоков ОС (M) через логические процессоры (P). Ключевые поля g:

  • stack — границы стека (lo, hi).
  • stackguard0 — порог для проверки переполнения стека (morestack), также используется для preemption (выставляется в stackPreempt).
  • sched (gobuf) — сохранённый контекст (SP, PC, BP) для возобновления.
  • atomicstatus — состояние горутины.
  • goid, m, waitreason.

Стоимость#

ПараметрГорутинаПоток ОС
Стартовый стек~2 КБ1–8 МБ (зарезервировано)
Созданиесотни наносекунд, без syscallsyscall, микросекунды
Переключениев user-space, ~десятки нсчерез ядро, дороже
Кол-восотни тысяч / миллионытысячи (упирается в память)

Создание go f() компилируется в вызов runtime.newproc, который аллоцирует/переиспользует g (свободные g лежат в p.gFree и глобальном sched.gFree), кладёт её в runqueue текущего P.

Рост стека (segmented → contiguous)#

До Go 1.3 были сегментированные стеки (hot split проблема). Сейчас — непрерывный стек с копированием:

  1. В пролог каждой функции компилятор вставляет проверку SP < stackguard0.
  2. Если места не хватает, вызывается runtime.morestack.
  3. Рантайм аллоцирует новый стек вдвое больше, копирует содержимое, корректирует указатели (для этого нужны точные стек-мапы — поэтому в Go нет «голых» указателей внутрь стека без ведома GC).
  4. Старый стек освобождается; при сжатии (shrinkstack, во время GC) — наоборот.
// Глубокая рекурсия заставит стек расти многократным копированием
func deep(n int) {
    if n == 0 { return }
    var buf [1024]byte // давит на стек
    _ = buf
    deep(n - 1)
}

Состояния (atomicstatus)#

  • _Gidle — только создана.
  • _Grunnable — в очереди, готова к запуску.
  • _Grunning — исполняется на M (привязана к P).
  • _Gsyscall — в системном вызове.
  • _Gwaiting — заблокирована (канал, mutex, GC, time.Sleep).
  • _Gdead — завершилась/свободна (в пуле для переиспользования).
  • _Gcopystack — стек копируется (рост/сжатие).

Жизненный цикл#

go f()  → newproc → _Grunnable → (scheduler) → _Grunning
   ├─ блокировка (chan/mutex) → _Gwaiting → разблокировка → _Grunnable
   ├─ syscall → _Gsyscall → возврат → _Grunnable
   └─ return из f → goexit → _Gdead → пул gFree

При возврате из функции горутины выполняется runtime.goexit: запускаются отложенные defer (если не запущены), горутина переводится в _Gdead и кладётся в пул.

Паника в горутине#

Паника раскручивает стек только этой горутины, выполняя её defer. Если ни один defer не вызвал recover, рантайм печатает трейс и завершает весь процесс (fatal error). recover в другой горутине не помогает.

func main() {
    go func() {
        defer func() { recover() }() // ловит ТОЛЬКО панику в этой горутине
        panic("boom")
    }()
    // паника без recover здесь убила бы весь процесс
}

Подводные камни / gotchas#

  • Утечка горутины: заблокированная навсегда горутина (на канале/в select без выхода) не собирается GC — её корни (стек) живы. См. отдельный файл про leaks.
  • recover работает только в defer той же горутины. Защищайте каждую запускаемую горутину собственным recover, если паника в ней не должна ронять процесс.
  • Переменная цикла (до Go 1.22): for i := range ... { go func(){ use(i) }() } захватывал общую i. С Go 1.22 каждая итерация имеет свою переменную — проблема ушла, но на собеседовании про неё спрашивают.
  • os.Exit / возврат из main убивает все горутины немедленно, без defer.
  • Глубокая рекурсия → дорогое копирование стека; в горячем коде это заметно.
  • Нет API «убить горутину» извне — только кооперативная отмена через context/каналы.

Вопросы на собеседовании#

В: Чем горутина отличается от потока ОС? О: Горутина — пользовательская абстракция рантайма Go, мультиплексируемая на потоки ОС моделью GMP. Стартовый стек ~2 КБ против мегабайтов у потока; создание и переключение дешевле, без перехода в ядро в типичном случае; планирование кооперативно-вытесняющее в user-space. Это позволяет держать сотни тысяч горутин.

В: Как растёт стек горутины? О: Непрерывный стек, растёт копированием. Пролог функции сравнивает SP со stackguard0; при нехватке morestack аллоцирует вдвое больший стек, копирует данные и корректирует указатели по точным стек-мапам. Сжатие происходит при GC через shrinkstack.

В: Что произойдёт при панике в горутине без recover? О: Раскрутится стек этой горутины с выполнением её defer; если recover не вызван, рантайм печатает fatal error и завершает весь процесс. Recover в других горутинах не спасает.

В: Почему стартовый стек именно маленький, и в чём цена? О: Маленький стек даёт дешёвое создание и высокую плотность горутин. Цена — потенциальные операции роста/копирования при глубоких вызовах; для этого нужны точные стек-мапы и невозможность «спрятать» указатель в стек от рантайма.

В: Как горутина переходит в _Gwaiting и обратно? О: При блокировке (пустой/полный канал, mutex, sleep) рантайм вызывает gopark, переводя g в _Gwaiting и освобождая M/P. При наступлении события goready возвращает её в runqueue как _Grunnable.

В: Можно ли извне завершить горутину? О: Нет принудительного механизма. Только кооперативно: горутина сама должна проверять ctx.Done() или сигнальный канал и выходить. Поэтому долгоживущие горутины обязаны принимать context.

В: Что такое runtime.Gosched()? О: Добровольная уступка процессора: текущая горутина переводится в runnable и помещается в очередь, давая шанс другим. Редко нужна напрямую; полезна в тесных циклах без точек преемпции (до async preemption была частым воркэраундом).

В: Куда деваются завершённые горутины? О: Переходят в _Gdead и кладутся в пул gFree (на P и глобальный) для переиспользования структуры g и стека, чтобы не аллоцировать заново.

На что копают на senior+#

  • Точные стек-мапы и почему они нужны для перемещения стека и precise GC.
  • Взаимодействие роста стека с async preemption (signal-based) и safe points.
  • Переиспользование g и стеков через gFree, влияние на латентность.
  • Влияние глубокой рекурсии и больших стек-фреймов на p99 латентность из-за morestack.
  • Почему recover обязан быть в отложенном вызове и как это связано с механизмом раскрутки _panic/_defer.
Backward context sync.Mutex и sync.RWMutex Forward