Горутины в Go

Почему их можно так много

Измерим цену горутины честно. Запускаем сто тысяч штук, все блокируются на канале, и смотрим статистику памяти: стеки выросли на 195,6 мегабайта, куча - на 56,2. Делим на сто тысяч: 2048 байт стека плюс 589 байт служебных структур, итого около 2,6 килобайта на горутину.

Два килобайта - это стартовый размер стека, и он не фиксированный. Когда горутине не хватает места, рантайм выделяет стек вдвое больше, копирует туда содержимое и правит указатели. Поэтому глубокая рекурсия работает, а мелкая функция не платит за чужие потребности.

Переключение тоже другое. Смена потока ОС идёт через ядро с сохранением полного контекста, смена горутины происходит в пользовательском пространстве силами планировщика Go, который сам мультиплексирует тысячи горутин на несколько потоков.

// «Дёшево» не значит «бесплатно». Двести пятьдесят мегабайт за сто тысяч горутин - вполне ощутимая сумма, а если каждая держит буфер или соединение, счёт идёт на гигабайты. Плюс утечка горутин - совершенно реальный класс багов, и растущий runtime.NumGoroutine - первый признак.

горутина

лёгкая задача рантайма Go, которую планировщик раскладывает по потокам ОС

растущий стек

стартует с 2 КБ и увеличивается копированием, когда места не хватает

Конкурентность против параллелизма

Конкурентность - про структуру программы: она описана как несколько независимо продвигающихся задач. Параллелизм - про физику: задачи реально исполняются одновременно на разных ядрах. Это разные вещи, и путать их на собеседовании - классическая ошибка.

Проверить легко. На машине с двумя ядрами runtime.NumCPU возвращает 2 и GOMAXPROCS по умолчанию тоже 2 - значит одновременно исполняются максимум две горутины, а сто тысяч запущенных просто чередуются. Программа при этом полностью конкурентна и написана правильно.

Обратное тоже верно: параллелизм сам по себе не ускоряет плохо структурированную программу. Если все горутины дерутся за один мьютекс, восемь ядер не помогут - они будут стоять в очереди.

// С Go 1.14 планировщик вытесняет горутины асинхронно, по сигналу от рантайма. До этого плотный счётный цикл без вызовов функций мог удерживать поток сколько угодно и мешал даже сборщику мусора. Сейчас такой цикл прервут принудительно.

GOMAXPROCS

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

Жизненный цикл: main не ждёт никого

Горутина живёт ровно до возврата из своей функции. И есть жёсткое правило сверху: когда возвращается main, процесс завершается немедленно, не дожидаясь никого. Запустил горутину и вернулся из main - она может не выполниться вовсе, и это не гонка, а гарантированное поведение.

Отсюда необходимость явно дожидаться: sync.WaitGroup, канал завершения, контекст. time.Sleep в качестве ожидания - признак того, что человек не разобрался: он и не гарантирует ничего, и замедляет.

Второе правило неприятнее. Паника внутри горутины не перехватывается снаружи. Проверено: recover в main не спасает - процесс падает целиком с трассировкой той горутины, где рвануло, и строчка после ожидания не печатается никогда.

// Практический вывод: у каждой долгоживущей горутины, особенно обрабатывающей внешний ввод, свой defer с recover внутри неё самой. Иначе одна кривая запись из очереди роняет весь сервис.

go func() { panic("внутри горутины") }()
time.Sleep(time.Second)
// recover в main НЕ поможет: процесс падает целиком
// panic: внутри горутины
// goroutine 10 [running]: ...

Как отвечать: «Чем горутина отличается от потока ОС?»

Тремя вещами: ценой, стеком и тем, кто её переключает. Поток ОС получает фиксированный стек - в Linux по умолчанию восемь мегабайт - и переключается через ядро. Горутина стартует со стека в два килобайта, который растёт копированием по мере надобности, и переключается планировщиком Go в пользовательском пространстве. Я мерил: сто тысяч горутин занимают около двухсот пятидесяти мегабайт, то есть примерно 2,6 килобайта на штуку - две тысячи стека плюс служебные структуры. Сто тысяч потоков ОС попросили бы сотни гигабайт, поэтому их и не бывает. Рантайм мультиплексирует горутины на небольшое число потоков, а сколько из них исполняется физически одновременно, задаёт GOMAXPROCS - по умолчанию по числу ядер. Отсюда же и разница между конкурентностью и параллелизмом: конкурентность - про структуру программы, параллелизм - про одновременное исполнение. И я бы добавил, что дёшево не значит бесплатно: горутина держит стек и запись в планировщике, утечка горутин - реальный класс багов, а паника внутри горутины роняет весь процесс, если не перехвачена там же.

Три оси сравнения с измеренными числами, разведены конкурентность и параллелизм, и сразу названы две практические опасности - видно, что человек эти горутины запускал в проде.

На чём валят

• −Считают горутину «лёгким потоком ОС» - у неё другой стек, другой планировщик и другая цена.
• −Ждут завершения горутин через time.Sleep вместо WaitGroup или канала.
• −Забывают, что возврат из main убивает процесс, не дожидаясь запущенных горутин.
• −Думают, что панику в горутине можно перехватить снаружи - нельзя, падает весь процесс.
• −Путают конкурентность и параллелизм и обещают ускорение от GOMAXPROCS там, где всё стоит на мьютексе.
• −Считают горутины бесплатными: сто тысяч штук - это четверть гигабайта на пустом месте.