Планировщик Go: все что нужно знать на собесе (ч.2) Первую часть читать тут В прошлый раз разобрали GMP, очереди, work stealing, syscalls. Сегодня самое мясо: вытеснение и GOMAXPROCS в 2026 Кооперативный vs вытесняющий планировщик ОС вытесняет потоки когда хочет, ей похуй на твои желания. Go рантайм исторически был ближе к кооперативности: горутина сама уступала управление в "безопасных точках" До Go 1.14 переключение происходило когда горутина: → Блокировалась (канал, мьютекс, таймер, I/O) → Делала явный yield через runtime.Gosched() → Попадала в safe point на входе в функцию И вот тут была ЖИРНАЯ проблема: tight loop без вызовов функций мог держать P бесконечно, голодая все остальные горутины и даже мешая сборщику мусора. Представь: одна горутина крутится в цикле и весь планировщик стоит колом Красота, правда? xD Когда я работал в МТС Облако и писал балансировщик, я по рофлу запускал эксперимент на Go 1.13 с горутинами, которые крутились в циклах обработки пакетов. На Go 1.13 латенси скакало как бешеное. Обновились на 1.14+ и стало сильно лучше Что изменилось в Go 1.14 "Goroutines are now asynchronously preemptible" Переводим на человеческий: горутины теперь можно вытеснить принудительно. Tight loops без вызовов больше не дедлочат планировщик и не задерживают GC Как это работает: есть рантайм-тред sysmon, который мониторит горутины выполняющиеся дольше ~10ms. Он кидает сигнал SIGURG, обработчик модифицирует стек и переводит выполнение в preemption-хендлер. По сути рантайм говорит горутине "все, хватит, дай другим поработать" Побочка (часто прилетает как follow-up на собесе): из-за асинхронного вытеснения программам может прилетать больше сигналов, и "медленные" syscalls чаще возвращают EINTR. Если не ретраишь - получаешь баги на ровном месте GOMAXPROCS в 2026 GOMAXPROCS управляет количеством P, а значит максимальным числом потоков одновременно выполняющих Go-код НО ВНИМАНИЕ. Вот, что большинство не знает и на чем горят на собесах Начиная с Go 1.25 рантайм на Linux учитывает cgroup CPU bandwidth limit. Это значит что в Kubernetes GOMAXPROCS по дефолту ставится на минимум между NumCPU и CPU limit контейнера. Плюс рантайм может обновлять значение на лету если лимиты меняются Раньше для этого все тащили uber-go/automaxprocs. Теперь это из коробки. НАКОНЕЦ-ТО блять, сколько лет ждали Важная деталь: автоповедение отключается если вы явно задали GOMAXPROCS через env или вызвали runtime.GOMAXPROCS в коде. Имейте в виду В комментах оставил пару примеров вопрос-ответ