Внутреннее устройство Golang: от структур данных до рантайма

Внутренняя реализация базовых структур данных: слайсы, карты и интерфейсы

Добро пожаловать в курс «Внутреннее устройство Golang». Мы начинаем погружение в недра языка с фундамента, на котором строится практически любая Go-программа. Многие разработчики используют слайсы и карты ежедневно, не задумываясь о том, как они устроены. Однако понимание их внутренней механики — это ключ к написанию производительного кода и избеганию коварных ошибок, связанных с утечками памяти и лишними аллокациями.

В этой статье мы разберем анатомию трех китов Go: слайсов (slices), карт (maps) и интерфейсов (interfaces).

Слайсы: иллюзия динамического массива

В Go массивы имеют фиксированную длину, что делает их неудобными для многих задач. Слайс (slice) решает эту проблему, предоставляя гибкий интерфейс. Но важно помнить: слайс — это не массив, а заголовок, описывающий часть массива.

Структура слайса

В исходном коде рантайма Go (файл src/runtime/slice.go) слайс представлен простой структурой из трех полей. Упрощенно её можно представить так:

type slice struct {
    array unsafe.Pointer // Указатель на начало данных в базовом массиве
    len   int            // Текущая длина (количество элементов)
    cap   int            // Емкость (сколько памяти выделено всего)
}

Когда вы передаете слайс в функцию, вы копируете именно эту легкую структуру (24 байта на 64-битной архитектуре), а не сами данные. Это делает передачу слайсов очень дешевой операцией.

Механика роста: append

Магия динамического размера происходит в функции append. Если в базовом массиве есть место (то есть len < cap), append просто записывает значение и увеличивает len. Но что происходит, когда место заканчивается?

1. Аллокация: Go выделяет новый, более крупный массив.
2. Копирование: Данные из старого массива копируются в новый.
3. Переключение: Указатель в структуре слайса меняется на новый массив.

Алгоритм роста емкости не линеен. Раньше правило было простым: удваиваем размер, пока он меньше 1024 элементов, затем растем на 25%. В современных версиях Go формула стала сложнее, чтобы обеспечить более плавный переход.

Математически коэффициент роста $K$ можно приближенно описать так для больших массивов:

$$K \approx 1.25$$

Где $K$ — это коэффициент, на который умножается текущая емкость при расширении для больших слайсов (приближенное значение, так как реальная формула учитывает классы размеров памяти аллокатора). Для малых слайсов $K = 2$.

Опасность утечек памяти

Поскольку слайс содержит указатель на базовый массив, сборщик мусора (Garbage Collector) не может удалить этот массив, пока на него ссылается хотя бы один слайс.

Если вы загрузили в память файл на 10 МБ в слайс, а затем сделали срез (slicing) размером в 10 байт и сохранили его глобально, все 10 МБ останутся в памяти.

Решение: для долгоживущих небольших срезов больших данных используйте copy в новый, чистый слайс.

Карты: анатомия хэш-таблицы

Карта в Go (map) — это неупорядоченная коллекция пар «ключ-значение», реализованная как хэш-таблица. Это одна из самых сложных структур в рантайме Go.

Структура hmap

Основа карты — структура hmap (header map). Ключевые поля включают:

• count: количество живых элементов.
• B: логарифм количества бакетов (buckets). То есть количество бакетов равно $2^B$.
• buckets: указатель на массив бакетов.

Бакеты (Buckets)

Данные хранятся в бакетах. Каждый бакет вмещает ровно 8 пар «ключ-значение».

Обратите внимание на визуализацию: ключи и значения лежат не вперемешку (k1, v1, k2, v2), а раздельно (k1, k2... v1, v2...). Это сделано для выравнивания памяти (padding). Если key требует 8 байт, а value — 1 байт, чередование привело бы к огромным потерям памяти на пустые отступы.

Поиск и переполнение

Когда вы делаете m[key], происходит следующее:

1. Вычисляется хэш ключа.
2. Младшие биты хэша определяют индекс бакета.
3. Старшие 8 бит (tophash) используются для быстрого сравнения внутри бакета.

Если бакет переполнен (в нем уже 8 элементов), создается overflow bucket (бакет переполнения), который связывается с основным через указатель. Это метод разрешения коллизий, называемый chaining (цепочки).

Эвакуация данных

Когда карта заполняется слишком сильно, начинается процесс роста. Критерий роста — это фактор загрузки (Load Factor).

$$L = \frac{N}{2^B}$$

Где $L$ — фактор загрузки, $N$ — общее количество элементов в карте, а $2^B$ — текущее количество бакетов. В Go эвакуация начинается, когда $L > 6.5$.

При росте выделяется новый массив бакетов в 2 раза большего размера. Важно: перенос данных происходит не мгновенно, а инкементально (постепенно) при операциях вставки или удаления, чтобы не блокировать выполнение программы надолго.

Интерфейсы: цена абстракции

Интерфейсы в Go обеспечивают полиморфизм. Но как программа понимает, какой метод вызывать, если конкретный тип неизвестен на этапе компиляции?

В рантайме интерфейс — это тоже структура. Существует два вида интерфейсов:

1. eface (interface{}) — пустой интерфейс.
2. iface — интерфейс с методами.

Пустой интерфейс (eface)

type eface struct {
    _type *_type         // Информация о конкретном типе данных
    data  unsafe.Pointer // Указатель на сами данные
}

Когда вы присваиваете значение int в interface{}, Go создает копию этого числа в куче (или использует оптимизации для малых чисел) и сохраняет указатель на него в поле data.

Интерфейс с методами (iface)

Здесь все интереснее. Структура выглядит так:

type iface struct {
    tab  *itab           // Таблица интерфейса
    data unsafe.Pointer  // Указатель на данные
}

Поле tab (указатель на itab) содержит:

• Указатель на тип данных.
• Список указателей на конкретные функции (методы), которые реализуют интерфейс для этого типа.

Динамическая диспетчеризация

Вызов метода через интерфейс i.Method() работает медленнее, чем прямой вызов, потому что требует разыменования указателя tab, поиска функции в таблице и перехода по адресу. Это называется динамической диспетчеризацией.

Хотя современные процессоры хорошо предсказывают переходы, вызов через интерфейс все же несет накладные расходы. Кроме того, использование интерфейсов часто приводит к тому, что переменные «убегают» в кучу (heap escape), что нагружает сборщик мусора.

Заключение

Мы рассмотрели, как устроены базовые структуры данных:

• Слайс — это легкий заголовок над массивом. Осторожнее с append и ссылками на большие массивы.
• Карта — это сложная система бакетов с инкрементальной эвакуацией данных.
• Интерфейс — это пара «тип + данные» (или «таблица методов + данные»), обеспечивающая полиморфизм ценой небольшой потери производительности.

В следующей статье мы поднимемся на уровень выше и разберем, как Go управляет конкурентностью: нас ждут горутины и планировщик.

Управление памятью: аллокация, стеки горутин и escape-анализ

В предыдущей статье мы разобрали анатомию слайсов, карт и интерфейсов. Мы узнали, что слайс — это всего лишь заголовок, указывающий на массив, а карта — сложная структура из бакетов. Но где физически располагаются эти байты? Почему создание переменной иногда почти бесплатно, а иногда вызывает нагрузку на систему?

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

Аллокатор памяти: наследие TCMalloc

Управление памятью в Go вдохновлено аллокатором TCMalloc (Thread-Caching Malloc) от Google. Главная цель этой архитектуры — минимизировать блокировки (locks) при выделении памяти в многопоточной среде.

Память в Go делится на два мира: Стек (Stack) и Куча (Heap).

• Стек — это оперативная память, привязанная к конкретной горутине. Выделение и очистка здесь происходят тривиально быстро (просто сдвигом указателя).
• Куча — это общая память для всех горутин. Здесь живут данные, которые должны пережить вызов функции. Управление кучей — сложный процесс, требующий участия сборщика мусора (GC).

Иерархия аллокатора

Чтобы выделять память в куче быстро, Go использует многоуровневую систему кэширования. Давайте представим это как систему складов.

1. mcache (Локальный кэш): У каждого логического процессора (P), на котором исполняются горутины, есть свой собственный кэш памяти — mcache. Самое важное здесь — отсутствие блокировок. Поскольку mcache принадлежит одному P, горутина может взять оттуда память мгновенно, не конкурируя с другими потоками.
2. mcentral (Центральный список): Если в mcache закончились свободные блоки определенного размера, процессор обращается к mcentral. Это общий ресурс, поэтому здесь используются блокировки (mutex), но они гранулированы.
3. mheap (Глобальная куча): Если и mcentral пуст, рантаим запрашивает большие куски памяти (арены) у операционной системы через mheap.

Классы размеров (Size Classes)

Аллокатор Go не выделяет произвольное количество байт (например, 17 или 43). Вместо этого он использует классы размеров. Память разбивается на блоки фиксированного размера: 8 байт, 16 байт, 32 байта и так далее.

Если вам нужно 17 байт, аллокатор выдаст блок на 32 байта. Потерянные 15 байт называются внутренней фрагментацией, но это плата за скорость работы аллокатора.

Стеки горутин: от 2 КБ до бесконечности

В языках вроде C или Java потоки операционной системы обычно имеют фиксированный размер стека (например, 1 МБ или 8 МБ). Это создает проблему: если вы запустите 100 000 потоков, вы исчерпаете всю оперативную память только на стеки, даже если они пустые.

Go решает эту проблему элегантно. Горутины рождаются маленькими.

Динамический стек

Каждая новая горутина начинает жизнь со стеком размером всего 2 КБ (в актуальных версиях Go). Это позволяет запускать сотни тысяч горутин на стандартном сервере.

Но что происходит, когда 2 КБ не хватает? Здесь вступает в игру механизм непрерывных стеков (contiguous stacks).

Как растет стек

В начале каждой функции компилятор вставляет небольшую проверку (preamble). Она проверяет, достаточно ли места в стеке для выполнения функции.

Если места мало, происходит следующее:

1. Выделяется новый блок памяти, в 2 раза больше текущего.
2. Все содержимое старого стека копируется в новый.
3. Указатели внутри стека корректируются, чтобы указывать на новые адреса (это самая сложная часть, так как рантаим должен знать, где лежат указатели).
4. Старый стек освобождается.

Математически новый размер стека $S_{new}$ вычисляется так:

$$S_{new} = S_{old} \cdot 2$$

Где $S_{new}$ — размер нового стека, $S_{old}$ — размер текущего стека, а $2$ — коэффициент роста. Этот экспоненциальный рост гарантирует, что операции расширения стека будут происходить редко (амортизированная сложность).

Историческая справка: Раньше Go использовал сегментированные стеки (segmented stacks), где новый блок просто прилинковывался к старому. Это вызывало проблему "hot split", когда цикл постоянно вызывал функцию, требующую выделения нового сегмента, и сразу возвращался, освобождая его. Непрерывные стеки решили эту проблему.

Escape Analysis: Побег в кучу

Один из самых частых вопросов на собеседованиях: «Где будет выделена эта переменная?». Ответ «в куче, потому что я использовал new» — неверен. В Go местоположение данных определяет не синтаксис, а Escape Analysis (анализ побега).

Escape Analysis — это фаза компиляции, которая решает: может ли переменная безопасно остаться на стеке, или она должна «сбежать» в кучу.

Почему это важно?

• Стек: Дешево. Удаляется автоматически при возврате из функции. Не нагружает GC.
• Куча: Дорого. Требует поиска свободного места. Требует работы GC для очистки.

Ваша цель как разработчика высоконагруженных систем — минимизировать аллокации в куче (heap allocations).

Основные правила побега

Переменная «сбегает» в кучу, если компилятор не может доказать, что она не используется после возврата из функции. Рассмотрим классические случаи.

1. Возврат указателя на локальную переменную

func NewUser() *User {
    u := User{Name: "Alice"}
    return &u // u сбегает в кучу
}

В C++ этот код привел бы к катастрофе (dangling pointer), так как стек функции NewUser был бы уничтожен. В Go компилятор видит это и переносит u в кучу.

2. Интерфейсы

func Print(v interface{}) {
    fmt.Println(v) // v часто сбегает в кучу
}

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

3. Слишком большие переменные

Если вы создадите огромный массив внутри функции, он может не поместиться в стек и улетит в кучу.

func process() {
    var data [10000000]int // Скорее всего сбежит в кучу
    _ = data
}

Как увидеть побег?

Используйте флаг компилятора -gcflags="-m":

go build -gcflags="-m" main.go

Вывод покажет вам, какие переменные сбегают (escapes to heap) и почему.

Заключение

Понимание управления памятью дает вам суперсилу оптимизации.

1. Аллокатор Go оптимизирован под многопоточность: mcache позволяет выделять память без блокировок.
2. Стеки горутин динамические: они начинаются с 2 КБ и растут копированием.
3. Escape Analysis определяет судьбу переменной. Чем больше данных остается на стеке, тем меньше работы у сборщика мусора и тем быстрее работает ваша программа.

В следующей статье мы разберем Планировщик Go (Scheduler): узнаем, как рантаим жонглирует тысячами горутин на нескольких ядрах процессора, и что такое концепция M:N.

Алгоритм и фазы работы сборщика мусора в Go

В предыдущей статье мы подробно разобрали, как Go выделяет память. Мы узнали про иерархию mcache, mcentral и mheap, а также про то, как работает Escape Analysis, отправляя данные в кучу (heap). Но выделение памяти — это только половина дела. Если память только забирать и не возвращать, приложение очень быстро исчерпает ресурсы сервера и упадет с ошибкой OOM (Out Of Memory).

За возвращение памяти в Go отвечает Garbage Collector (GC) — сборщик мусора. В отличие от языков вроде C или C++, где программист обязан вручную удалять объекты (free, delete), Go делает это автоматически. Однако за эту магию приходится платить ресурсами процессора.

В этой статье мы разберем, как именно GC понимает, что объект больше не нужен, почему Go использует трехцветный алгоритм и что такое Stop-The-World.

Проблема живых и мертвых

Главная задача сборщика мусора — определить, какие объекты в куче являются «живыми» (live), а какие — «мусором» (garbage).

• Живой объект — это объект, до которого можно добраться по цепочке указателей, начиная от корневых структур (Roots).
• Корни (Roots) — это глобальные переменные и, что самое важное, стеки всех активных горутин. Если на объект есть ссылка в стеке функции, которая сейчас выполняется, этот объект удалять нельзя.

Если до объекта невозможно добраться от корней, он считается мусором, и занимаемую им память можно вернуть системе.

Трехцветный алгоритм (Tricolor Mark-and-Sweep)

Go использует неуплотняющий (non-compacting) сборщик мусора, работающий параллельно с основной программой. В его основе лежит алгоритм Tricolor Mark-and-Sweep (Трехцветная маркировка и очистка).

Суть алгоритма заключается в том, что все объекты в памяти условно окрашиваются в три цвета:

1. Белый (White): Потенциальный мусор. В начале цикла сборки все объекты считаются белыми. Если к концу сборки объект остался белым, он будет удален.
2. Серый (Grey): Живой объект, до которого сборщик добрался, но еще не проверил, на что ссылается этот объект (не просканировал его поля-указатели).
3. Черный (Black): Гарантированно живой объект, который был полностью просканирован. Сборщик мусора закончил с ним работу.

Логика работы

1. В начале все объекты белые.
2. Сборщик сканирует корни (стеки и глобальные переменные) и помечает все объекты, на которые они ссылаются, как серые.
3. Сборщик берет серый объект, красит его в черный, а все объекты, на которые он ссылается, красит в серый.
4. Этот процесс повторяется, пока очередь серых объектов не опустеет.
5. В итоге остаются только черные (живые) и белые (мусор) объекты. Белые удаляются.

Фазы работы сборщика мусора

Сборщик мусора в Go стремится минимизировать задержки (latency). Для этого большая часть работы выполняется конкурентно (concurrently), то есть параллельно с выполнением вашего кода. Однако полностью избежать пауз невозможно.

Цикл сборки мусора (GC Cycle) состоит из четырех основных фаз:

1. Sweep Termination (Завершение очистки)

• Состояние: Stop-The-World (STW).

Перед началом новой сборки нужно убедиться, что предыдущая очистка завершена. Все процессоры (P) останавливаются. Это очень короткая пауза. В этот момент также включаются специальные механизмы для следующей фазы.

2. Mark (Маркировка)

• Состояние: Concurrent (Конкурентно).

Это самая длительная фаза, занимающая около 80-90% времени цикла GC. Сборщик запускает специальные фоновые воркеры (Mark Workers), которые сканируют кучу и красят объекты (превращают белые в серые, серые в черные).

Важно: ваша программа продолжает работать. Горутины выделяют новую память и меняют указатели.

3. Mark Termination (Завершение маркировки)

• Состояние: Stop-The-World (STW).

Чтобы завершить маркировку, нужно гарантировать, что не осталось ни одного необработанного серого объекта. Для этого выполнение программы снова приостанавливается. Сборщик доделывает финальную работу, очищает кэши и подготавливается к фазе очистки.

4. Sweep (Очистка)

• Состояние: Concurrent (Конкурентно).

Теперь мы знаем, где мусор (белые объекты). Фаза очистки происходит в фоновом режиме. Память не «обнуляется» физически сразу же; вместо этого блоки памяти помечаются как свободные в структурах mspan, чтобы их можно было использовать для новых аллокаций.

Write Barrier: Защита от хаоса

Поскольку фаза маркировки (Mark) идет параллельно с работой программы, возникает проблема. Представьте ситуацию:

1. Сборщик покрасил объект A в черный (просканировал его).
2. Ваша программа (Mutator) берет указатель на белый объект B и записывает его внутрь объекта A.
3. Сборщик удаляет ссылку на B из того места, где он ее видел раньше.

Результат: Черный объект A ссылается на белый объект B. Но сборщик уже закончил с A и больше к нему не вернется! В конце цикла B будет удален, хотя он нужен. Это приведет к краху программы.

Чтобы этого не случилось, Go использует механизм Write Barrier (Барьер записи). Это небольшой кусочек кода, который компилятор вставляет при каждой операции записи указателя в кучу.

Принцип Hybrid Write Barrier: Если вы пытаетесь изменить указатель или создать ссылку на белый объект во время работы GC, барьер автоматически красит этот объект в серый цвет. Это гарантирует соблюдение инварианта: черный объект никогда не может ссылаться на белый.

Когда запускается GC? (GC Pacer)

Сборщик мусора не работает постоянно. Он запускается, когда размер кучи достигает определенного предела. Этот предел динамический и зависит от переменной окружения GOGC.

Формула расчета целевого размера кучи для следующего запуска:

$$\text{Goal} = \text{Live} + \left( \text{Live} \cdot \frac{\text{GOGC}}{100} \right)$$

Где:

• $\text{Goal}$ — размер кучи, при достижении которого запустится GC.
• $\text{Live}$ — размер «живых» данных, оставшихся после предыдущего цикла GC.
• $\text{GOGC}$ — процент прироста (по умолчанию 100).

Пример: Если после сборки мусора у вас осталось 10 МБ живых данных, а GOGC=100 (значение по умолчанию), то следующая сборка начнется, когда куча вырастет до:

$$10 + (10 \cdot \frac{100}{100}) = 20 \text{ МБ}$$

Если вы установите GOGC=200, сборщик будет запускаться реже (при 30 МБ), потребляя больше памяти, но экономя процессорное время.

GOMEMLIMIT

В Go 1.19 появился параметр GOMEMLIMIT. Он устанавливает жесткий лимит памяти. Если потребление приближается к этому лимиту, GC начинает работать агрессивнее, игнорируя GOGC, чтобы предотвратить OOM (Out Of Memory).

Заключение

Сборщик мусора в Go — это сложный инженерный компромисс между пропускной способностью (throughput) и задержками (latency).

1. Алгоритм: Трехцветная маркировка (Tricolor Mark-and-Sweep).
2. Конкурентность: Маркировка и очистка работают параллельно с кодом, но есть две короткие паузы Stop-The-World.
3. Безопасность: Write Barrier защищает данные от случайного удаления во время конкурентной маркировки.
4. Настройка: GOGC управляет балансом «CPU vs RAM».

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

Планировщик Go: модель GMP, переключение контекста и системный мониторинг

В предыдущих статьях мы проделали большой путь. Мы изучили, как данные хранятся в памяти (слайсы и карты), как эта память выделяется (аллокатор) и как она очищается (сборщик мусора). Теперь у нас есть данные и свободная память, но программа — это не просто хранилище байтов. Это действия.

Кто решает, какая функция будет выполняться прямо сейчас? Как Go умудряется держать в воздухе сотни тысяч горутин, используя всего несколько ядер процессора? Почему go func() — это не создание системного потока?

В этой статье мы разберем сердце рантайма Go — Планировщик (Scheduler).

Проблема: Потоки ОС слишком тяжелые

Чтобы понять гениальность планировщика Go, нужно вспомнить, как работают классические потоки операционной системы (OS Threads).

Когда вы создаете поток в Java или C++, операционная система выделяет под него значительные ресурсы:

1. Память стека: Обычно 1–2 МБ (даже если поток ничего не делает).
2. Системные вызовы: Создание и уничтожение потока требует обращения к ядру ОС.
3. Переключение контекста (Context Switch): Чтобы переключиться с одного потока на другой, процессор должен сохранить все регистры, сбросить кэши и загрузить состояние нового потока. Это занимает от 1 до 2 микросекунд.

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

Математика масштабируемости

Давайте посчитаем теоретический предел количества потоков $N$, которые можно запустить на сервере с 8 ГБ оперативной памяти, если один поток занимает 1 МБ.

$$N = \frac{M_{total}}{S_{thread}} = \frac{8192 \text{ MB}}{1 \text{ MB}} \approx 8192$$

Где:

• $N$ — максимальное количество потоков.
• $M_{total}$ — общий объем доступной памяти (8192 МБ).
• $S_{thread}$ — размер стека одного потока (1 МБ).

Всего 8 тысяч потоков исчерпают память. Для современного высоконагруженного сервера (C10K problem) этого недостаточно. Go решает эту задачу, внедряя концепцию горутин, которые на старте занимают всего 2 КБ. Используя ту же формулу, мы получим миллионы горутин на том же железе.

Модель M:N

Go использует модель многопоточности, называемую M:N.

Это означает, что M горутин (пользовательских задач) мультиплексируются на N потоков операционной системы. Рантаим Go выступает посредником, скрывая от нас сложность управления реальными потоками.

Анатомия планировщика: GMP

Планировщик Go построен вокруг трех сущностей, аббревиатура которых и дала название модели: G, M и P.

1. G (Goroutine)

Это сама горутина. Структура g содержит:

• Стек (stack pointer).
• Указатель команд (instruction pointer) — где мы остановились.
• Статус (ожидает, выполняется, системный вызов).

G не может выполняться сама по себе. Ей нужно место на процессоре.

2. M (Machine)

Это реальный поток операционной системы (OS Thread). Именно M выполняет инструкции на физическом ядре процессора (CPU).

Однако в Go поток M «глупый». Он не знает, какие горутины существуют и в каком порядке их выполнять. Он просто умеет «крутить» код, который ему дадут.

3. P (Processor)

Это ключевой элемент, которого нет в других языках. P — это логический процессор, ресурс, необходимый для выполнения Go-кода.

• Количество P по умолчанию равно количеству логических ядер вашего CPU (регулируется переменной GOMAXPROCS).
• P хранит Локальную очередь выполнения (Local Run Queue, LRQ).

Суть работы: Чтобы поток M мог выполнить горутину G, он должен захватить контекст P. Без P поток M либо спит, либо выполняет системный вызов, но не Go-код.

Очереди выполнения и Work Stealing

Как горутины попадают на исполнение? Существует два уровня очередей:

1. Local Run Queue (LRQ): У каждого P есть своя очередь. Когда вы пишете go func(), новая горутина попадает в LRQ того P, на котором сейчас выполняется родительская горутина. Это обеспечивает локальность данных (Data Locality) и минимизирует блокировки, так как к своей очереди P обращается без мьютексов.
2. Global Run Queue (GRQ): Общая очередь для всех. Сюда попадают горутины, если локальная очередь переполнена (вмещает 256 элементов), или горутины, разблокированные из сети.

Алгоритм поиска работы

Когда поток M (связанный с P) освобождается, он ищет новую работу в строгом порядке:

1. Проверить свою LRQ (локальную очередь).
2. Каждые 61 тик планировщика проверить GRQ (глобальную очередь), чтобы не допустить голодания глобальных задач.
3. Если локально пусто, попытаться украсть работу у других P.

Work Stealing (Кража работы)

Если один процессор завален работой, а другой простаивает, простаивающий P «ворует» половину горутин из очереди загруженного P.

Это делает планировщик Go невероятно эффективным в распределении нагрузки без централизованного «диспетчера», который стал бы узким местом.

Переключение контекста и вытеснение

Как планировщик забирает управление у горутины? Ведь если одна горутина запустит бесконечный цикл for {}, она может захватить процессор навечно?

Кооперативная многозадачность (до Go 1.14)

Раньше Go использовал кооперативную многозадачность. Переключение происходило только в определенных точках:

• Вызов runtime.Gosched().
• Операции ввода-вывода (сеть, файлы).
• Операции с каналами.
• Вызов функций (проверка переполнения стека).

Это означало, что плотный математический цикл for i:=0; i<1e10; i++ {} мог полностью заблокировать P и GC, приводя к зависанию приложения.

Асинхронное вытеснение (Asynchronous Preemption)

С версии Go 1.14 планировщик стал вытесняющим (preemptive). Теперь он использует сигналы операционной системы (SIGURG в Linux).

Если горутина выполняется дольше 10 мс, ей посылается сигнал. Обработчик сигнала прерывает выполнение, сохраняет текущее состояние (регистры) и передает управление планировщику. Это гарантирует, что даже самые жадные алгоритмы не подвесят систему.

Sysmon: Всевидящее око

В рантайме Go есть специальный поток, который работает вне модели GMP. Он не привязан ни к какому P. Его имя — sysmon (system monitor).

Sysmon просыпается каждые 20 мкc – 10 мс и выполняет критически важные задачи:

1. Netpoll: Проверяет готовность сетевых соединений. Если пакет пришел, sysmon возвращает ожидающую горутину в очередь выполнения.
2. Retake P: Если поток M заблокирован в системном вызове (syscall) слишком долго, sysmon «отбирает» у него P и отдает другому свободному потоку M. Это гарантирует, что другие горутины в очереди этого P не будут ждать завершения долгого чтения файла.
3. Force GC: Если сборщик мусора не запускался более 2 минут, sysmon запускает его принудительно.
4. Preemption: Именно sysmon замечает, что горутина работает слишком долго (>10 мс), и инициирует процесс её вытеснения.

Системные вызовы (Syscalls)

Что происходит, когда горутина делает синхронный системный вызов (например, чтение файла)?

1. Горутина делает syscall.
2. Поток M блокируется на уровне ОС (ждет ответа диска).
3. Связь между M и P разрывается.
4. P (вместе с очередью других горутин) передается новому или спящему потоку M.

Когда системный вызов завершается, старый M пытается вернуть себе P. Если не получается, он кладет горутину в глобальную очередь, а сам засыпает.

Заключение

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

• GMP модель позволяет эффективно использовать ядра процессора, избегая накладных расходов на переключение системных потоков.
• Локальные очереди и Work Stealing минимизируют блокировки и равномерно распределяют нагрузку.
• Sysmon и асинхронное вытеснение гарантируют отзывчивость системы даже при наличии тяжелых вычислений.

Теперь мы знаем, как Go хранит данные, управляет памятью и исполняет код. Но как горутины общаются между собой? В следующей части курса мы разберем каналы (channels) и примитивы синхронизации — инструменты, которые делают Go идеальным языком для конкурентного программирования.

Устройство каналов и примитивов синхронизации под капотом

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

Философия Go гласит: «Не общайтесь, используя общую память; используйте общую память, общаясь». Главный инструмент для этого — каналы. Однако под капотом каналов и мьютексов скрывается сложная инженерная магия, тесно связанная с планировщиком и управлением памятью.

В этой статье мы вскроем структуру hchan, узнаем, как данные телепортируются между стеками горутин, и разберем, как sync.Mutex избегает голодания потоков.

Каналы: больше, чем просто труба

Многие воспринимают канал как магическую трубу. На самом деле, канал — это указатель на структуру hchan, аллоцированную в куче. Когда вы передаете канал в функцию, вы копируете этот указатель, поэтому все функции работают с одной и той же очередью данных.

Структура hchan

В исходном коде рантайма (runtime/chan.go) структура канала выглядит примерно так:

type hchan struct {
    qcount   uint           // Количество элементов в буфере
    dataqsiz uint           // Размерность буфера (capacity)
    buf      unsafe.Pointer // Указатель на кольцевой буфер с данными
    elemsize uint16         // Размер одного элемента
    closed   uint32         // Флаг закрытия
    elemtype *_type         // Тип элементов
    sendx    uint           // Индекс для записи следующего элемента
    recvx    uint           // Индекс для чтения следующего элемента
    recvq    waitq          // Очередь заблокированных получателей (G)
    sendq    waitq          // Очередь заблокированных отправителей (G)
    lock     mutex          // Внутренний мьютекс для защиты полей
}

Обратите внимание на поле lock. Да, каналы используют мьютексы внутри себя. Это необходимо, так как канал — это разделяемый ресурс, доступ к которому могут иметь множество горутин одновременно.

Кольцевой буфер

Если канал буферизированный, данные хранятся в buf. Это кольцевой буфер (circular buffer). Рантаим не сдвигает все элементы массива при чтении (это было бы $O(n)$), а просто меняет индексы sendx и recvx.

Формула вычисления следующего индекса выглядит так:

$$next = (current + 1) \pmod{capacity}$$

Где $next$ — новый индекс, $current$ — текущий индекс (sendx или recvx), а $capacity$ — емкость буфера. Это позволяет использовать массив как бесконечную ленту, пока скорость чтения соответствует скорости записи.

Механика отправки и получения

Самое интересное происходит, когда буфер полон (при отправке) или пуст (при чтении). Здесь канал напрямую взаимодействует с планировщиком Go.

Сценарий 1: Блокировка (Gopark)

Представьте, что горутина G1 хочет записать данные в полный канал.

1. G1 захватывает lock канала.
2. Видит, что места нет.
3. Создает структуру sudog (обертка над горутиной), кладет её в очередь sendq канала.
4. Вызывает gopark.

В этот момент планировщик (P) переводит G1 в состояние Waiting, разрывает связь между G1 и потоком M, и берет следующую горутину из очереди выполнения. G1 больше не потребляет процессорное время. Она просто «висит» в списке внутри структуры канала.

Сценарий 2: Прямая передача (Direct Send)

Теперь приходит горутина G2 и хочет прочитать из этого канала. Она видит, что в sendq кто-то ждет.

Обычная логика подсказала бы такой путь: G2 забирает данные из буфера, а G1 просыпается и кладет свои данные в освободившееся место. Но Go делает умнее.

Go использует оптимизацию Direct Send. Рантаим копирует данные напрямую из стека спящей горутины G1 в стек читающей горутины G2.

Это единственный случай в Go, когда одна горутина имеет прямой доступ к стеку другой горутины.

Это дает огромный прирост производительности:

• Не нужно захватывать лишние блокировки.
• Меньше промахов кэша процессора (CPU Cache Misses).
• Данные копируются один раз (Stack -> Stack), а не два (Stack -> Buffer -> Stack).

После копирования G2 вызывает goready для G1, сообщая планировщику, что G1 снова можно выполнять.

Select: Случайный выбор

Конструкция select позволяет ожидать несколько операций одновременно. Как она работает?

1. Блокировка: select блокирует все каналы, участвующие в операции (сортируя их по адресу в памяти, чтобы избежать взаимных блокировок — Deadlock).
2. Проверка: Проверяет, есть ли готовые к выполнению каналы.
3. Случайность: Если готовых каналов несколько, Go использует псевдослучайный генератор (Jitter), чтобы выбрать один из них. Это гарантирует, что ни один канал не будет иметь приоритета и не возникнет голодания.
4. Ожидание: Если никто не готов, горутина добавляет себя в очереди ожидания (recvq/sendq) всех каналов в select и засыпает.

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

Sync.Mutex: Спиннинг и голодание

Теперь перейдем к примитивам синхронизации. sync.Mutex в Go — это не просто обертка над системным мьютексом (как pthread_mutex). Это гибридная реализация, оптимизированная под планировщик Go.

Структура мьютекса предельно компактна:

type Mutex struct {
    state int32
    sema  uint32
}

Поле state хранит информацию о том, заблокирован ли мьютекс, сколько горутин ждут и есть ли «проснувшиеся» горутины.

Режимы работы мьютекса

Мьютекс в Go имеет два режима работы, переключающихся динамически:

1. Normal Mode (Нормальный режим): Работает по принципу пропускной способности. Когда горутина освобождает мьютекс, она будит первую горутину из очереди. Однако проснувшаяся горутина должна соревноваться с новыми горутинами, которые только что пришли к методу Lock().

   У новых горутин преимущество: они уже выполняются на процессоре (CPU), им не нужно переключать контекст. Поэтому проснувшаяся горутина часто проигрывает и снова засыпает. Это несправедливо, но очень быстро.

2. Starvation Mode (Режим голодания): Если горутина не может захватить мьютекс более 1 мс, мьютекс переходит в режим голодания.

   В этом режиме мьютекс отдается строго той горутине, которая ждала дольше всех. Новые горутины даже не пытаются захватить мьютекс, а сразу встают в хвост очереди. Это медленнее, но гарантирует, что «хвостовые задержки» (tail latency) не будут бесконечными.

Активное ожидание (Spinning)

Перед тем как уснуть (вызвать дорогой системный вызов или переключение контекста), горутина некоторое время «крутится» в цикле (active spinning), проверяя флаг state.

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

Sync.Map: Специализированный инструмент

Стандартная map в Go не потокобезопасна. sync.RWMutex решает проблему, но при высокой конкуренции на чтение (много ядер читают одни и те же ключи) производительность падает из-за cache contention (конкуренции за кэш-линии процессора).

sync.Map решает эту проблему, используя две структуры внутри:

1. read (atomic): Доступ без блокировок. Если ключ есть здесь, мы получаем его мгновенно.
2. dirty (mutex): Доступ с блокировкой. Сюда пишутся новые ключи.

Когда происходит слишком много промахов в read карте (misses), dirty карта повышается до read, а dirty очищается. Это называется амортизацией затрат. sync.Map идеальна для случаев, когда запись происходит редко, а чтение — постоянно.

Заключение

Мы увидели, что:

1. Каналы — это сложные структуры с внутренними мьютексами и очередями. Они тесно интегрированы с планировщиком для реализации прямой передачи данных между стеками.
2. Select обеспечивает случайный выбор для предотвращения приоритезации одного канала.
3. Mutex в Go умный: он сочетает активное ожидание (spinning) и честные очереди (starvation mode), чтобы балансировать между производительностью и справедливостью.

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

На этом мы завершаем блок, посвященный внутреннему устройству рантайма Go. Теперь вы знаете, что происходит от момента создания переменной до переключения контекста горутины.