Почему горутины дёшевы

Стек, который растёт

У потока ОС стек фиксированный — мегабайт на поток, который нужно выделить и удерживать. У горутины стартовый стек — минимум около 2 килобайт, и это деталь реализации, а не закон языка: с Go 1.24 стартовый размер адаптивен — runtime подстраивает его по среднему размеру стеков после GC. Когда код упирается в предел, runtime выделяет стек вдвое больше и копирует туда данные. Сто тысяч горутин с килобайтными стеками — это сотни мегабайт, а не сотни гигабайт.

Парковка вместо блокировки

Когда горутина делает блокирующую операцию — ждёт канал (о каналах — следующий модуль,), спит, ждёт мьютекс — она не «занимает поток, пока ждёт». Планировщик паркует её: сохраняет состояние, убирает из очереди, а M берёт следующую G.

<!-- wp:code-run/run {"code":"ch := make(chan int)\ngo func() {\n

Пока горутина спит, ни M, ни P за ней не закреплены. Отсюда вывод: блокировка в одной горутине не останавливает остальные — заблокированная G просто выбывает, её место занимает другая.

Что это значит на практике

Тысячи горутин, ожидающих данные из сети, не стоят тысяч потоков. Один поток переключается между многими горутинами, исполняя готовые. Поэтому Go-сервисы держат сотни тысяч одновременных соединений на скромном железе — а модель «поток на соединение» упирается в память уже на десятках тысяч. Миллион загрузок «Полки» — это нагрузка на входящие, а не на память стеков.

Вы узнаете:

• как runtime решает, когда расширять стек
• что даёт парковка против явных точек async/await

Маленький растущий стек (стартовый минимум ~2 КБ, точный размер — деталь runtime) + парковка = горутины дёшевы, а блокировки «бесплатны» для планировщика.