У процесса своё изолированное адресное пространство и набор ресурсов ядра. Внутри процесса планируются потоки: у каждого свой стек и регистры, а память общая; переключение между потоками стоит входа в ядро и порядка микросекунды. Горутину планирует сам рантайм, и ядро о ней не знает вообще.

Три источника дешевизны

1. Стек. Поток резервирует фиксированный (1–8 МБ виртуально, страницы подтягиваются по обращению). Горутина стартует от 2 КБ реальной памяти и растёт копированием. Миллион потоков занимает терабайты виртуального адресного пространства, а миллион горутин обходится несколькими гигабайтами реальной памяти.
2. Переключение. Сменить горутину значит сохранить SP, PC и указатель на g в gobuf и загрузить другие. Не нужно менять привилегии, не нужно сбрасывать TLB, кэши остаются тёплыми. ~50–200 нс против 1–2 мкс.
3. Кто планирует. Планировщик Go знает семантику: он видит, что горутина встала на канале, и переключает мгновенно, а не ждёт истечения кванта. Ядро такого не знает.

Чем горутина хуже потока

• Нет приоритетов, нет affinity к ядру, нет real-time гарантий.
• Нельзя убить извне (см. отдельный вопрос).
• Настоящий блокирующий syscall всё равно займёт целый поток ОС.
• Нет изоляции: паника в любой горутине без recover роняет весь процесс.

Механика

Компилятор вставляет в пролог почти каждой функции сравнение указателя стека с g.stackguard0. Если для кадра места не хватает, управление уходит в runtime.morestack, оттуда в newstack и copystack: выделить блок вдвое больше, скопировать байты, обойти все указатели, которые смотрели внутрь старого стека, и сдвинуть их на разницу адресов. Для этого компилятор хранит точные карты указателей на каждый safe-point: тот же механизм обслуживает и точный GC.

Обратное делает shrinkstack: во время GC, если горутина использует меньше четверти своего стека, он ужимается вдвое.

Историческая часть, которую любят спрашивать

До Go 1.3 стеки были сегментированными: новый кусок связывался со старым списком. Проблема называлась «hot split»: если граница сегмента попадала внутрь горячего цикла, каждая итерация выделяла и освобождала сегмент, и профиль проваливался на порядок. В 1.3–1.4 перешли на копирующие стеки, а начальный размер снизили с 8 КБ до 2 КБ.

// Показать рост стека можно так:
func deep(n int) {
    var pad [512]byte           // чтобы кадр был заметным
    _ = pad
    if n > 0 { deep(n - 1) }
}
// gctrace рост стека не покажет. Его видно в CPU-профиле как runtime.morestack
// и runtime.copystack: go test -run TestDeep -cpuprofile cpu.out

Конкурентная программа остаётся конкурентной на одном ядре: GOMAXPROCS=1 не мешает запустить тысячу горутин, они просто будут чередоваться. Параллелизм появляется, когда ядер больше одного и GOMAXPROCS > 1. Отсюда несимметричность: конкурентность даёт возможность параллелизма, но не наоборот.

Пример, который лучше мантры

HTTP-сервер, который на каждый запрос ходит в базу и в стороннее API. На одном ядре он всё равно обслужит тысячу одновременных соединений: пока одна горутина ждёт ответа сети, ядро свободно, и на нём работает другая. Это чистая конкурентность без параллелизма, и выигрыш тут не от ядер, а от того, что ожидание не блокирует.

Теперь обратный случай: посчитать SHA-256 от тысячи файлов. Это CPU-bound работа, и конкурентность сама по себе не ускорит ничего: на одном ядре тысяча горутин посчитает ровно столько же, сколько один цикл, только с накладными расходами на переключения. Ускорит именно параллелизм: восемь ядер дадут примерно восьмикратный выигрыш.

Зачем понадобился P

В Go 1.0 модель была GM: одна глобальная очередь под одним мьютексом. На многоядерных машинах это упиралось в contention, а ещё убивало локальность: горутина могла уехать на любой поток, и кэш процессора обнулялся. В Go 1.1 Дмитрий Вьюков добавил P: теперь у каждого P своя очередь на 256 слотов (lock-free кольцевой буфер) и свой mcache, так что обычные аллокации и планирование идут без единого атомарного конфликта.

Порядок поиска работы (findRunnable)

1. раз в 61 тик: одна горутина из глобальной очереди (чтобы та не голодала);
2. runnext: слот на одну «только что созданную/разбуженную» горутину, ради локальности кэша;
3. локальная очередь P;
4. глобальная очередь: пачкой len/GOMAXPROCS + 1;
5. неблокирующий netpoll;
6. work stealing: до 4 попыток украсть половину очереди у случайного P;
7. ничего нет, и тогда P в idle-список, M паркуется.

Где рождается горутина

go f() кладёт новую G в runnext текущего P, а прежнюю горутину из этого слота сдвигает в локальную очередь. Если та переполнена (256 штук), половина её вместе с выбитой из runnext горутиной уезжает в глобальную очередь одним батчем. Это и есть «перелив»: одному P не дают накопить всё.

Цепочка такая: G → (P) → M → поток ОС → ядро. Горутина попадает в очередь P; M, владеющий этим P, снимает её и исполняет; поток ОС планируется ядром на физическое ядро по своим правилам. Go не управляет affinity и не может «прибить» горутину к ядру: ближайшее, что есть, это runtime.LockOSThread: она прибивает горутину к конкретному потоку (нужно для OpenGL, некоторых C-библиотек и Linux namespace).

Количественно

• G: сколько запустил, столько и есть, упираешься только в память.
• P: ровно GOMAXPROCS, фиксировано на время работы (в 1.25 может меняться при смене cgroup-лимита).
• M: динамически. Рантайм создаёт новый M, когда текущий уходит в блокирующий syscall и P нужно отдать другому. Потолок 10 000.

Поэтому в проде число потоков работает как диагностика. GOMAXPROCS=8 и 12 потоков это норма. GOMAXPROCS=8 и 600 потоков значат, что где-то массово блокирующие syscall или cgo, и это стоит памяти (у каждого M ещё и свой системный стек) и переключений контекста.

// сколько потоков у процесса
// Linux:  cat /proc/<pid>/status | grep Threads
// изнутри программы:
import "runtime/pprof"
p := pprof.Lookup("threadcreate")   // сколько потоков вообще создавалось
fmt.Println(p.Count())              // 5 на пустой программе с GOMAXPROCS=14.
                                    // Число зависит от машины и от истории процесса,
                                    // а не от текущего числа живых потоков

Блокирующий syscall

1. Перед вызовом рантайм зовёт entersyscall: сохраняет контекст горутины и переводит её в состояние _Gsyscall (до Go 1.26 ещё и P помечали как _Psyscall).
2. Если syscall возвращается быстро, exitsyscall подхватывает тот же P: дешёвый быстрый путь.
3. Если нет, sysmon через ~20 мкс видит, что горутина всё ещё в _Gsyscall, и делает handoffp: отбирает P и отдаёт другому M (взяв свободный или создав новый). Работа на этом ядре продолжается.
4. Когда syscall наконец вернётся, «осиротевший» M попробует получить любой свободный P; если не выйдет, положит горутину в глобальную очередь и припаркуется в пуле потоков.

netpoller

Всё, что открыто через пакет net (и os.Pipe, и таймеры на части платформ), рантайм переводит в O_NONBLOCK и регистрирует в поллере. Вызов conn.Read внутри выглядит так: попытка read → EAGAIN → gopark горутины со ссылкой на её g в pollDesc. Горутина снята с потока, поток пошёл выполнять следующую.

Поллер дёргают в трёх местах: в findRunnable (неблокирующий netpoll), перед парковкой последнего M (блокирующий, иначе некому будет проснуться) и в sysmon, если сеть не опрашивали больше 10 мс. Готовые горутины переводят в _Grunnable и кладут в очередь.

Кооперативное вытеснение

Планировщик записывает в g.stackguard0 специальное значение stackPreempt. Пролог следующей вызванной функции сравнивает SP с этим полем, «видит переполнение», уходит в morestack, а тот распознаёт флаг и передаёт управление планировщику. Механизм роста стека переиспользован тут красиво, но работает только там, где есть вызов функции.

// Go 1.13 и раньше: программа зависала намертво
func main() {
    runtime.GOMAXPROCS(1)
    go func() { for { } }()     // ни вызовов, ни аллокаций: вытеснить негде
    time.Sleep(time.Second)
    fmt.Println("недостижимо в 1.13")
}

// запуск на go1.27: строка печатается через секунду, асинхронное вытеснение работает.
// недостижимо в 1.13

Асинхронное вытеснение (Go 1.14)

Sysmon замечает горутину, работающую дольше 10 мс, и шлёт её потоку сигнал SIGURG. Обработчик проверяет, что точка «асинхронно безопасна» (в ней нет «спрятанных» указателей и незавершённой работы с ними, мы не в критической секции рантайма, не в //go:nosplit-функции), и подменяет адрес возврата на runtime.asyncPreempt: та сохраняет весь регистровый файл и уходит в планировщик. SIGURG выбрали потому, что он реально не используется и не мешает отладчикам.

Где всё ещё можно «захватить» процессор

• Внутри cgo-вызова: сигнал не поможет, чужой код мы не контролируем.
• В функциях рантайма с //go:nosplit и с отключёнными сигналами.
• При GODEBUG=asyncpreemptoff=1: его иногда включают для отладки, потому что асинхронное вытеснение мешает воспроизводить некоторые баги.
• Логически: горутина держит мьютекс и молотит цикл. Её вытеснят, но лок она не отдаст, и все ожидающие всё равно стоят. Вытеснение спасает планировщик, а не твой дизайн.

Что именно ограничивает

Не число потоков и не число горутин, а количество контекстов P. Одновременно исполняется Go-код максимум в GOMAXPROCS горутинах. Потоков при этом может быть сколько угодно: те, что сидят в блокирующих syscall, P не держат.

Проблема контейнеров

Под с limits.cpu: "1" на 64-ядерной ноде до Go 1.25 получал GOMAXPROCS=64, потому что runtime.NumCPU() читает маску affinity, а не cgroup-квоту. Дальше включается CFS throttling: cgroup выдаёт квоту на период 100 мс, 64 потока выжирают её за первые единицы миллисекунд, и остаток периода контейнер заморожен. Симптомы: рваные p99, «непонятные» лаги, метрика container_cpu_cfs_throttled_seconds_total ползёт вверх. GC тоже страдает: он масштабируется по GOMAXPROCS и создаёт лишних воркеров.

Что делать

// До Go 1.25 стандарт де-факто:
import _ "go.uber.org/automaxprocs"    // при старте читает cgroup v1/v2 и ставит GOMAXPROCS

// В Go 1.25 (нужно go >= 1.25 в go.mod) это в рантайме:
//   default = min(runtime.NumCPU(), ceil(cgroup CPU limit)), минимум 2
//   значение обновляется само при смене лимита (опрос ~раз в секунду)
//   GOMAXPROCS(0) больше не «замораживает» значение, а просто читает
//   выключить: GODEBUG=containermaxprocs=0,updatemaxprocs=0
//   переопределить: переменная окружения GOMAXPROCS=N или runtime.GOMAXPROCS(n)

Считаем стоимость

• Стек 2 КБ минимум, но после первого же вызова с локальными массивами это 4–8 КБ. Миллион → 2–8 ГБ.
• Структура g весит сотни байт, плюс место в очередях.
• Работа GC: каждый стек это корень для сканирования. Миллион корней ощутимо удлиняет фазу сканирования и STW-моменты.
• Планировщик: миллион элементов в очередях, стилинг чаще, локальность хуже.

// Это отработает, но посмотри на RSS процесса
var wg sync.WaitGroup
for i := 0; i < 1_000_000; i++ {
    wg.Add(1)
    go func() { defer wg.Done(); time.Sleep(time.Second) }()
}
fmt.Println(runtime.NumGoroutine())   // 1000001, а не 1000000:
                                      // NumGoroutine считает и саму main-горутину
wg.Wait()

Когда ок

• Горутина «лёгкая»: держит только сокет и маленький буфер (классика: сервер на сотни тысяч WebSocket-соединений).
• Работа I/O-bound, горутины почти всегда спят в netpoller.
• Нет общего узкого места: общего мьютекса, общей мапы, одного канала-бутылочного горлышка.

Когда нет

• Каждая горутина открывает соединение к БД: пул на 20 коннектов, миллион ожидающих это очередь, а не параллелизм. Ограничивать надо на входе.
• Каждая держит буфер на 32 КБ, вот и 32 ГБ.
• CPU-bound задачи: больше GOMAXPROCS считающих горутин пользы не даёт, только оверхед на переключения.
• Горутина на каждый элемент коллекции, типичный антипаттерн: дешевле пул из GOMAXPROCS воркеров.

Почему так спроектировано

Принудительно убивать поток давно считается ошибкой дизайна (в Java Thread.stop deprecated с 1.2). Убитая горутина оставила бы за собой захваченные мьютексы, недописанные структуры данных, незакрытые файлы и невыполненные defer. Go выбрал единственный безопасный вариант: горутина сама решает, где ей корректно закончиться.

Правильный шаблон

func worker(ctx context.Context, in <-chan Job, out chan<- Result) error {
    for {
        select {
        case <-ctx.Done():
            return ctx.Err()                 // выходим явно
        case job, ok := <-in:
            if !ok {
                return nil                   // источник закрыт, штатно завершаемся
            }
            res, err := handle(ctx, job)     // ctx прокидываем внутрь, иначе отмена не дойдёт
            if err != nil {
                return err
            }
            select {                          // отправка тоже должна отменяться
            case out <- res:
            case <-ctx.Done():
                return ctx.Err()
            }
        }
    }
}

Три частые ошибки

• Отмену проверяем, а отправку нет. Классическая утечка: горутина увидела ctx.Done(), но зависла на out <- res, потому что читателя уже нет. Каждая блокирующая операция должна быть в select с ctx.Done().
• Долгая работа без точек проверки. Если внутри цикл на минуту, проверяй ctx.Err() внутри цикла, а не только снаружи.
• ctx не прокинут в вызываемый код. Отдавай ctx в db.QueryContext и в http.NewRequestWithContext, иначе отмена «застрянет» на первом же блокирующем вызове.

runtime.Gosched()

Вызывает mcall(gosched_m): горутину переводят из _Grunning в _Grunnable, кладут в глобальную очередь (важно: не в локальную, чтобы дать шанс другим P), и M идёт выбирать следующую. Горутина не блокируется и не спит, она просто пропускает ход.

После Go 1.14 нужда в нём почти отпала: асинхронное вытеснение справляется само. Остались редкие случаи: бенчмарки и тесты, где нужно спровоцировать переключение; очень длинные вычислительные циклы, где хочется отдать управление раньше 10 мс; спин-ожидание в низкоуровневом коде.

// Gosched не годится для синхронизации: он не барьер и не даёт happens-before
var ready bool
go func() { data = compute(); ready = true }()
for !ready { runtime.Gosched() }   // гонка: компилятор вправе вынести !ready из цикла
// правильно: канал, sync.WaitGroup или atomic.Bool

runtime.NumGoroutine()

Возвращает gcount(): число горутин в состояниях, отличных от «мертва» и «системная». Стоит это несколько атомарных чтений, так что вешать на /metrics можно спокойно, хоть каждую секунду.

// Эта метрика нужна любому Go-сервису: по ней ловят утечку горутин
goroutines := prometheus.NewGaugeFunc(
    prometheus.GaugeOpts{Name: "go_goroutines_current"},
    func() float64 { return float64(runtime.NumGoroutine()) },
)
// Растущий без насыщения график = утечка. Дальше:
//   curl localhost:6060/debug/pprof/goroutine?debug=2
// и смотрим, на какой строке они все стоят.

1. sync.WaitGroup - когда горутин много и результат не нужен

var wg sync.WaitGroup
for _, u := range urls {
    wg.Add(1)                          // Add до go, не внутри горутины
    go func() {                        // Go 1.22+: u уже своя на каждой итерации
        defer wg.Done()                // Done в defer сработает и при панике
        fetch(u)
    }()
}
wg.Wait()

// В Go 1.25 то же короче, и Add/Done уже не забудешь:
var wg sync.WaitGroup
for _, u := range urls {
    wg.Go(func() { fetch(u) })
}
wg.Wait()

2. Канал-сигнал - когда горутина одна

done := make(chan struct{})
go func() { defer close(done); work() }()
<-done                                 // ждём

// с таймаутом:
select {
case <-done:
case <-time.After(5 * time.Second):
    return errors.New("timeout")       // горутина продолжит работать, см. предупреждение ниже
}

3. errgroup - когда нужны ошибки и отмена

g, ctx := errgroup.WithContext(ctx)
g.SetLimit(8)                          // не больше 8 одновременно
for _, u := range urls {
    g.Go(func() error { return fetch(ctx, u) })
}
if err := g.Wait(); err != nil {       // вернёт первую ошибку и отменит ctx для остальных
    return err
}

4. Канал результата - когда нужно одно значение

res := make(chan Result, 1)            // буфер 1, чтобы отправитель не завис, если мы ушли
go func() { res <- compute() }()
r := <-res