Горутины и планировщик Go: две тысячи байт, вытеснение и GOMAXPROCS, который ограничивает не то, что думают

Что здесь на самом деле спрашивают

Лестница почти всегда такая:

1. «Чем горутина отличается от потока?» — проверяют, назовёте ли вы число.
2. «Сколько она стоит?» — вопрос на честность: «мало» без числа не ответ.
3. «Что такое GMP?» — три буквы знают многие; смысл P — немногие.
4. «Что ограничивает GOMAXPROCS?» — здесь чаще всего отвечают «число горутин», и это неверно.
5. «Планировщик вытесняющий или кооперативный?» — вопрос с датой: до Go 1.14 и после.
6. «Когда горутина уходит с процессора?» — про парковку и точки переключения.

Дальше урок идёт по этой лестнице. Спина у неё одна: горутина — это объект рантайма, а не объект операционной системы.

База: горутина — это не поток операционной системы

Начинать стоит с того, чем горутина не является: почти все неверные ответы на собеседовании растут из одного и того же переноса — из привычки думать о ней как о потоке.

Поток операционной системы — сущность ядра, и он дорогой: своя запись в ядре, свой стек в мегабайты, каждое переключение идёт через ядро. Потоков поэтому заводят единицы и десятки, и каждый запуск обдумывают заранее.

Горутина — сущность самой программы на Go, и три её свойства нужно назвать до всякой механики:

1. Она не поток. Под тысячей горутин работает не тысяча потоков, а заметно меньше — счёт идёт на единицы.
2. Её запуск стоит одного слова в коде. Перед обычным вызовом ставится go, вызов начинает выполняться сам по себе, а программа идёт дальше, не дожидаясь его конца.
3. Их бывает очень много. Тысяча горутин — не нагрузка, а обычное состояние сервера, и упирается их число в память, а не в запрет.

Отсюда и главный вопрос урока: если горутин тысячи, а мест, где можно выполняться, единицы — кто и как раздаёт эти места? Ответ такой: этим занимается сама программа на Go. Внутри неё живёт планировщик, который решает, какая горутина сейчас на процессоре, и раскладывает тысячи горутин по нескольким потокам — не спрашивая ядро на каждое переключение.

Этого уже достаточно, чтобы ответить на базовый вопрос собеседования «чем горутина отличается от потока». Всё дальнейшее — про то, насколько именно она дешевле, кто и по каким правилам раздаёт процессорное время, что происходит, когда горутина ушла ждать, и почему одна горутина не может занять место навсегда.

Механизм 1: какую задачу решает планировщик

Прежде чем разбирать буквы, стоит сказать, зачем эта машинерия вообще существует. Задача у планировщика ровно одна, и формулируется она без единого термина Go:

Готовых к выполнению горутин на порядки больше, чем мест, где можно выполняться. Мест — по числу ядер; горутин — сколько создала программа.

Всё остальное в уроке — ответы на вопросы, которые из этой картинки следуют: кто решает, какая G займёт свободное место; что делать, когда занявшая место горутина ушла ждать; и как не дать одной горутине занять место навсегда.

Ответ Go на эту задачу состоит из двух решений. Первое — сделать единицу работы дешёвой, чтобы тысячи и миллионы были нормой. Второе — планировать их в пространстве пользователя, не обращаясь к ядру на каждое переключение.

Начнём с первого, потому что оно измеримо.

Горутина — структура рантайма, и её можно взвесить

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

Отсюда числа. Замерено на тысяче спящих горутин (bench/gosched/practice.go), делением на тысячу:

Два килобайта — это _StackMin из runtime/stack.go, «минимальный размер стека для новых горутин». И это не предел, а старт: стек растёт по мере надобности, копируясь на новое место, и потому не приходится закладываться на максимум заранее.

И границу у этого числа называет то же место, откуда оно взято: _StackMin — константа рантайма, а не обещание языка. Поэтому правило пишется не от двух тысяч, а от порядка величины: горутина стоит килобайты там, где поток ОС стоит мегабайты, — и переживёт смену версии именно эта разница, а не само число.

Про эти два числа стоит сказать отдельно. Первая редакция замера считала только HeapAlloc и получила ~500 байт — число, которое противоречит общеизвестному «горутина стоит два килобайта». Противоречия нет: стек горутины в HeapAlloc не входит вовсе, он учитывается отдельно, в StackInuse. Одно число без другого даёт неверный ответ, и на собеседовании стоит называть оба.

Практический вывод, который и хотят услышать: миллион горутин — это гигабайты, а не безумие. Миллион потоков ОС невозможен, миллион горутин — вопрос памяти.

Механизм 2: G, M и P — и весь смысл в третьей букве

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

G и M понятны без объяснений. Весь смысл — в P, и объяснять его надо не как «процессор», а как право: право выполнять код Go. Прав ровно GOMAXPROCS штук, и поток, оставшийся без права, код Go не выполняет.

Зачем такая прослойка? Затем, что она разводит два разных ограничения:

• сколько горутин может считать одновременно — это число P;
• сколько потоков ОС существует — это число M, и оно больше: когда горутина уходит в системный вызов, её M блокируется вместе с ней, отдаёт своё P другому потоку, и работа продолжается.

Именно поэтому в документации отдельно сказано:

Очереди и кража работы

Из программы очереди не наблюдаемы, поэтому здесь без чисел — но устройство стоит назвать, потому что из него следует главное свойство планировщика.

Освободился P — берёт из своей локальной очереди; если пуста, из общей; если и там пусто, крадёт половину у соседа.

Зачем локальные очереди вообще. Общая очередь на всех требовала бы замка на каждое планирование — то есть состязания тем сильнее, чем больше ядер. Локальная очередь обходится без синхронизации в обычном случае, и замок нужен только при краже.

Кража работы — то, почему нагрузка распределяется без диспетчера. Никто не раскладывает горутины по процессорам; простаивающий P сам ищет себе работу. У этого есть наблюдаемое следствие: горутина может начать выполняться на одном ядре и продолжить на другом, и рассчитывать на «своё» ядро нельзя.

Механизм 3: системный вызов и ввод-вывод — два разных пути

Два способа «уйти ждать» устроены по-разному, и разницу спрашивают.

Системный вызов блокирует поток. M уходит в ядро вместе с горутиной — ядро не знает ни про какие горутины. Чтобы простой не остановил остальную работу, планировщик отбирает P у этого M и отдаёт другому потоку.

Отсюда и оговорка документации про GOMAXPROCS: заблокированные в системных вызовах потоки в предел не входят. Число M больше числа P, и растёт оно именно так.

Сетевой ввод-вывод поток не блокирует. Здесь работает netpoller: сокет переводится в неблокирующий режим, горутина паркуется, а M остаётся со своим P и берёт следующую работу. Когда данные пришли, ядро уведомляет рантайм (epoll, kqueue, IOCP), и горутина возвращается в очередь готовых.

Вот почему сервер на Go держит десятки тысяч соединений на нескольких потоках: ожидание сети не стоит потока. А чтение файла — стоит, потому что для дисковых операций такого механизма нет.

Полный список причин уйти с процессора

Список короткий, и его стоит уметь назвать:

• сама заблокировалась — канал, мьютекс, WaitGroup, сетевой ввод-вывод;
• системный вызов — M уходит в ядро вместе с горутиной и отдаёт своё P;
• ожидание сети — горутина паркуется, а M со своим P работает дальше;
• runtime.Gosched() — добровольная уступка;
• вытеснение по времени — примерно каждые 10 мс, сигналом, с Go 1.14;
• сборка мусора — на короткие остановки всего мира.

И отдельно — main не ждёт никого:

Возврат из main завершает процесс, и все запущенные горутины умирают на месте — без отложенных вызовов и без шанса дописать что-либо. Ждать надо явно: sync.WaitGroup, канал или errgroup.

Механизм 4: планировщик вытесняющий — но только с Go 1.14

Вопрос с датой, и знать надо обе половины.

До Go 1.14 планировщик был кооперативным: он мог переключиться только там, где горутина сама давала повод — вызов функции, обращение к каналу, выделение памяти. Цикл без единого вызова

for i := 0; i < 1e10; i++ {
    x = x*1664525 + 1013904223
}

не давал ни одной такой точки. При GOMAXPROCS=1 он вешал программу целиком — включая сборку мусора, которой нужно остановить все горутины, а эту остановить было нечем.

С Go 1.14 горутины вытесняются асинхронно, сигналом:

Проверено запуском: при GOMAXPROCS=1 соседняя горутина получила процессор, пока счётный цикл работал, — true в прогоне bench/gosched/internals.go.

Почему это стоит знать, а не просто помнить дату. Потому что след того времени остался в чужом коде: runtime.Gosched(), расставленный по циклам «чтобы не подвесить планировщик». Сегодня он там не нужен: планировщик снимет горутину и без него.

И это же место — образец того, как в теме устроены границы утверждений. Ответ «планировщик кооперативный» был верным и перестал им быть в конкретной версии: поведение планировщика — часть реализации, а не контракт языка. Поэтому любое утверждение про него называется вместе с версией, на которой оно проверено.

Механизм 5: GOMAXPROCS ограничивает одновременных, а не существующих

Это самая частая ошибка в ответах, и она проверяется замером.

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

Числа под картинкой — из прогона той же счётной задачи:

При одном P вчетверо большая работа занимает вчетверо больше времени: горутины считают по очереди. При двух — примерно вдвое. Горутин всё это время четыре.

Что стоит знать про значение по умолчанию. Оно равно числу доступных ядер. В контейнере с лимитом CPU это часто оказывается числом ядер хоста, а не лимитом контейнера, — и тогда рантайм создаёт заметно больше P, чем позволено считать. Лечится либо явным GOMAXPROCS, либо библиотекой, читающей лимиты cgroup.

И здесь стоит назвать границу, потому что её отсутствие и порождает сюрприз при переезде. Сколько потоков реально исполняют код Go — свойство версии рантайма и окружения, а не строчки в коде: документация прямо оговаривает, что this call will go away when the scheduler improves (этот вызов исчезнет, когда планировщик будет улучшен). Правило поэтому пишется от границы: число одновременно исполняющих потоков выясняют у запущенного процесса на той версии Go, на которой он работает, а не выводят из числа ядер машины.

Глубже: дорожает не операция, а парковка

Здесь два замера, и вместе они дают правило.

Первый — запуск горутины. Одна и та же работа, один атомарный инкремент:

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

Второй — уступка процессора. Та же работа, но горутина отдаёт процессор:

Третья строка тут важнее второй: time.Sleep(0) почти бесплатен, потому что возвращается сразу и не паркует горутину. То есть дорожает не «обращение к планировщику», а именно снятие с процессора и последующее возвращение.

Отсюда и цена того самого runtime.Gosched(), расставленного по циклам в старом коде: каждый такой вызов — около ста наносекунд, потраченных ни на что, потому что с Go 1.14 планировщик снимет горутину и без просьбы.

Отсюда правило, которое переносится на каналы, мьютексы и WaitGroup: пока горутина не блокируется, планировщик в её цене не участвует вовсе. Мьютекс без конкуренции — это атомарная операция; канал с готовым получателем — копирование. Дорожает ожидание, а не сама операция.

И граница у обоих замеров одна: они сняты на одной машине, двух ядрах и одной версии Go. Переносить отсюда нужно причину — что дорожает снятие с процессора и возвращение на него, — а не «в 82 раза» и не «106 нс»: у вас будут свои числа, а вывод останется тем же.

Как отвечать на собеседовании

Короткий ответ: горутина — не поток операционной системы, а единица работы самой программы на Go. Её запускает одно слово go, стоит она килобайты против мегабайтов у потока, а какая из них сейчас на процессоре — решает планировщик внутри процесса. Поэтому горутин бывают тысячи при единицах потоков, и поэтому GOMAXPROCS ограничивает не число горутин, а число выполняющихся одновременно.

Этого достаточно, чтобы ответить верно. Дальше — то, что добавляют, если собеседник копает.

Если интервьюер копает глубже

На «чем отличается от потока» отвечайте числом. «Структура рантайма со своим стеком: два килобайта стека плюс сотни байт структур против мегабайтов у потока ОС; переключение внутри процесса, а не через ядро».

Про GMP объясняйте P как право. «P — право выполнять код Go, их ровно GOMAXPROCS; поток без P код Go не выполняет. Отсюда и то, что потоков может быть больше, чем P: ушедший в системный вызов отдаёт своё P другому».

Про GOMAXPROCS скажите «одновременно». «Ограничивает не число горутин, а число выполняющихся одновременно; у меня четыре горутины при GOMAXPROCS=1 считали вчетверо дольше одной». Ответ «сколько горутин можно создать» — самый частый неверный.

Про вытеснение назовите дату и последствие. «Вытесняющий с 1.14, до этого кооперативный; цикл без вызовов раньше вешал сборку мусора».

Про цену дайте оба числа и разделите их. «Запуск с ожиданием — сотни наносекунд, но это на фоне работы в шесть; дорожает парковка, а не операция: Gosched добавляет сто наносекунд, а Sleep(0) — почти ничего».

Дальше спросят

Частые заблуждения

Практика

Две задачи. Сначала ответьте, потом сверьтесь с настоящим выводом: в обеих правильный ответ взят из прогона скрипта, а не назначен.

fmt.Println(runtime.NumGoroutine())

before := runtime.NumGoroutine()
go func() {
defer wg.Done()
}()
fmt.Println(runtime.NumGoroutine() - before)

fmt.Println((m2.StackInuse - m1.StackInuse) / n / 100 * 100)
fmt.Println((m2.HeapAlloc - m1.HeapAlloc) / n / 100 * 100)

1
1
2000
500

0
1
8000
2000

1
1
500
2000

2
1
2000
0

Проверка знаний