Модуль 22 ⏱ ~387 мин чтения 📐 2 Mermaid диаграмм

07. Runtime Go. Общая архитектура

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

Архитектура Runtime: ядро рантайма, GMP и аппаратная синергия

В отличие от языков с виртуальными машинами (Java JVM, CLR) или языков без рантайма (C, C++), Go использует уникальную модель: легковесный управляющий рантайм (~2–3 МБ) статически влинковывается непосредственно в каждый исполняемый бинарник. Он предоставляет микроядерную функциональность: кооперативно-вытесняющий планировщик горутин, сборщик мусора, асинхронный сетевой поллер (epoll/kqueue) и менеджер виртуальной памяти.

flowchart TD
    classDef comp   fill:#1e3a5f,stroke:#38bdf8,stroke-width:2px,color:#f8fafc
    classDef sched  fill:#1e1b4b,stroke:#818cf8,stroke-width:1px,color:#f8fafc
    classDef sys    fill:#312e81,stroke:#a78bfa,stroke-width:1px,color:#f8fafc
    classDef worker fill:#064e3b,stroke:#34d399,stroke-width:1px,color:#f8fafc

    App["Пользовательский код приложения"]:::comp

    subgraph GoRuntime["Go Runtime Core (src/runtime)"]
        GMP["Планировщик (GMP Engine):<br/>Распределение G по M через контексты P"]:::sched
        Mem["Управление памятью:<br/>TCMalloc, mcache, mcentral, Tri-color GC"]:::sched
        NetPoller["Сетевой поллер (Netpoller):<br/>epoll (Linux) / kqueue (macOS) / IOCP (Win)"]:::sched
        Sysmon["Фоновый демон (sysmon):<br/>Preemption, retake P, force GC"]:::worker
    end

    subgraph OSKernel["Ядро операционной системы (Linux Kernel)"]
        Threads["Потоки ядра (clone / pthread)"]:::sys
        Syscalls["Системные вызовы (read, write, futex)"]:::sys
    end

    App --> GoRuntime
    GMP --> Threads
    NetPoller --> Syscalls
    Mem --> Syscalls

flowchart LR
    classDef step fill:#1e293b,stroke:#38bdf8,stroke-width:1px,color:#f8fafc
    classDef init fill:#1e1b4b,stroke:#818cf8,stroke-width:2px,color:#f8fafc
    classDef main fill:#064e3b,stroke:#34d399,stroke-width:2px,color:#f8fafc

    Boot["_rt0_amd64_linux (Ассемблер)"]:::step --> InitOS["runtime.osinit (ядра CPU, страница памяти)"]:::step
    InitOS --> SchedInit["runtime.schedinit (создание m0, g0, аллокатора, P)"]:::init
    SchedInit --> NewProc["runtime.newproc (создание main goroutine)"]:::step
    NewProc --> Mstart["runtime.mstart (запуск диспетчера M0)"]:::step
    Mstart --> MainGoroutine["runtime.main (инициализация пакетов init())"]:::init
    MainGoroutine --> AppMain["main.main (точка входа пользователя)"]:::main

Ключевые модули исходного кода рантайма (`src/runtime/`)

Файл / Каталог	Назначение модуля	Ключевые структуры и функции
`proc.go`	Ядро планировщика задач	`runtime.schedule()`, `findrunnable()`, `newproc()`
`runtime2.go`	Определения базовых структур рантайма	`type g`, `type m`, `type p`, `type sudog`
`malloc.go`	Аллокатор памяти (TCMalloc архитектура)	`mallocgc()`, `newobject()`, размерные классы
`mgc.go` / `mgcmark.go`	Сборщик мусора (GC)	`gcStart()`, `gcDrain()`, `wbBuf` (write barrier)
`netpoll.go` / `netpoll_epoll.go`	Асинхронный ввод-вывод	`netpoll()`, `netpollopen()`, `netpollblock()`
`chan.go`	Реализация каналов	`type hchan`, `chansend()`, `chanrecv()`
`map.go` / `map_swiss.go`	Ассоциативные массивы	Хэш-таблицы, Swiss Tables, эвакуация бакетов
`sysmon.go`	Системный монитор (фоновый поток ОС)	`retake()`, вытеснение зависших горутин

Навигатор по вопросам главы

Что такое runtime Go?
Что входит в runtime?
Как runtime управляет памятью?
Как runtime управляет горутинами (goroutines)?
Что такое планировщик (scheduler)?
Что такое sysmon?
Как работает sysmon и зачем он нужен?
Что такое netpoller?
Как runtime взаимодействует с ОС?
Что такое системный вызов (syscall)?
Что такое CGO?
Почему CGO дорог?
Как происходит запуск программы на Go (bootstrap)?
Какие основные структуры данных использует runtime (g, m, p, schedt)?
Что такое "monitor thread"?
Как runtime обрабатывает прерывания и сигналы ОС?
Как работает time.Sleep?
Как работает runtime.LockOSThread и когда это нужно?
Что такое "runtime finalizer" и как он связан с GC?
Как работает recover и panic на уровне runtime?
Как устроен channel и его буфер в памяти (структура hchan)?
Как работает select на уровне runtime?
Что такое "work stealing" в планировщике?
Как происходит переключение контекста между горутинами?
Как устроены timers и ticker?
Как runtime обрабатывает блокирующие системные вызовы в горутине?
Как работает fork/exec в Go с учетом горутин?
Что такое "spinning thread" и зачем он нужен?
Что происходит с горутиной, когда она делает ioutil.ReadFile?
Как runtime собирает и выводит стектрейс при панике?
Чем отличается поведение рантайма на Linux, macOS и Windows?
Что такое GODEBUG и как его использовать для отладки?
Как работает runtime.GOMAXPROCS?
Как runtime.GC() влияет на выполнение программы?
Что такое "асинхронная вытесняющая многозадачность" (async preemption)?
Как работает runtime.Gosched()?
Что произойдет с горутиной, если она зациклится без системных вызовов?
Как работает runtime.NumGoroutine()?
Как работает runtime.SetBlockProfileRate?
Что такое "mutex profile" и как его получить?
Как Go runtime обрабатывает сигналы SIGSEGV?
Как работает pprof на уровне сэмплирования?
Какова роль ассемблера в исходном коде Go runtime?
Как go:linkname используется в рантайме и чем это опасно?
Что такое «закрепление горутины за потоком» и зачем это нужно для некоторых операций?
Как работает syscall.RawSyscall и в чем его отличие от syscall.Syscall?
Чем отличается runtime.KeepAlive() от простого использования переменной?
Как работает диспетчеризация сигналов в рантайме?
Как runtime.Caller() получает информацию о стеке вызовов?
Что такое «состояние гонки» в самом планировщике Go и как его избегают?

Что такое runtime Go?

Краткий ответ (30–60 секунд)

Runtime Go — это библиотека и набор сервисов, встраиваемых в каждый бинарный файл Go, обеспечивающих управление памятью (аллокатор, сборщик мусора), планирование горутин, отражение (reflection), поддержку каналов, таймеров, сетевого поллинга, обработку сигналов и взаимодействие с ОС. Он работает как слой между программой и ядром, заменяя традиционную операционную среду виртуальной машиной с зелёными нитями. Гарантирует, что горутины выполняются в рамках пула потоков ОС с минимальными блокировками и эффективным переключением контекста.

Развёрнутый ответ

В отличие от C/C++, где программа напрямую вызывает libc и системные вызовы, каждая Go-программа компилируется вместе с собственным рантаймом (около 2 МБ дополнительного кода), реализующим абстракции выше уровня ОС. Рантайм отвечает за:

Управление памятью: собственный аллокатор классов размеров, сборка мусора на основе барьеров и mark/stop.
Планирование горутин: мультиплексирование миллионов горутин на потоки ОС, work stealing, асинхронная преемптивная диспетчеризация.
Каналы, таймеры, сеть: кооперативная абстракция над epoll/kqueue/IOCP.
Паника/восстановление: обход стека с помощью отображения стековых фреймов.

Код рантайма написан в основном на Go (с небольшими ассемблерными вставками) и находится в пакете runtime. Компоновщик Go-программ всегда подключает runtime, даже для пустой main.

Под капотом (internals)

Рантайм загружается первым: при запуске исполняется rt0_<arch>.s, устанавливающий g0 (стек главной горутины), после чего runtime·rt0_go вызывает runtime.args, runtime.osinit, runtime.schedinit, создаёт главную горутину с runtime·newproc и запускает её на текущем m, а затем runtime·mstart. Ключевые структуры (g, m, p) размещаются в статической памяти или на куче. Сборщик мусора использует трёхцветный алгоритм с барьерами записи. Планировщик реализован в runtime/proc.go: findrunnable, schedule, stealWork. Преемпция поддерживается через сигналы SIGURG (с версии 1.14). Взаимодействие с ОС абстрагировано через внутренний пакет runtime/internal/syscall.

Типичные ошибки кандидатов

Считать, что рантайм Go — это просто среда исполнения, наподобие JVM.
Между JVM и Go-рантаймом огромная разница: Go компилирует нативный код, а не байт-код, рантайм вшивается в бинарник статически, его работа не требует отдельного процесса. Это скорее библиотека, чем виртуальная машина. Исправление: понимать, что Go-рантайм — это слой системного ПО внутри приложения, а не отдельная платформа.
Путать горутину и поток ОС, считая, что runtime просто запускает горутину на отдельном потоке.
Рантайм мультиплексирует горутины на пул потоков, количество которых регулируется GOMAXPROCS и активностью syscall’ов. Без понимания m и p трудно ответить на вопросы о блокировках и производительности. Исправление: изучить модель MPG (Machine, Processor, Goroutine).
Забывать, что накладные расходы на создание горутины (~4 КБ стека) обеспечиваются именно рантаймом.
Новички иногда считают, что горутины создаются «бесплатно». На деле 4 КБ выделяются и могут расти, этим управляет аллокатор и механизм копирования стека. Исправление: помнить, что создание многих горутин потребляет память и может косвенно нагружать GC.

Возможные дополнительные вопросы интервьюера

Какой минимальный размер стека горутины в последних версиях Go и как он растёт?
Минимальный стек — 2 КБ (с Go 1.22, ранее 8 КБ и 4 КБ). При переполнении рантайм копирует стек на увеличенный в 2–4 раза, используя escape-анализ, чтобы не перемещать указатели.
Что произойдёт, если программа на Go скомпилирована с buildmode=c-shared, кто инициализирует рантайм?
Экспортируется функция main.init, которая при загрузке библиотеки вызывает runtime·rt0_go. Внешний код может инициализировать рантайм только один раз.
Можно ли написать программу на Go без рантайма?
Теоретически с помощью -gcflags=-N -l и //go:noescape можно минимально обходить аллокатор, но полностью исключить рантайм нельзя, так как он вшит и управляет стеком, сигналами и запуском main.

Что входит в runtime?

Краткий ответ (30–60 секунд)

В пакет runtime входят: планировщик горутин (GMP-модель), сборщик мусора, аллокатор памяти, обработка сигналов, netpoller, таймеры, поддержка каналов и оператора select, механизм panic/recover, стековые фреймы и вызов функций, интерфейс взаимодействия с ОС (syscalls), профилирование (pprof), race detector и отладочные средства (GODEBUG, трассировка). Также сюда относят ассемблерные файлы для специфичных платформ и внутренние вспомогательные пакеты (runtime/internal/atomic, runtime/internal/sys, runtime/internal/math).

Развёрнутый ответ

Весь код рантайма сосредоточен в каталоге $GOROOT/src/runtime/. Ключевые файлы:

runtime/proc.go — планировщик (schedule, newproc, work stealing, sysmon).
runtime/mgc.go, runtime/mgcmark.go, runtime/mgcsweep.go — сборка мусора.
runtime/malloc.go, runtime/mheap.go, runtime/mcache.go — аллокатор.
runtime/chan.go — каналы, select.
runtime/sigqueue.go, runtime/os_linux.go — сигналы.
runtime/netpoll.go, runtime/netpoll_epoll.go — сетевой поллинг.
runtime/time.go, runtime/timers.go — таймеры.
runtime/panic.go, runtime/defer.go — panic/recover/defer.
runtime/stack.go — стеки горутин.
runtime/symtab.go — таблицы символов для стека и pprof.
runtime/race/race.go — детектор гонок данных.
runtime/internal/ — низкоуровневые атомарные операции, макросы, математика.

Также рантайм включает ассемблерные файлы для каждой платформы (runtime/rt0_linux_amd64.s, runtime/asm_amd64.s), реализующие самые нижние точки входа, переключения контекста горутин (gogo, gocall) и взаимодействие со стеком.

Под капотом (internals)

Все функции в runtime имеют специальную обработку компилятором: он вставляет вызовы runtime.morestack при нехватке места на стеке, обрабатывает барьеры GC для указателей, генерирует таблицу для defer и recover. Структура m0 и g0 статически размещены в секции данных программы. Многие API рантайма «монолитны»: newproc получает указатель на функцию и аргументы, создаёт g с начальным стеком. Пакет runtime использует внутреннюю компоновку (внутренние экспорты через go:linkname), чтобы не экспортировать лишнее в публичный API.

Типичные ошибки кандидатов

Полагать, что рантайм — это только планировщик + GC.
Опускание поддержки каналов, netpoller, сигналов ведёт к недопониманию, как работает I/O. Исправление: перечислить все основные компоненты, как в списке выше.
Считать, что планировщик написан на чистом Go без ассемблера.
В ключевых точках (переключение стеков, сохранение/восстановление регистров) используется ассемблер. Без понимания этого трудно объяснить переключение контекста. Исправление: помнить о gogo и gocall в asm_*.s.
Думать, что runtime можно заменить или удалить без глубокой переработки компилятора.
Компилятор GC (go tool compile) сильно завязан на символы рантайма. Исправление: осознавать степень интеграции языка и рантайма, например, new и make напрямую вызывают функции рантайма.

Возможные дополнительные вопросы интервьюера

Какие из компонентов рантайма можно отключить при сборке?
Сборщик мусора нельзя отключить, но можно изменить его поведение через GOGC=off или memory limit. Race detector подключается флагом -race. Netpoller всегда встроен.
Как генерация кода компилятором помогает рантайму при defer?
Компилятор строит таблицу defer с информацией о стеке и PC, а рантайм обрабатывает её при панике или return, обеспечивая обход всех отложенных функций.
Где физически лежат исходники syscall-обёрток для Linux?
В runtime/internal/syscall и runtime/sys_linux_amd64.s, где через ассемблер вызывают инструкцию SYSCALL, минуя обёртки libc.

Как runtime управляет памятью?

Краткий ответ (30–60 секунд)

Рантайм реализует собственный аллокатор на основе TCMalloc: мелкие объекты (до 32 КБ) распределяются из арен mcaches на каждом P, более крупные — напрямую из куч (mheap). Сборщик мусора использует трёхцветный алгоритм с барьерами записи, короткими паузами STW на этапах mark start/termination и большей частью работает конкурентно. Память возвращается ОС через madvise. Управление стеком: разделяемые сегменты заменены копирующим стеком, растущим при необходимости.

Развёрнутый ответ

Go избегает вызова malloc для каждого объекта. Вместо этого он предварительно запрашивает у ОС большие регионы памяти (через mmap), разбивает их на страницы и классы размеров. Всего классов — порядка 70. Каждый P владеет mcache с быстрыми буферами для мелких объектов. При нехватке mcache пополняется из центрального mcentral, который управляет свободными пролётами в спанах. mheap управляет всеми спанами и аренами памяти. Большие объекты (>32 КБ) выделяются непосредственно из mheap и освобождаются индивидуально.

Сборщик мусора работает в двух фазах:

Mark: обход всех достижимых объектов, начиная с корней (глобальные переменные, стеки горутин, регистры). В основном конкурентный, но требует STW для инициализации и завершения. Использует барьеры записи (shade(Object)) для отслеживания изменений указателей во время конкурентного маркирования.
Sweep: очистка непомеченных объектов. Выполняется конкурентно, в то время как горутины выделяют память.

Сборка мусора инициируется при превышении процента от последней живой кучи (GOGC=100 по умолчанию) или при приближении к лимиту памяти.

Под капотом (internals)

Структуры: mheap содержит глобальную блокировку и массивы arenas; mspan — участок кучи с объектами одного класса размера; mcache — кэш с быстрым доступом без блокировок. Аллокация мелких объектов: runtime.mallocgc(...). Объекты размером до 16 байт используют безбарьерные кэши. Барьер записи — это вызов gcWriteBarrier в моменты присваивания указателя в хип (компилятор вставляет проверку writeBarrier.enabled). При panic или defer также могут срабатывать барьеры. Копирование стека горутины выполняет runtime.copystack, который копирует фреймы и обновляет указатели.

Типичные ошибки кандидатов

Считать, что в Go нет фрагментации памяти.
Аллокация через классы размеров минимизирует, но не исключает внутреннюю фрагментацию (объект 65 байт попадает в класс 80 байт — потеря 15 байт). Исправление: признавать наличие проблемы, компенсируемой быстродействием.
Путать копирующий стек горутины с кучей.
Стек управляется отдельно, его расширение вызывает выделение новой области и копирование; это не объекты GC. Исправление: различать stack и heap в контексте горутины.
Думать, что GOGC=100 означает, что GC запустится, когда куча вырастет вдвое от предыдущего сбора.
На самом деле GOGC=100 устанавливает цель: сборка запускается, когда новая куча достигнет prev_live * (1 + GOGC/100). После получения лимита памяти (Go 1.19) поведение усложняется. Исправление: изучить формулу в runtime/metrics.
Полагать, что ручной вызов runtime.GC() полностью освобождает память ОС.
Сборщик возвращает память не сразу, а через scavenger, который периодически отдаёт неиспользуемые страницы ОС через madvise(MADV_DONTNEED). Исправление: мониторить RSS и использовать debug.FreeOSMemory().

Возможные дополнительные вопросы интервьюера

Что такое write barrier и как он реализован на уровне ассемблера?
Это булев флаг и функция gcWriteBarrier, которая помечает слот как серый. Компилятор вставляет проверку перед каждой записью указателя в кучу; реализация — небольшие ассемблерные пути в runtime/asm_*.s.
Какие преимущества и недостатки копирующего стека перед сегментированным?
Преимущество: отсутствие проблемы «горячей точки» при граничном доступе. Недостаток: необходимость обновления всех указателей на стеке (overhead). Ранний Go использовал сегменты, но отказался в пользу копирования.
Можно ли влиять на частоту GC программно?
Да, через runtime/debug.SetGCPercent, runtime/debug.SetMemoryLimit, а также переменную GOGC окружения.

Как runtime управляет горутинами (goroutines)?

Краткий ответ (30–60 секунд)

Горутины — это легковесные потоки, управляемые планировщиком Go. Рантайм создаёт для каждой горутины структуру g с сегментом стека (начальный размер ~2 КБ), сохраняет контекст (PC, SP, g) и планирует их на логические процессоры p, привязанные к потокам ОС m. Горутины кооперативно передают управление в точках вызова функций, каналов, сетевых операций, а с версии 1.14 поддерживается асинхронная преемпция на основе сигналов.

Развёрнутый ответ

Создание: go f(args) компилируется в вызов runtime.newproc(size, f), который размещает в куче новую структуру g со стартовым стеком. g ставится в очередь локального или глобального выполнения. Планировщик (функция schedule) находит готовую к выполнению горутину, переключает контекст текущего m на неё через gogo. Переключение контекста примерно в 10 раз дешевле, чем переключение потоков ОС, поскольку не требует системных вызовов и сохраняет лишь несколько регистров.

Горутины блокируются на каналах, таймерах, select, сетевых операциях. В таких случаях они помещаются в очередь ожидания (waitq) объекта блокировки, а p освобождается для выполнения других горутин. Блокирующие системные вызовы переводят m в режим ожидания, при этом p перехватывается свободным m или idle-пулом, чтобы не простаивал CPU. Асинхронная преемпция (1.14+) посылает сигнал SIGURG потоку, который провоцирует безопасную точку (safe-point) и вызов morestack, где проверяется флаг преемпции.

Под капотом (internals)

struct g содержит stack (lo, hi), sched (сохранённые sp, pc, g), atomicstatus, каналы ожидания и т.д. При создании newproc1 аллоцирует стек, устанавливает sched.pc на runtime.goexit и sched.sp на верхушку стека с раскрученными фреймами. Переключение на горутину: runtime.gogo(&g.sched) — это ассемблерная функция, загружающая регистры из gobuf. findrunnable реализует многоуровневый поиск работы: локальная очередь, глобальная очередь, netpoller, work stealing у других p, и наконец опрос таймеров.

Типичные ошибки кандидатов

Считать, что у каждой горутины фиксированный стек 4 КБ, и он не растёт.
Стек динамически растёт: минимальный размер 2 КБ (Go 1.22), он копируется в больший при нехватке. Исправление: знать о runtime.morestack и копировании.
Утверждать, что горутина всегда вытесняется через системный таймер.
До 1.14 использовалась кооперативная преемпция по границам фреймов; асинхронная преемпция через сигналы появилась позже. Исправление: ссылаться на async preemption и SIGURG.
Думать, что заблокированная на syscall горутина освобождает p мгновенно.
Syscall может занять время, и только после таймаута (~20 мкс) sysmon отбирает p и передаёт другому m. Исправление: понимать логику handoffp и sysmon.
Полагать, что количество горутин ограничено только памятью, игнорируя накладные расходы планировщика.
Миллионы горутин создают нагрузку на планировщик, очереди и GC. На практике десятки тысяч — нормально, но для миллионов требуется тюнинг. Исправление: обсуждать «goroutine leak» и задержки при остановке мира.

Возможные дополнительные вопросы интервьюера

Какая структура хранит информацию о стеке горутины?
g.stack (тип stack) с полями lo и hi. Также есть stackguard0 для обнаружения переполнения.
Как планировщик решает, что горутину пора вытеснить?
Через флаг preempt в g, который выставляется sysmon или сигналом. При достижении safe-point (например, проверка stackguard0) горутина добровольно вызывает runtime.Gosched.
Что значит «goroutine leak» и как его найти?
Утечка горутин — бесконечное ожидание на канале, мьютексе или сетевом вызове без возможности завершения. Обнаруживается через pprof по профилю горутин, runtime.NumGoroutine() или /debug/pprof/goroutine.

Что такое планировщик (scheduler)?

Краткий ответ (30–60 секунд)

Планировщик Go — это компонент рантайма, распределяющий горутины (g) по потокам ОС (m) с использованием логических процессоров (p). Работает по принципу M:N (мультиплексирование M горутин на N потоков ОС). Ключевые обязанности: планирование выполнения, вытеснение, балансировка нагрузки через work stealing, обработка блокировок и системных вызовов, поддержка сетевого поллинга.

Развёрнутый ответ

Планировщик реализует две основные функции: schedule() — выбор следующей горутины для выполнения на текущем m, и findrunnable() — поиск работы, если локальная очередь пуста. Алгоритм:

Проверить локальную очередь текущего p (runq — lock-free ring buffer).
Заглянуть в глобальную очередь раз в 61-е планирование (для справедливости).
Обратиться к netpoller за готовыми сетевыми горутинами.
Попытаться украсть работу у другого p (work stealing) — обход allp с рандомизированным началом.
При отсутствии работы m уходит в режим ожидания (idle), паркуется в списке ожидающих потоков, пока не появится новая горутина или таймер.

Механизм вытеснения: для кооперативной (до 1.13) — по границе фрейма на основе stackguard; для асинхронной (1.14+) — sysmon посылает сигнал SIGURG потоку, при обработке сигнала runtime·asyncPreempt выставляет флаг преемпции, и при следующей проверке безопасного региона горутина вызовет morestack и запланирует передачу управления.

Под капотом (internals)

В runtime/proc.go: schedule() сохраняет контекст текущего g в g.sched, загружает новый через gogo. Локальная очередь p.runq — массив из 256 элементов и индексы head/tail, обращение без атомарных операций (только producer-consumer синхронизация). Глобальная очередь (sched.runq) защищена мьютексом. Work stealing: runqsteal копирует половину элементов из чужой очереди. sysmon запускается как отдельный поток без p, периодически выполняет проверки: готовность netpoller, преемпцию горутин, захват p у заблокированных на syscall m, утилизацию таймеров.

Типичные ошибки кандидатов

Утверждать, что планировщик использует FIFO для локальных очередей.
Локальная очередь — lock-free кольцевой буфер, потребитель (владелец p) забирает с головы, вор крадёт с хвоста, что даёт LIFO для владельца и FIFO для воровства. Ошибка приводит к непониманию аномалий порядка выполнения. Исправление: знать устройство runq.
Думать, что work stealing обязательно обходит все p.
Ищется p с непустой очередью, начиная со случайного индекса, не полный обход. Исправление: помнить о stealOrder.start = случайный.
Игнорировать роль spinning потоков при переходе в idle.
Поток после неудачного поиска работы не всегда сразу паркуется; он может «крутиться» (spin) короткое время, ожидая внезапного появления работы, чтобы избежать задержек пробуждения. Исправление: знать константу maxSpinning и spinning состояние m.

Возможные дополнительные вопросы интервьюера

Что означает приоритет горутин? Есть ли он в Go?
Явного приоритета нет, но голодание может возникать из-за особенностей очередей. Гарантируется прогресс, но не честность.
Почему каждая 61-я операция планирования обращается к глобальной очереди?
Чтобы горутины в глобальной очереди не голодали бесконечно, когда локальные постоянно пополняются. Эвристика на основе константы schedtick % 61.
Как планировщик избегает гонок при работе с списком m в idle-пуле?
Используется sched.midle (мьютекс sched.lock), а для быстрого захвата есть атомарные списки freem. Детали в proc.go.

Что такое `sysmon`?

Краткий ответ (30–60 секунд)

sysmon — это специальный поток ядра Go, запускаемый без привязки к p. Он выполняет функции мониторинга: выявление заблокированных на системных вызовах m для освобождения их p, проверку необходимости асинхронной преемпции горутин, опрос netpoller, утилизацию неиспользуемых таймеров, освобождение памяти ОС и контроль зависших горутин (преемпция на основе времени). Работает циклично с постепенно увеличивающейся задержкой до 10 мс.

Развёрнутый ответ

sysmon стартует при инициализации рантайма в функции newm(sysmon, nil). Он работает в бесконечном цикле, просыпаясь каждые ~20 мкс в активной фазе и до 10 мс при низкой нагрузке. Основные задачи:

Retake p from blocked m: если m находится в системном вызове более 20 мкс (константа forcePreemptNS), sysmon забирает его p и передаёт другому m или паркует p в idle, чтобы не простаивал CPU.
Preempt long-running goroutines: отслеживает p с работающей горутиной дольше 10 мс, выставляет g.preempt = true и, при асинхронной преемпции, посылает signal SIGURG.
Netpoll: вызывает netpoll(0) для получения списка готовых горутин, ставит их в очередь runq.
Timer check: очищает отжившие таймеры, добавляет готовые горутины в очереди.
Scavenge: периодически возвращает неиспользуемую память ОС.

Под капотом (internals)

В runtime/proc.go функция sysmon содержит цикл с вызовом usleep(delay). Задержка динамическая: если не было работы, delay растёт до 10 мс; если работа была, delay сбрасывается до 20 мкс. Проверка блокировки m в syscall: retake(now) анализирует состояние m по структуре m.p, m.lockedg и времени последнего изменения p. Если p.status == _Psyscall и прошло больше порога, выполняется handoffp. Асинхронная преемпция: preemptone(p) отправляет сигнал SIGURG потоку m через tgkill. Поток обрабатывает сигнал в runtime.sighandler, устанавливая флаг преемпции.

Типичные ошибки кандидатов

Считать, что sysmon привязан к p.
Он работает на своём m без p, что позволяет ему не участвовать в планировании горутин и иметь гарантированный ход. Исправление: подчёркивать, что это «непривязанный» (unbound) поток.
Думать, что sysmon только для преемпции.
Он также отвечает за netpoller и возврат памяти. Игнорирование этих задач сужает понимание роли. Исправление: перечислить все периодические проверки.
Забывать о 20 мкс задержке перед захватом p у syscall-потока.
Это компромисс: короткие syscall'ы не вызывают лишних миграций p. Кандидаты могут предполагать мгновенный захват, что неверно. Исправление: упоминать forcePreemptNS.
Утверждать, что sysmon может преемптировать горутину в любой точке.
Асинхронная преемпция требует safe-point. sysmon лишь инициирует сигнал, а сама горутина прерывается только при входе в функцию или проверке stackguard. Исправление: знание механизма асинхронной преемпции.

Возможные дополнительные вопросы интервьюера

Можно ли управлять работой sysmon из кода программы?
Нет, он часть рантайма и не экспонирован. Влияние косвенное: через runtime.LockOSThread можно повлиять на захват p, но управлять sysmon нельзя.
Что будет, если sysmon зависнет?
Системные вызовы могут навсегда заблокировать p, таймеры перестанут обрабатываться, преемпция сломается, программа может войти в livelock. Потеря мониторинга фатальна.
Каким образом sysmon взаимодействует с netpoller?
Вызовом netpoll(0) он получает список горутин, готовых к сетевому вводу/выводу, и через injectglist добавляет их в глобальную или локальную очередь.

Как работает `sysmon` и зачем он нужен?

Краткий ответ (30–60 секунд)

sysmon — монитор системного состояния. Он нужен для утилизации ресурсов: предотвращает блокировку P на долгих системных вызовах, обеспечивает справедливую преемпцию CPU-bound горутин, запускает готовые после netpoller горутины и возвращает память ОС. Без него горутина, выполняющая бесконечный цикл без вызовов, могла бы навсегда оккупировать поток, а p мог бы простаивать при ожидании syscall.

Развёрнутый ответ

До версии 1.14 планировщик полагался на кооперативную преемпцию в точках вызова функций. sysmon отмечал горутины, работающие дольше 10 мс, флагом preempt, и при следующем вызове функции горутина проверяла stackguard0 и добровольно передавала управление. С асинхронной преемпцией sysmon посылает сигнал потоку, который выполняет эту горутину, что делает преемпцию почти мгновенной (в safe-point). Захват p у занятых syscall'ом m реализует паттерн «handoff». Алгоритм:

sysmon в цикле вызывает retake(now), где перебирает все p. Если p в состоянии _Psyscall и прошло > 20 мкс, выполняется handoffp — p передаётся другому m или помечается как idle, а старый m продолжает syscall без p.
Если после syscall'а m освободится, он попытается найти себе p или встанет в idle.

Таким образом, sysmon — это сердце гарантии утилизации CPU и отзывчивости для горутин.

Под капотом (internals)

retake (в runtime/proc.go) для каждого p проверяет _Psyscall или _Prunning. Для syscall: использует m.lockedg, p.syscalltick для отслеживания длительности. handoffp разрывает связь m и p, запускает startm для поиска нового m для p. Сигнал SIGURG: tgkill(getpid(), m.procid, sigPreempt). В обработчике сигнала runtime·doSigPreempt сохраняет регистры в g.sigcontext и вызывает asyncPreempt, которая в итоге приводит к вызову mcall и планированию.

Типичные ошибки кандидатов

Смешивать роли sysmon и netpoller.
netpoller — механизм ожидания событий; sysmon вызывает netpoll(0) и ставит горутины в очередь. Кандидаты могут сказать, что sysmon сам опрашивает сеть — это неточно. Исправление: разграничивать сущности.
Утверждать, что sysmon работает с постоянной периодичностью 10 мс.
Частота динамическая, от 20 мкс до 10 мс, для снижения энергопотребления при низкой активности. Исправление: указать адаптивность задержки.
Полагать, что после syscall m гарантированно возвращает свой p.
Если p был передан другому m, он потерян. exitsyscall сначала пытается забрать свой старый p, затем ищет любой свободный, иначе паркуется. Исправление: знать exitsyscall и fast-path/wakep.

Возможные дополнительные вопросы интервьюера

Можем ли мы обойтись без sysmon, если используем только горутины с сетевым I/O?
Нет, потому что CPU-bound горутины без преемпции будут вешать программу, а таймеры без sysmon не будут обрабатываться.
Влияет ли sysmon на latency сетевых вызовов?
Косвенно: он периодически опрашивает netpoller, добавляя задержку до 20 мкс. Для низколатентных задач это может быть заметно, но в целом терпимо.
Как sysmon определяет, что горутина работает слишком долго?
Через p.schedtick и p.syscalltick, сравнивая текущее время с p.runnext не напрямую; для преемпции используется sysmon с таймаутом 10 мс и выставление preempt в g.

Что такое `netpoller`?

Краткий ответ (30–60 секунд)

netpoller — компонент рантайма, который эффективно ожидает готовности сетевых операций (чтение/запись) без блокировки потоков ОС. Он использует мультиплексирование I/O: epoll (Linux), kqueue (macOS/BSD), IOCP (Windows). Когда горутина хочет выполнить сетевой вызов, она регистрирует файловый дескриптор в netpoller и паркуется. Позднее, при наступлении события, netpoller пробуждает соответствующую горутину через планировщик.

Развёрнутый ответ

Все сетевые операции в Go (через net пакет) в конечном итоге обращаются к рантаймовому netFD. При вызове Read() на сокете, если данных нет, горутина вызывает gopark с функцией park_m, которая регистрирует интересующую операцию в netpoller через netpollblock. Поток ОС не блокируется; планировщик освобождает p для другой работы. Netpoller самостоятельно, в выделенном потоке или через sysmon, опрашивает ОС на наличие готовых событий (epoll_wait с нулевым таймаутом). При появлении событий он извлекает соответствующие горутины и помещает их в очередь готовых.

Два основных режима вызова:

При планировании: в findrunnable() планировщик вызывает netpoll(false) для немедленного получения готовых горутин.
Периодически sysmon: вызов netpoll(true) с блокировкой до таймаута, чтобы не пропустить события в спящей системе.

Под капотом (internals)

Структура pollDesc связывает дескриптор и горутины ожидания (wg для чтения и записи). runtime/netpoll.go содержит общий интерфейс, платформенно-специфичные файлы (netpoll_epoll.go) реализуют netpollinit, netpollopen, netpollclose, netpoll(). Epoll: epoll_create1, epoll_ctl, epoll_wait. Дескриптор добавляется в epoll при первом вызове netpollopen. Когда горутина паркуется, её g записывается в pd.wg, а статус pd обновляется. При пробуждении netpoll извлекает готовые pd, вызывает netpollgoready, которая переводит g в состояние _Grunnable и помещает в очередь.

Типичные ошибки кандидатов

Считать, что netpoller вызывает колбэк напрямую, как в Node.js.
Это низкоуровневая интеграция с планировщиком: он лишь переводит горутину в очередь готовых, а не запускает её немедленно. Исправление: указывать на injectglist и добавление в runq.
Полагать, что netpoller работает на отдельном потоке ОС.
Он может работать в контексте sysmon или любого m, делающего findrunnable. Специальный выделенный поток не нужен. Исправление: объяснять вызов netpoll(0) в sysmon и findrunnable.
Думать, что операции с файлами (File.Read) используют netpoller.
Обычные файловые дескрипторы на дисках почти всегда готовы, и Go прибегает к блокирующему read в отдельной горутине (через syscall блокирующий поток). Netpoller только для сокетов и pipe. Исправление: различать файловый I/O и сетевой.

Возможные дополнительные вопросы интервьюера

Может ли горутина ожидать несколько событий одновременно?
Да, через select с несколькими сетевыми каналами. runtime.netpollcheck и netpollblock позволяют парковать одну горутину для нескольких pd; пробуждается при любом готовом.
Что случится, если epoll_wait вернёт ошибку?
Рантайм обрабатывает EINTR повторным вызовом, другие ошибки могут привести к пропуску событий или панике.
Какие преимущества даёт интеграция netpoller с планировщиком?
Позволяет обрабатывать миллионы соединений с малым количеством потоков ОС, избегая модель «thread-per-connection» и высоких накладных расходов на контекст ОС.

Как runtime взаимодействует с ОС?

Краткий ответ (30–60 секунд)

Взаимодействие осуществляется через прямые системные вызовы, обёртки над libc (для некоторых платформ, например, macOS), сигналы UNIX и низкоуровневые операции с памятью (mmap/munmap). Рантайм минимизирует зависимость от libc на Linux (делая syscall напрямую) для контроля аллокаций и планирования. Для переносимости используются внутренние пакеты runtime/internal/syscall и syscall. События ОС (сигналы, готовность сети) транслируются в модель горутин через netpoller и диспетчер сигналов.

Развёрнутый ответ

Системные вызовы: на Linux x86-64 Go в runtime/internal/syscall вызывает SYSCALL инструкцию, передавая номер вызова и аргументы через регистры. Это позволяет обходить glibc, но для некоторых сложных вызовов (например, clone) используется небольшая ассемблерная прослойка.
Управление памятью: рантайм управляет виртуальной памятью через mmap/munmap/mprotect. Кучи растут аренами (arena), аллоцированными через mmap.
Потоки ОС: создание и управление через clone (Linux) с флагами CLONE_VM, CLONE_FS, CLONE_FILES, CLONE_SIGHAND, CLONE_THREAD, что создает потоки, разделяющие адресное пространство. Для Windows используются CreateThread.
Сигналы: sigaction для установки обработчиков SIGSEGV (для обработки нулевых указателей и stack guard), SIGURG (преемпция), SIGPROF (pprof), SIGPIPE (игнорируется). Диспетчер сигналов различает синхронные и асинхронные сигналы.
Сетевые события: через epoll/kqueue/IOCP (см. netpoller).
Планирование и блокировки: futex на Linux — для блокировки потоков при ожидании горутин (park/unpark) и реализации внутренних мьютексов рантайма.

Под капотом (internals)

runtime/os_linux.go: инициализация ОС в osinit, syscall вызовы в sys_linux_$arch.s. Макросы SYS_read, etc., определены в zsysnum_linux_$arch.go. madvise для возврата памяти. newosproc (создание потока) использует clone, а не pthread, чтобы тонко управлять стеком. runtime.futex реализован через syscall.Syscall(SYS_futex, ...). netpoll использует epoll_create1 (CLOEXEC) и epoll_wait. Для macOS: kqueue и kevent; сигнальный поток маскирует сигналы и вызывает sigsend через tgkill для обработки в нужном m.

Типичные ошибки кандидатов

Полагать, что все системные вызовы идут через libc.
На Linux рантайм выполняет прямые syscall, чтобы избежать накладных расходов и контроля libc над сигналами. Исключение — macOS (из-за политики Apple) и Windows (DLL). Исправление: знать различие платформ.
Думать, что блокировка m на syscall уничтожает p, а не просто передаёт.
При блокирующем syscall p не теряется, а передается другому m для продолжения работы. Исправление: говорить о handoffp.
Игнорировать разницу между синхронными и асинхронными сигналами в обработке рантайма.
SIGSEGV от нулевого указателя должен обрабатываться на том же m и g, где произошло нарушение; асинхронные сигналы, такие как SIGURG, могут быть обработаны в любом потоке, но с сохранением контекста. Исправление: изучить диспетчеризацию сигналов.

Возможные дополнительные вопросы интервьюера

Как Go отслеживает состояние m при входе в syscall?
entersyscall переводит p в статус _Psyscall, сохраняет m.p для быстрого восстановления. При возврате exitsyscall пытается забрать свой p обратно.
Зачем рантайм использует futex напрямую, а не pthread-мьютексы?
Для низкоуровневой синхронизации с минимальными накладными расходами и возможностью точной настройки пробуждения (например, нескольких потоков).
Что такое SIGPIPE и как Go с ним поступает?
По умолчанию игнорируется в signal.Ignore(syscall.SIGPIPE), чтобы записи в закрытый сокет не убивали процесс. Можно перехватить вручную.

Что такое системный вызов (syscall)?

Краткий ответ (30–60 секунд)

Системный вызов — это механизм, с помощью которого пользовательская программа запрашивает сервис ядра ОС: операции ввода-вывода, управление памятью, процессами, файловой системой. В Go системные вызовы обёрнуты в пакете syscall или x/sys/unix, а рантайм использует прямые вызовы через ассемблер. С точки зрения рантайма syscall делится на блокирующий (может занять неопределённое время) и неблокирующий. Блокирующий syscall приводит к отсоединению p от m для предотвращения простоя CPU.

Развёрнутый ответ

Syscall — переход из пользовательского режима в режим ядра через специальную инструкцию (SYSCALL/sysenter/int 0x80). В Go на Linux пакет syscall экспортирует обёртки, которые в итоге выполняют runtime.entersyscall, ассемблерную инструкцию SYSCALL, затем runtime.exitsyscall. Например, syscall.Read -> Syscall(SYS_read, uintptr(fd), uintptr(p), uintptr(n)) -> syscall.Syscall6 на ассемблере. Рантайм не использует libc для простых вызовов (на Linux), но для macOS из-за отсутствия стабильного ABI вынужден идти через libSystem.

Классификация:

Блокирующие: read на сокете без данных, futex с ожиданием. Рантайм заранее помечает p как _Psyscall, и после syscall восстанавливает.
Неблокирующие: getpid, nanosleep(0). Выполняются быстро, не вызывая handoff p.
RawSyscall: обёртка без entersyscall/exitsyscall, используется очень осторожно (например, в signal handler), чтобы не нарушить состояние рантайма.

Под капотом (internals)

В runtime/sys_linux_amd64.s: TEXT runtime·syscall(SB),NOSPLIT,$0-56 перемещает аргументы в регистры (MOVQ, MOVL), вызывает SYSCALL, проверяет результат. При ошибке возвращает -errno. runtime.entersyscall блокирует g для GC (чтобы не сканировать стек), сохраняет p, вызывает gosave для возможности преемпции. После возврата exitsyscall пытается восстановить p; если не получается, горутина паркуется.

Типичные ошибки кандидатов

Считать, что все вызовы syscall.Syscall автоматически обрабатывают рантаймовую блокировку.
Есть RawSyscall, который не обращается к рантайму, и его неправильное использование может привести к порче p/m. Исправление: различать Syscall и RawSyscall, читать документацию.
Полагать, что системный вызов всегда приводит к переключению контекста на уровне ОС.
Некоторые вызовы (например, getpid) могут обслуживаться без переключения (vsyscall/vDSO). Go может использовать vDSO для clock_gettime и getrandom с целью ускорения.
Утверждать, что syscall.Read для обычного файла неблокирующий.
Обычные дисковые файлы всегда готовы к чтению (в смысле poll), но сам read может блокироваться в ядре на время дискового I/O. Рантайм Go не может использовать netpoller для такого файла, и для избежания блокировки потока создаётся отдельный поток (blocking syscall path). Исправление: знать о blockingReader и pollDesc.

Возможные дополнительные вопросы интервьюера

Как рантайм узнаёт, что syscall завершился и пора восстановить p?
По факту возврата из syscall управление передаётся на инструкцию, следующую за SYSCALL, затем вызывается exitsyscall. Там проверяется статус p и решается, что делать.
Почему на macOS обязателен libc для syscall?
Apple не гарантирует стабильность ядерного ABI, номера системных вызовов меняются между версиями, и вызовы через libSystem.dylib — единственный поддерживаемый способ.
Что такое vDSO и как Go его использует?
vDSO — виртуальная динамическая разделяемая библиотека в адресном пространстве ядра, доступная пользовательскому коду для быстрого выполнения некоторых syscall (clock_gettime). Go с помощью runtime.vdso* вызывает её напрямую для уменьшения задержек в time.Now.

Что такое `CGO`?

Краткий ответ (30–60 секунд)

CGO — механизм вызова кода на языке C из Go и наоборот. Он позволяет линковать внешние C-библиотеки и использовать заголовки. При вызове C-функции горутина временно переходит с лёгкого стека Go на системный стек, а вызов проходит через прослойку, генерируемую cgo-тулом. Это сопряжено с дополнительными накладными расходами (переключение стека, блокировка m), что делает CGO «дорогим» и потенциально блокирующим для планировщика.

Развёрнутый ответ

Для использования CGO в коде нужен комментарий import "C", перед которым идёт блок /* ... */ с заголовками и директивами линковки. go build запускает cgo — препроцессор, который генерирует обёртки на Go и C, компилирует C-файлы, линкует объектные файлы. При вызове C функции рантайм выполняет:

entersyscall или специализированный cgocall, чтобы отметить занятость m и предотвратить GC стека горутины.
Переключение на системный стек g0 (или специальный системный стек CGO) для выполнения C-кода.
Вызов сгенерированной ассемблерной функции _cgo_..., которая устанавливает C-стек, вызывает целевую функцию.
После возврата восстанавливается стек Go, вызывается exitsyscall, возможно handoff p.

Поток m во время выполнения C-кода считается блокированным (не участвует в планировании), но p может быть передан другому m. Если C-код долгий, sysmon отберёт p.

Под капотом (internals)

Механизм cgocall в runtime/cgocall.go: сохраняет текущий g в m.g0, переключается на g0, вызывает asmcgocall(fn). asmcgocall переходит на ассемблерный переходник, который настраивает C-стек и вызывает fn. Для возврата используется recovery и восстановление g стека. GC при этом не должен освобождать память, используемую C-кодом, поэтому указатели, передаваемые в C, должны быть защищены runtime.KeepAlive или не должны перемещаться (выделяться в куче специальным аллокатором C.malloc). cgo добавляет барьеры записи при передаче указателей между кучами Go и C.

Типичные ошибки кандидатов

Считать, что CGO-вызов дешёв, как обычный вызов Go функции.
Переключение стека (около 50-100 нс) плюс возможная блокировка m, увеличение задержек. Исправление: количественно оценивать overhead и предлагать альтернативы (pure Go).
Передавать указатели на Go-объекты в C без runtime.Pin или явных механизмов.
GC может переместить объект, и указатель станет невалидным. Исправление: использовать C.malloc / C.CBytes, или фиксировать с помощью runtime.Pin (Go 1.21+) для указателей, пересекающих границу.
Многократно вызывать мелкие C-функции в цикле, не замечая, что блокировка m сериализует горутины.
Хотя p передаётся, m блокирован для C вызова, что снижает конкурентность. Исправление: минимизировать частоту CGO-вызовов или выполнять пакетную обработку.
Полагать, что небезопасный пакет unsafe и CGO — это одно и то же.
Это разные механизмы. unsafe работает с памятью Go, CGO — с внешними вызовами. Исправление: различать.

Возможные дополнительные вопросы интервьюера

Можно ли вызывать Go-функции из C через CGO?
Да, экспортировав //export GoFunc. Рантайм создаёт обратную прослойку: при вызове из C происходит переключение на стек Go, установка g, и может выполняться планировщик.
Что такое _cgo_gotmp и зачем cgo генерирует такие символы?
Это временные переменные, используемые обёртками для сохранения промежуточных результатов и переключения контекста; они видны как заглушки в pprof.
Какие ограничения накладываются на код, вызываемый через CGO, в отношении GC?
Нельзя удерживать указатели на Go-объекты, которые могут быть собраны, если не применить runtime.KeepAlive. Также следует остерегаться длительных C-вызовов, затрагивающих планирование.

Почему `CGO` дорог?

Краткий ответ (30–60 секунд)

Дороговизна CGO обусловлена: (1) необходимостью переключения стека между Go (динамический, растущий) и C (фиксированный, обычно 8 МБ); (2) блокировкой потока m на время выполнения C-кода, что вынуждает планировщик передавать p другому m и обратно после завершения; (3) дополнительными прослойками и функциональными вызовами; (4) влиянием на GC (барьеры памяти, невозможность перемещения переданных в C блоков памяти). Всё это добавляет как прямые задержки (latency), так и косвенные издержки на планирование и сборку мусора.

Развёрнутый ответ

Переключение стека: Go использует маленькие растущие стеки (2 КБ+), тогда как C ожидает большой фиксированный стек. При входе в C рантайм переключается на g0 стек (или отдельный стек m.cgoStack), что требует сохранения регистров и переключения страниц стека. Эта операция стоит порядка десятков наносекунд в лучшем случае, но может включать syscall для изменения guard page.

Участие планировщика: Вызов C рассматривается как блокирующая операция, подобная syscall. entersyscall (или cgocall) переводит p в _Psyscall, разрешая sysmon захватить p. После возврата из C нужна exitsyscall, которая может потратить время на поиск нового p, если старый забрали. Это разрушает кэш локальной очереди и может привести к миграциям горутин.

Воздействие на GC: Пока m в C, GC приостановлен? Не совсем, но m не участвует в stop-the-world, но и не может сканировать свой Go-стек, если горутина всё ещё существует. GC должен ждать возврата всех m из C, что задерживает паузу STW. Кроме того, Go не может перемещать память, переданную в C, требуя cgo.Handle или C.malloc.

На практике: даже короткий вызов C-функции (например, getpid()) имеет значительные накладные расходы по сравнению с чистым Go-вариантом (использующим прямой syscall). Высокая частота CGO-вызовов может привести к деградации пропускной способности на порядки.

Под капотом (internals)

runtime.cgocall выполняет: entersyscall(), сохранение g в m.g0, переключение на g0, вызов asmcgocall(fn). asmcgocall (в asm_amd64.s) изменяет SP на m.g0.sched.sp, вызывает fn через CALL. На обратном пути восстанавливается Go-стек, вызывается exitsyscall(). Всё это находится под блокировкой m для g. Если в этот момент sysmon отобрал p, exitsyscall при попытке вернуть старый p обнаружит, что он уже у другого m, и перейдёт в путь поиска свободного p или парковки горутины.

Типичные ошибки кандидатов

Ошибочное утверждение, что CGO-вызов только изменяет стек, но не влияет на планировщик.
На самом деле он вызывает entersyscall/exitsyscall, что может приводить к перепланированию. Исправление: указать путь cgocall.
Игнорирование влияния на задержку STW паузы.
Из-за ожидания возврата потоков из C паузы GC могут удлиняться. Это критично для приложений с высокой частотой CGO-вызовов. Исправление: оценивать время возврата и использовать GODEBUG=asyncpreemptoff=1 или подобное для облегчения.
Полагаться, что C.malloc полностью решает проблему указателей.
C.malloc выделяет в C-куче, но Go не управляет этой памятью; освобождение должно быть вручную (C.free). Передача указателя из Go в C всё равно требует осторожности. Исправление: знать о cgo.Handle в Go 1.17+ для безопасной передачи инкапсулированных указателей.

Возможные дополнительные вопросы интервьюера

Какие существуют альтернативы CGO для взаимодействия с нативным кодом?
Прямые системные вызовы, реализация функциональности на чистом Go, использование unsafe для структурирования памяти, внешние процессы через API, а с версии 1.20+ готовится улучшенная поддержка WASM и wazero.
Можно ли отключить CGO при сборке?
Да, CGO_ENABLED=0 отключает драйвер cgo. Это часто используется для статических сборок и упрощения кросс-компиляции.
Что такое cgocheck и как он помогает?
GODEBUG=cgocheck=1 включает дополнительные проверки корректности передачи указателей между Go и C, что выявляет нарушения в runtime; по умолчанию включен для race-сборок.

Как происходит запуск программы на Go (bootstrap)?

Краткий ответ (30–60 секунд)

Запуск начинается с ассемблерной точки входа _rt0_<arch>, которая настраивает начальный стек и вызывает runtime·rt0_go. Далее выполняются инициализации ОС (runtime.osinit), выделение начальной кучи (runtime.mallocinit), параметров (runtime.args), планировщика (runtime.schedinit), создаётся главная горутина (runtime.newproc), и запускается главный m (runtime·mstart), который исполняет runtime.main. В runtime.main вызываются все init-функции пакетов, затем main.main, а после её завершения происходит выход с кодом возврата.

Развёрнутый ответ

Пошаговая последовательность (Linux amd64):

Ядро загружает ELF-сегмент, управление передаётся на точку входа _rt0_amd64_linux (или аналогичную), указанную в ELF header.
Ассемблерный код инициализирует регистры, устанавливает SP на выделенный стек, сохраняет argc/argv, переходит к runtime·rt0_go (в asm_amd64.s).
rt0_go вызывает runtime.args (разбирает аргументы командной строки, окружение), runtime.osinit (число CPU, настройка ncpu), runtime.schedinit (инициализация allp, инициализация планировщика, создание m0, g0, p0, запуск sysmon, netpoller).
Создаётся главная горутина main с помощью runtime·newproc(0, runtime.main). Она ставится в очередь p0.
Вызывается runtime·mstart на текущем m0, который запускает планировщик: schedule() находит горутину main и переключается на неё.
runtime.main выполняется на горутине main. Сначала вызывает doInit для всех init-функций пакетов в порядке импорта (с помощью runtime·main_init_done), затем вызывает main_main (пользовательская main).
После возврата из main.main runtime.main вызывает exit(0). Все горутины завершаются принудительно.

Под капотом (internals)

rt0_go в runtime/asm_amd64.s выделяет место для g0 и m0, инициализирует TLS (thread-local storage) для текущего потока, чтобы get_tls работало. schedinit создаёт массив allp (размер GOMAXPROCS), привязывает m0 к p0. newproc выделяет g для main с начальным стеком 2 КБ (параметр _StackMin), устанавливает sched.pc на runtime.main. mstart устанавливает m.g0 и вызывает schedule. Важно: до вызова schedule работа идёт на системном стеке g0, а на горутине main — после переключения. main_init_done — это барьер, гарантирующий, что все init-функции завершены до main.

Типичные ошибки кандидатов

Полагать, что main.main — это первая выполняемая функция.
До неё инициализируются сотни init-функций, что может замедлить старт. Исправление: упомянуть runtime.main и doInit.
Думать, что во время инициализации уже доступны горутины и каналы.
Да, доступны, но планировщик ещё не запущен в полную силу? На самом деле после schedinit планировщик готов, и newproc создаёт горутины, но выполнение пользовательского кода начинается только после переключения на горутину main. Однако init-функции могут запускать горутины (хотя это не рекомендуется). Исправление: уточнять, что хотя горутины создаются, main-горутина стартует и выполняет init последовательно.
Забывать про runtime.GOMAXPROCS и его влияние на старт.
При schedinit создаётся ровно GOMAXPROCS штук p. Если установлено окружение, оно влияет на количество p сразу. Исправление: знать, что osinit получает число CPU, а schedinit использует getproccount.

Возможные дополнительные вопросы интервьюера

Можно ли запустить программу без main?
Нет, пакет main с функцией main обязателен для исполняемых программ.
Как добавляются init-функции из разных пакетов в порядок выполнения?
Компилятор генерирует в каждом пакете ссылку на init, линковщик строит направленный ациклический граф согласно импортам. runtime.doInit выполняет их в гарантированном порядке.
Что произойдёт, если init-функция вызовет panic?
Программа аварийно завершится с трассировкой стека. runtime.main не будет достигнут.

Какие основные структуры данных использует runtime (`g`, `m`, `p`, `schedt`)?

Краткий ответ (30–60 секунд)

g (горутина) — хранит стек, состояние, saved контекст, канал ожидания; m (машина) — представляет поток ОС, содержит указатели на текущую g, g0 (стек планировщика), p, информацию о блокировках; p (процессор) — логический процессор, владеет локальной очередью горутин, кешем аллокатора (mcache), состоянием (_Pidle, _Prunning, _Psyscall); schedt — глобальная структура планировщика, содержащая глобальную очередь горутин, списки idle m/p, мьютексы, статистику.

Развёрнутый ответ

g (runtime/runtime2.go): поля: stack (lo, hi), stackguard0 (обнаружение переполнения), sched (gobuf с sp, pc, g, lr для восстановления), atomicstatus, goid, m (связанный m), p (если закреплена), waitreason, preempt, defer, panic, timer и т.д. Вся горутина около 80-100 байт плюс стек.
m: поля: g0 (горутина планировщика с системным стеком), curg (текущая пользовательская горутина), p (присоединённый p), nextp (временный p при передаче), id, spinning, locks (счётчик блокировок), park (для ожидания), mOS (специфичный для ОС дескриптор потока), lockedg (для LockOSThread). Потоков создаётся по требованию, лимит — maxmcount (10000 по умолчанию).
p: поля: id, status, m (присоединённый m), runq (массив из 256 guintptr с head/tail), runnext (небольшая оптимизация для быстрого перепланирования), mcache, gfree (кэш свободных g), syscalltick, deferpool и т.д. Количество p равно GOMAXPROCS.
schedt: глобальная структура в runtime/proc.go (sched). Поля: lock (глобальный мьютекс), midle (список свободных m), pidle (список свободных p), runq (глобальная очередь горутин с мьютексом), runqsize, gfree (глобальный список свободных g), ngsys (количество системных горутин), nmspinning, schedtick, sysmonwait.

Под капотом (internals)

Все g, m, p размещаются в куче рантаймом. m и p создаются не через стандартный alloc, а через специальные функции (newm, newp), которые на старте используют статические предвыделенные m0, g0, p0 для main. runq p — lock-free single-producer multi-consumer ring buffer. Потребитель (владелец) использует load-acquire/store-release без атомарных инструкций благодаря выравниванию и свойствам когерентности кэша. Вор (runqgrab) применяет атомики для синхронизации хвоста. schedt.lock используется для глобальных операций, но стараются минимизировать его захват.

Типичные ошибки кандидатов

Путать m и p, считая p физическим потоком.
p — логический контекст, ускоряющий работу с кэшами и очередью. Без p поток не может выполнять пользовательские горутины. Исправление: чётко определить MPG.
Не знать о runnext и его влиянии на порядок.
runnext содержит единственную горутину, которая будет запущена следующей на этом p, обеспечивая лучшую локальность. Но если её перезаписывают, старая теряет приоритет и попадает в очередь. Исправление: упомянуть, что это оптимизация для паттернов «вызов-ответ».
Предполагать, что глобальная очередь (sched.runq) используется для всех горутин.
Основная работа проходит через локальные очереди p. Глобальная очередь — только для горутин, которые не удалось разместить локально, и для балансировки. Исправление: описать политику размещения.
Ошибочно считать schedt аналогом планировщика Linux.
Это не полноценный планировщик, а набор глобальных ресурсов. Планирование распределено по m. Исправление: различать централизованные структуры и децентрализованную логику.

Возможные дополнительные вопросы интервьюера

Каково максимальное количество m и как оно контролируется?
maxmcount (10000) — защита от бесконтрольного создания. Достигается при создании потоков для блокирующих syscall, когда все имеющиеся заняты. Программа аварийно завершается при превышении.
Что хранится в g.goid и как он генерируется?
goid — 64-битный монотонный идентификатор, присваиваемый из sched.goidgen с помощью атомарного прибавления. Уникален в пределах процесса.
Может ли p существовать без m?
Да, p в состоянии _Pidle живёт без m, ожидая, когда поток проснётся и возьмёт его.

Что такое "monitor thread"?

Краткий ответ (30–60 секунд)

«Monitor thread» в контексте Go — это неофициальное название потока sysmon, выполняющего функции системного мониторинга. Он не привязан к p, работает циклически и проверяет необходимость преемпции горутин, захвата p у заблокированных на syscall потоков, опрашивает netpoller и управляет таймерами. Это критически важный фоновый поток, без которого планировщик не мог бы обеспечивать справедливое разделение CPU.

Развёрнутый ответ

В исходниках не встречается термин «monitor thread», но sysmon часто так называют из-за его мониторинговой роли. Он запускается во время schedinit вызовом newm(sysmon, nil). sysmon не имеет p, т.е. он может работать на любом свободном m, но обычно создаётся отдельный поток, который спит, просыпается по таймеру. Задачи monitor thread:

Checkdead & preemption: отслеживает длительно выполняющиеся горутины и инициирует преемпцию.
Retake p: перехват p у потоков, выполняющих системные вызовы дольше 20 мкс.
Netpoll: пробуждает спящие горутины сетевых операций.
Timer cleanup: очищает отработавшие таймеры, запускает горутины, ожидающие time.Sleep.
Scavenging: возвращает неиспользуемую память ОС.

Функционально это не один поток, а логика, привязанная к любому m, исполняющему sysmon. Но на практике это один выделенный m, чтобы не отвлекать рабочие потоки. Важно: он не участвует в выполнении пользовательских горутин.

Под капотом (internals)

В runtime/proc.go, функция sysmon() содержит бесконечный цикл с usleep(delay). delay динамическая: 20 мкс если была работа, иначе растёт до 10 мс. Проверка retake проходит по всем p; если p.status == _Psyscall и syscalltick не менялся дольше порога, вызывается handoffp. Преемпция через preemptone(p) посылает tgkill с sigPreempt. sysmon также отслеживает sched.lastpoll для netpoll. При завершении программы sysmon останавливается специальным механизмом (notewakeup).

Типичные ошибки кандидатов

Путать monitor thread с обычным потоком, имеющим p.
Этот поток работает без p и не участвует в планировании. Кандидаты могут ошибочно предполагать, что sysmon — просто один из рабочих потоков. Исправление: подчеркнуть отсутствие p.
Игнорировать роль sysmon в преемпции после Go 1.14.
Можно подумать, что асинхронная преемпция полностью заменяет sysmon, но он по-прежнему выставляет флаг и отправляет сигнал. Исправление: объяснить, что sysmon остаётся инициатором сигнала.
Считать, что delay в sysmon всегда 10 мс, что приведёт к низкой реактивности.
Динамическая задержка обеспечивает компромисс между реактивностью и энергопотреблением. Исправление: описать адаптивный механизм.

Возможные дополнительные вопросы интервьюера

Можно ли создать свой поток-монитор, подобный sysmon?
Нет, sysmon глубоко интегрирован. Аналогом может служить отдельная горутина с time.Sleep, но она не получит доступ к внутренним структурам рантайма.
Что произойдёт, если sysmon не сможет запуститься?
Рантайм аварийно завершится на этапе инициализации с фатальной ошибкой.
Как остановить sysmon при штатном завершении программы?
exit или возврат из main вызывает runtime.panicit -> exit с остановкой всех потоков. sysmon завершается принудительно.

Как runtime обрабатывает прерывания и сигналы ОС?

Краткий ответ (30–60 секунд)

Рантайм устанавливает обработчики для важных сигналов (SIGSEGV, SIGURG, SIGPROF, SIGPIPE и др.) через sigaction, перехватывая их. Сигналы диспетчеризуются в очередь сигналов (note), а затем в безопасном контексте обрабатываются на соответствующем m. Синхронные сигналы (SIGSEGV в текущей горутине) обрабатываются на том же m немедленно, асинхронные (SIGURG для преемпции) могут доставляться на произвольный m, но форсируют обработку путём выставления флага и вызова asyncPreempt.

Развёрнутый ответ

Рантайм Go максимально контролирует сигналы, чтобы обеспечить стабильность. При инициализации (runtime.signal_init) блокируются все сигналы на будущих потоках, и создаётся специальный поток signal_thread, который их получает. Потоки-рабочие (m) маскируют сигналы, оставляя только некоторые. Сигнальный поток вызывает sigsend(sig) для помещения сигнала в очередь к нужному m или для глобальной обработки. Обработка происходит в runtime.sigtramp → runtime.sighandler.

Типы сигналов:

Синхронные (непосредственно вызваны действием программы, например, доступ к nil): SIGSEGV, SIGBUS, SIGFPE. Они доставляются на выполняющий поток. sighandler проверяет, является ли адрес в стеке guard-страницей (для расширения стека) или нулевым указателем; в последнем случае инициирует панику с помощью sigpanic. Для стека обрабатывается ситуация и стек расширяется.
Асинхронные (SIGURG, SIGPROF): могут быть посланы любому потоку. sighandler для SIGURG проверяет, тот ли это m, и вызывает doSigPreempt — сохраняет контекст и ставит asyncPreempt. Для SIGPROF (сигнал профилирования от setitimer) обновляется профиль.

Игнорируемые сигналы: SIGPIPE (по умолчанию, чтобы запись в закрытый сокет не убила процесс), но можно переопределить через signal.Notify.

Под капотом (internals)

Файлы runtime/os_linux.go, runtime/signal_unix.go, runtime/signal_amd64.s. sigtramp — ассемблерная функция, которая сохраняет все регистры в sigcontext, вызывает runtime.sigtrampgo. В ней для синхронного сигнала: если sig == _SIGSEGV и адрес близок к g.stack.lo — увеличить стек через runtime.morestack. Иначе: sigpanic, которая изменяет PC горутины на runtime.sigpanic и при следующем возобновлении горутина запаникует. Для асинхронного SIGURG: если m не выполняет безопасную точку, сигнал игнорируется; иначе внедряется asyncPreempt.

Типичные ошибки кандидатов

Считать, что любой сигнал можно обработать в пользовательской горутине через signal.Notify.
Некоторые сигналы (SIGSEGV, SIGFPE) не могут быть перехвачены надёжно для продолжения работы; они вызывают панику. SIGKILL и SIGSTOP вообще не перехватываются. Исправление: знать границы перехвата.
Думать, что SIGURP используется исключительно для преемпции.
Да, SIGURG зарезервирован рантаймом. Пользовательский код не должен его ловить, иначе можно нарушить преемпцию.
Игнорировать важность синхронности при обработке SIGSEGV для стека.
Если обработчик не распознает ситуацию расширения стека и просто запаникует, программа упадёт даже при легальном переполнении. Рантайм очень аккуратно различает guard page и реальное нарушение. Исправление: изучить sigpanic и morestack.

Возможные дополнительные вопросы интервьюера

Как Go обрабатывает SIGSEGV при разыменовании nil-указателя в горутине?
sigpanic модифицирует pc горутины на runtime.sigpanic, так что при возврате из сигнала горутина продолжит выполнение с sigpanic, которая вызовет panic с runtime error: invalid memory address or nil pointer dereference.
Можно ли перехватить SIGURP через signal.Notify?
Попытка вызовет панику в signal.Notify, так как рантайм запрещает перехват этого сигнала.
Что такое sigsend и почему для сигналов нужна очередь?
sigsend — это обёртка над атомарной операцией отправки сигнала в очередь m. Очередь нужна для того, чтобы сигнал обрабатывался в контексте конкретного потока, а не в прерывании, где ограничен функционал (нельзя захватывать блокировки).

Как работает `time.Sleep`?

Краткий ответ (30–60 секунд)

time.Sleep(d) приостанавливает текущую горутину на заданный интервал, не блокируя поток ОС. Рантайм помещает горутину в очередь ожидания глобальной кучи таймеров. sysmon или вызов checkTimers в планировщике периодически проверяет таймеры; когда срок истекает, горутина становится готовой и помещается в очередь выполнения. Таким образом, миллионы горутин могут спать практически без нагрузки на систему.

Развёрнутый ответ

Реализация time.Sleep вызывает runtime.timeSleep(ns). В runtime/time.go функция timeSleep создаёт запись timer со временем срабатывания и функцией пробуждения goroutineReady (или goready), которая помещает горутину обратно в runq. Таймер добавляется в min-кучу, связанную с текущим p (локальная куча из 64 таймеров), или в глобальную при переполнении. Горутина паркуется вызовом gopark. Пробуждение: во время планирования (findrunnable) и в sysmon вызывается checkTimers, который находит просроченные таймеры и выполняет их callback (перемещая горутину в очередь). Также sysmon при необходимости просыпается для обработки ближайшего таймера, чтобы обеспечить точность.

Под капотом (internals)

Структура timer в runtime/runtime2.go: when, period, f (функция-колбек, часто goroutineReady), arg (указатель на g), next (связь в списке). Таймеры хранятся в p.timers — массиве [64]timer с индексами и блокировкой p.timersLock. При большом количестве таймеров p может сбросить излишки в глобальную очередь sched.timers, защищённую sched.lock. Проверка на срабатывание происходит в checkTimers, вызываемой из findrunnable, sysmon, а также при GOMAXPROCS изменениях. Для высокой точности, если ближайший таймер скоро должен сработать, sysmon просыпается раньше задержки 20 мкс. Используется futex/select для сигнализации при добавлении быстрого таймера.

Типичные ошибки кандидатов

Полагать, что time.Sleep вызывает нативный nanosleep и блокирует поток.
Это не так: поток не блокируется; горутина паркуется, а поток продолжает выполнять другие горутины. Исправление: говорить о gopark.
Думать, что точность time.Sleep гарантируется до микросекунд.
Гарантируется минимум указанной продолжительности, но реальная длительность может быть дольше из-за планировщика и нагрузки. Таймеры проверяются с периодичностью до нескольких миллисекунд. Исправление: говорить про «minimum sleep duration» и вариативность.
Забывать про таймеры в контексте select с time.After.
time.After создаёт таймер, который после срабатывания отправит значение в канал. Это не time.Sleep, но базируется на том же механизме таймеров. Исправление: объяснить связь через timer.

Возможные дополнительные вопросы интервьюера

Может ли time.Sleep(0) быть оптимизирован?
Да, это вызов gopark без таймера с немедленным пробуждением, используется для переключения контекста (runtime.Gosched).
Как реализован time.After и чем он хуже time.Sleep для некоторых сценариев?
time.After создает канал и таймер; при множественных вызовах без очистки может возникнуть утечка памяти. Лучше использовать time.NewTimer.
Что такое таймерная куча и как она оптимизирует вставку/удаление?
Локальная куча — min-heap из 64 элементов, вставка O(log N), удаление минимума O(1). При переполнении сбрасывается в глобальную очередь, которая тоже heap, но с блокировкой.

Как работает `runtime.LockOSThread` и когда это нужно?

Краткий ответ (30–60 секунд)

runtime.LockOSThread привязывает текущую горутину к текущему потоку ОС (m) до явного вызова runtime.UnlockOSThread. После этого горутина может выполняться только на этом потоке, а поток не может обслуживать другие горутины (кроме системных вызовов). Это необходимо для взаимодействия с низкоуровневыми библиотеками, которые используют thread-local storage (например, графические библиотеки на C), или когда требуется, чтобы горутина не мигрировала между потоками (например, работа с семафорами ОС, signal handling).

Развёрнутый ответ

Механизм: LockOSThread увеличивает счётчик m.locked, устанавливает m.lockedg в текущий g, а g.lockedm указывает на m. Планировщик при попытке запустить этот g на другом m обнаружит lockedm и остановит текущий m, чтобы передать g обратно на привязанный поток. Это гарантирует, что код между LockOSThread и UnlockOSThread выполняется строго на одном потоке. Типичные сценарии:

CGO и TLS: C-код может полагаться на TLS (thread-local storage). Привязка обеспечивает контекст.
Низкоуровневые вызовы ОС: например, изменение маски сигналов через pthread_sigmask (требует стабильного потока).
Собственные примитивы синхронизации: при использовании sync.Cond с Wait на основе futex, где важна идентичность потока (обычно не нужно, но бывает).
Работа с GPU: OpenGL с контекстом, привязанным к потоку.

Если горутина с LockOSThread блокируется в syscall, она может блокировать и поток, но p всё равно может быть передан другому m? Поведение: блокирующий syscall не освобождает привязанный поток, p остаётся при нём? С версии Go 1.14: если горутина с LockOSThread выполняет системный вызов, p отбирается стандартным образом, но m сохраняет привязку к горутине, которая продолжит выполнение на том же m после выхода из syscall. m становится блокированным, но p уходит. Это может создать проблемы, если поток надолго заблокирован в syscall.

Под капотом (internals)

В runtime/proc.go при schedule(), если у следующей горутины lockedm не nil, вызывается функция startlockedm, которая паркует текущий m и пробуждает привязанный m для выполнения. Привязка обеспечивается полями g.lockedm и m.lockedg. LockOSThread реализован как m.locked++ и запись lockedg. При вызове entersyscall для привязанной горутины handoffp всё равно может передать p другому m, оставляя m с lockedg в ожидании. Когда горутина завершается или вызывает UnlockOSThread, счётчик декрементируется; если становится 0, связь разрывается.

Типичные ошибки кандидатов

Считать, что после LockOSThread горутина не может быть вытеснена.
Вытеснение (преемпция) возможно, но горутина продолжит работу только на том же потоке после перепланирования. Исправление: указать, что привязка не запрещает приостановку, а миграцию.
Забывать вызвать UnlockOSThread, что навсегда закрепляет поток и может привести к его утечке или неэффективности.
Если горутина завершится без разблокировки, привязанный m может стать «бесхозным» и остаться в закреплённом состоянии без работы. Исправление: всегда вызывать defer runtime.UnlockOSThread().
Использовать для повышения производительности (закрепление для улучшения кэша CPU).
Это не является документированным паттерном и может привести к снижению параллелизма и блокировкам. Исправление: использовать только при необходимости совместимости с внешним кодом.

Возможные дополнительные вопросы интервьюера

Как LockOSThread влияет на сборку мусора?
Поток, закреплённый за горутиной, может блокировать STW, если горутина долго не достигает safe-point. Это может увеличить паузы GC.
Можно ли создать ситуацию, когда все потоки закреплены и планировщик не может запустить новые горутины?
Да, если все доступные потоки (до maxmcount) закреплены и не освобождаются, программа может зависнуть.
Что случится, если горутина с LockOSThread делает Gosched()?
Она временно уступает процессор, но планировщик должен будет потом выполнить её на том же потоке; пока поток без p, он ждёт. Может снизить утилизацию.

Что такое "runtime finalizer" и как он связан с GC?

Краткий ответ (30–60 секунд)

Runtime finalizer — это функция, ассоциированная с объектом в куче, которая автоматически вызывается сборщиком мусора, когда объект становится недостижимым. Устанавливается через runtime.SetFinalizer(obj, finalizer). Связан с GC непосредственно: финализаторы выполняются в специальной горутине после того, как GC пометил объект как мусор, но перед освобождением памяти. Позволяет выполнить очистку ресурсов (например, закрыть файловые дескрипторы), но не гарантирует своевременность вызова.

Развёрнутый ответ

Механизм: при вызове SetFinalizer объект obj добавляется в специальный список (finq), а не освобождается сразу. Во время завершающей фазы GC (sweep) объекты с финализаторами не освобождаются, а перемещаются в очередь финализаторов. Отдельная горутина bgsweep или systemstack запускает их в отдельной горутине runfinq. Финализатор выполняется однократно для объекта. После выполнения объект теряет финализатор и в следующем цикле GC становится обычным мусором.

Важные оговорки:

Нет гарантии, что финализатор вообще будет вызван (программа может завершиться раньше).
Финализатор может воскресить объект (если записать его в глобальную переменную), тогда GC не освободит его, но финализатор больше не вызовется.
Запрещено устанавливать финализатор на объект, который не выделен в куче, или на nil.
Финализаторы выполняются в отдельной горутине, поэтому там можно безопасно вызывать Go-функции.
Снижают производительность GC, так как откладывают освобождение и добавляют работу.

Под капотом (internals)

runtime/mfinal.go: SetFinalizer проверяет, что объект в куче (использует findObject). Добавляет запись в finblock — связанный список блоков финализаторов. Во время sweep, после mark, sweepone вызывает mspan.sweep, и освобождает только объекты без финализаторов. Объекты с финализаторами перемещаются в глобальную очередь finq. Горутина runfinq (запускается при schedinit или позже) в цикле берет из finq, вызывает финализатор в отдельном g. Она использует setblocks и blockever.

Типичные ошибки кандидатов

Полагать, что финализаторы вызываются немедленно при потере ссылки.
Они вызываются только после того, как GC обнаружит недостижимость, что может произойти спустя неопределённое время. Исправление: говорить «eventually, when GC runs».
Использовать финализатор для критичного освобождения ресурсов (файловые дескрипторы), полагаясь на его своевременность.
Это антипаттерн. Лучше использовать defer и явное закрытие. Исправление: резюмировать «finalizers are not for timely resource cleanup».
Устанавливать финализатор на объект, который сам является частью циклической ссылки.
GC не соберёт объект, так как он может быть признан мусором только при полном обходе. Но финализатор может помешать сборке или привести к утечке, если цикл не разорван. Исправление: избегать финализаторов для изолированных объектов.
Считать, что финализатор выполняется в том же контексте/потоке, что и GC.
Он выполняется в отдельной горутине, после завершения STW. Исправление: определять runfinq.

Возможные дополнительные вопросы интервьюера

Что произойдёт, если финализатор запаникует?
Паника в финализаторе не обрабатывается; она аварийно завершит программу, так как runfinq вызывает финализатор без recover. Рекомендуется осторожное программирование.
Как отменить установленный финализатор?
runtime.SetFinalizer(obj, nil) убирает финализатор.
Можно ли иметь несколько финализаторов на один объект?
Нет, только один; повторный вызов перезапишет предыдущий.

Как работает `recover` и `panic` на уровне runtime?

Краткий ответ (30–60 секунд)

panic останавливает нормальное выполнение горутины, раскручивает стек, выполняя отложенные функции (defer), пока не встретит recover, который перехватывает панику и восстанавливает управление. На уровне рантайма panic создаёт структуру _panic и связывает её с горутиной, модифицирует g.pc для перехода к фреймам defer. recover проверяет наличие активной паники в g и возвращает переданное значение. Если паника не перехвачена, программа завершается с stack trace.

Развёрнутый ответ

Процесс:

panic(value) вызывает runtime.gopanic(value). Создаётся структура _panic с аргументом, указателем на текущий g.panic, и устанавливается в g.panic.
gopanic начинает цикл по всем defer текущей горутины (поля g._defer). Для каждого defer фрейма он устанавливает pc на инструкции после вызова defer, чтобы выполнить отложенную функцию. Отложенная функция выполняется в контексте этого фрейма.
Если отложенная функция вызывает recover(), то runtime.gorecover проверяет, что текущий g.panic не nil и возвращает его аргумент. После успешного recover паника помечается как обработанная (panic.recovered = true), и раскрутка прекращается. Управление переходит к коду после блока defer, который перехватил панику.
Если после выполнения всех defer паника не перехвачена, gopanic вызывает runtime.fatalpanic — выводит стектрейс всех горутин, сообщение паники и вызывает exit(2).

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

Под капотом (internals)

Структура _panic в runtime/runtime2.go: arg interface{}, link *_panic (следующая в цепочке), defer _defer (текущий обрабатываемый defer), recovered bool, aborted bool. gopanic в runtime/panic.go содержит цикл for { ... } с вызовом reflectcall для выполнения defer функции. gorecover просто возвращает p.arg если p != nil && !p.recovered. После восстановления, gopanic устанавливает gp.panic = p.link и продолжает нормальное исполнение. Стектрейс собирается через callers и fpunwind.

Типичные ошибки кандидатов

Считать, что recover можно вызвать из обычной функции, а не из defer.
recover() внутри функции, вызванной напрямую, а не через defer, возвращает nil, потому что на момент выполнения нет активной паники (паника обрабатывается только во время раскрутки отложенных вызовов). Исправление: использовать defer func() { if r := recover(); r != nil { ... } }().
Думать, что паника одной горутины может быть перехвачена в другой.
Каждая горутина имеет собственный стек и цепочку _panic. Паника не передаётся между горутинами; если горутина паникует, умирает только она (но если это main-горутина — программа завершается). Исправление: подчеркнуть локальность паники.
Полагать, что recover может отменить любую панику.
Некоторые паники (например, runtime: concurrent map writes) невозможно перехватить, так как они происходят в стадии, когда рантайм считает состояние невосстановимым. Исправление: различать «ordinary panic» и «fatal runtime error».
Игнорировать, что defer с recover добавляет накладные расходы.
Каждый defer создаёт структуру и влияет на производительность; использование в горячих циклах может быть нежелательным.

Возможные дополнительные вопросы интервьюера

Что будет, если внутри recover снова случится паника?
Новая паника свяжется в цепочку, и её обработка приостановит предыдущую. Если вторая паника не перехвачена, программа завершится, но первая останется необработанной.
Можно ли вернуть управление после recover и продолжить нормальную работу?
Да, управление переходит к инструкциям после defer, который перехватил панику. Состояние горутины сохраняется, можно продолжать.
Как работает panic с nil аргументом?
panic(nil) порождает панику, recover вернёт nil. Но recover возвращает nil и при отсутствии паники, поэтому для проверки лучше использовать if p := recover(); p != nil.

Как устроен `channel` и его буфер в памяти (структура `hchan`)?

Краткий ответ (30–60 секунд)

Канал в Go — это указатель на структуру hchan, размещаемую в куче. Она содержит мьютекс, кольцевой буфер для хранения элементов (если канал буферизованный), два указателя на списки ожидающих горутин (sendq и recvq), количество элементов, размер элемента, флаги. Операции send/receive синхронизируются через мьютекс и прямую передачу данных между горутинами: при совпадении готовых отправителя и получателя копирование происходит напрямую, без буфера. Буфер — это просто непрерывный участок памяти, организованный как очередь FIFO с индексами sendx и recvx.

Развёрнутый ответ

Поле make(chan T, size) вызывает runtime.makechan, который аллоцирует hchan и буфер size * sizeof(T). Поля (runtime/chan.go):

qcount — текущая заполненность буфера.
dataqsiz — ёмкость буфера.
buf — указатель на начало массива буфера (размер = dataqsiz * elemtype.size).
elemsize, elemtype — размер и тип элемента.
sendx, recvx — индексы вставки и извлечения.
recvq, sendq — waitq (связные списки горутин, ожидающих операции).
lock — mutex для защиты всех полей.

Алгоритм отправки (chansend):

Блокировка lock.
Если есть ожидающий получатель в recvq, извлечь его и скопировать данные напрямую в стек ожидающего получателя (или в буфер, если он есть), минуя буфер, затем разблокировать.
Иначе, если буфер не заполнен, поместить элемент в buf[tx], увеличить sendx, счётчик.
Если буфер заполнен, горутина паркуется в sendq и отпускает мьютекс. Позже, при получении, получатель скопирует данные и разбудит отправителя.
Для получения (chanrecv) — симметрично. Закрытие канала (closechan) устанавливает флаг closed, пробуждает все ожидающие горутины с нулевым значением.

Буфер обеспечивает порядок FIFO; при передаче от отправителя к получателю напрямую FIFO сохраняется благодаря тому, что получатели ожидают в recvq в порядке поступления.

Под капотом (internals)

hchan выделяется через mallocgc (куча). Буфер — отдельный кусок памяти, выделенный при создании канала. Операции синхронизируются с помощью lock — на самом деле это mutex (структура рантаймовая, не путать с sync.Mutex), который реализован на основе futex или pthread с оптимальным spinning + parking. sendq/recvq связные списки waitq, состоящие из sudog — структуры, которая представляет горутину в очереди ожидания. sudog содержит ссылку на g, элемент для передачи, буфер, индекс. При прямой передаче send копирует значение напрямую в стек получателя (через memmove), избегая буфера.

Типичные ошибки кандидатов

Считать, что буферные каналы хранят данные как связный список.
Это непрерывный кольцевой буфер, что обеспечивает O(1) вставку/извлечение и хорошую локальность кэша. Исправление: упомянуть кольцевой массив.
Полагать, что закрытый канал немедленно освобождает буфер.
Буфер остаётся, пока существуют ссылки на канал. Получатели могут дочитывать оставшиеся элементы. Освобождается GC только после потери всех ссылок. Исправление: указать на жизненный цикл hchan.
Игнорировать возможность прямой передачи данных при совпадении ожиданий.
Многие думают, что данные всегда проходят через буфер. На самом деле, если есть ждущий получатель, отправитель копирует данные прямо в его стек, минуя буфер, что ускоряет обмен. Исправление: рассказать про bypass.
Забывать, что recvq и sendq могут приводить к утечке горутин, если канал не закрыт и никто не отправляет/получает.
Неправильное управление жизненным циклом приводит к зависанию и утечке горутин. Исправление: сознавать последствия.

Возможные дополнительные вопросы интервьюера

Какова структура sudog и почему она важна?
sudog представляет горутину в очереди ожидания канала, содержит указатель на g, передаваемый элемент, индексы, и позволяет реализовать эффективную прямую передачу данных без промежуточных копирований.
Почему нельзя сравнить два канала через ==?
Каналы сравнимы, но операторы == и != проверяют равенство указателей hchan, т.е. это один и тот же канал. Запретов на сравнение нет, но это редко полезно.
Что такое «channel race» при одновременном close и send?
Паника «send on closed channel». Обрабатывается проверкой флага closed под мьютексом.

Как работает `select` на уровне runtime?

Краткий ответ (30–60 секунд)

select преобразуется компилятором в вызов runtime.selectgo с массивом дескрипторов всех case. Эта функция блокирует горутину, регистрируя её в очередях ожидания всех каналов, указанных в select. При готовности любого из каналов горутина пробуждается, обрабатывает соответствующую ветку, деинициализирует регистрацию на остальных каналах и возвращает индекс победившего case. При наличии нескольких готовых случаев выбор псевдослучаен. Если есть default, и ни один канал не готов, selectgo сразу возвращает индекс default.

Развёрнутый ответ

Структура runtime.scase описывает каждый case: канал c, тип операции (send/recv) и указатель на значение. Общий алгоритм selectgo:

Фаза опроса (poll): сначала быстро проверяется готовность без блокировки: для каждого case, если операция может быть выполнена немедленно (получение из непустого канала, отправка в незаполненный буфер, или есть ожидающий партнёр), то выполняется выбранная ветка (если несколько готовых, случайный выбор).
Фаза регистрации: если немедленно не получилось, горутина создаёт sudog для каждого case, привязывается ко всем очередям ожидания каналов (sendq/recvq) с атомарным состоянием.
Парковка: горутина вызывает gopark с колбеком selparkcommit, который финально активирует ожидание.
Пробуждение: когда один из каналов становится готов, его рантайм-функция (chansend/chanrecv) обнаруживает sudog с флагом select и пробуждает горутину через goready.
Завершение: горутина удаляет свои sudog из всех каналов (dequeue), чтобы не осталось dangling указателей; определяет индекс победившего case и возвращает его. Для остальных case возможные данные копируются корректно.

Случайность выбора достигается с помощью fastrandn.

Под капотом (internals)

Реализация в runtime/select.go. selectgo имеет сигнатуру func selectgo(cas0 *scase, order0 *uint16, ncases int) (int, bool). Второй параметр — массив порядка опроса для fairness. Функция выполняет три цикла: sellock (блокировка всех каналов), selunlock (разблокировка), и selparkcommit. Для обработки готовых case на этапе poll используется selectnbrecv/selectnbsend — неблокирующие варианты. При dequeue для каждого канала вызывается dequeueSudoG. При реализации send/recv в chansend/chanrecv, если обнаруживается sudog с isSelect==true, пробуждение идёт через g.selectDone и g.param.

Типичные ошибки кандидатов

Полагать, что select проверяет case в порядке исходного кода.
Порядок опроса случаен для справедливости. Компилятор генерирует случайную перестановку. Исправление: помнить о fastrandn и order.
Думать, что default case гарантирует мгновенную обработку без затрат.
Если есть default, рантайм только делает poll, но всё равно захватывает блокировки каналов для проверки. При большом количестве case это не бесплатно. Исправление: указывать, что poll требует блокировок.
Игнорировать, что select с одним case и default — это неблокирующая операция, которая может проверять готовность канала.
Часто используют для «try-send/receive», но нужно быть аккуратным с гонками. Исправление: рекомендовать select { case ch <- x: default: }.
Забывать, что select может вызвать пробуждение нескольких горутин одновременно при закрытии канала.
При close канала все ожидающие sudog в recvq/sendq с select пробуждаются, и каждый select затем обрабатывает завершение. Исправление: знать о деактивации.

Возможные дополнительные вопросы интервьюера

Как select обрабатывает закрытые каналы?
Закрытый канал на чтение немедленно готов (возвращает zero value, ok=false), на запись приводит к panic. Эти проверки встроены в poll.
Что такое sudog.isSelect и как он помогает?
Флаг указывает, что sudog участвует в select. При извлечении из очереди рантайм понимает, что нужно уведомить selectgo через g.selectDone.
Может ли select привести к дедлоку, если все каналы nil?
select{} на nil-каналах навсегда заблокирует горутину, если нет default. Это допустимо, как способ блокировки.

Что такое "work stealing" в планировщике?

Краткий ответ (30–60 секунд)

Work stealing — это стратегия балансировки нагрузки, при которой свободный логический процессор (p) ищет работу в локальных очередях других занятых p. В Go, когда p исчерпывает свою локальную очередь, он случайно выбирает другого p и «крадёт» половину его горутин из хвоста кольцевого буфера. Это обеспечивает равномерную загрузку CPU без централизованной диспетчеризации и минимизирует contention.

Развёрнутый ответ

В многопоточной системе с локальными очередями неизбежно возникает дисбаланс. Work stealing решает это децентрализованно: каждый p, становясь idle, вызывает findrunnable(), которая после безуспешной проверки своей очереди, глобальной очереди и netpoller пытается украсть работу. Функция stealWork() в runtime/proc.go проходит по всем p в случайном порядке (начиная со случайного индекса) и для каждого p с непустой локальной очередью вызывает runqsteal(p, stealRunNextG). runqsteal забирает половину элементов с хвоста очереди (используя атомарные операции для синхронизации), оставляя владельцу оставшиеся. Таким образом вор и владелец работают на разных концах, минимизируя contention. После успешного воровства вор запускает первую украденную горутину. Если ни у кого не удалось украсть, m переводится в режим ожидания.

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

Под капотом (internals)

runqsteal (в runtime/proc.go) копирует элементы из p2.runqtail с использованием цикла for i := 0; i < steal; i++, обновляет хвост через atomic.Store. Для защиты от гонок владелец может читать голову без атомарных операций, но при краже используется упорядочивание памяти. runqgrab захватывает горутины с хвоста атомарно, используя atomic.Cas на runqtail. Размер очереди 256, воруем половину (но не более len(p2.runq)/2). Если stealRunNextG==true, вместо половины вор пробует украсть runnext (одна горутина для экстренных случаев). Также в findrunnable после безуспешного воровства m может перейти в «spinning» состояние перед полной парковкой.

Типичные ошибки кандидатов

Путать work stealing с работой с глобальной очередью.
Work stealing — это кража из локальных очередей. Глобальная очередь — отдельный механизм. Исправление: чётко разделять.
Считать, что кража происходит каждый раз при поиске работы.
Сначала проверяются локальная очередь, глобальная, netpoller, и только потом — воровство. Исправление: описать полный порядок в findrunnable.
Полагать, что вор забирает все горутины.
Забирается до половины, чтобы сохранить работу у владельца и не вызвать миграцию всех горутин. Исправление: назвать долю 1/2.
Забывать о runnext как оптимизации.
runnext содержит горутину, которая будет запущена следующей на этом p, и если её украдут, это может нарушить паттерн «вызов-ответ». Поэтому существует отдельный режим для кражи runnext. Исправление: упомянуть stealRunNextG.

Возможные дополнительные вопросы интервьюера

Как гарантируется, что горутина не потеряется во время кражи?
Атомарные операции над хвостом гарантируют, что владелец и вор видят консистентное состояние. Владелец всегда читает голову без атомика, но хвост обновляется атомарно, создавая неотъемлемый регион.
Влияет ли work stealing на latency для UI-потоков?
Может, так как горутины, вытесненные с одного ядра на другое, теряют кэш, но в целом это улучшает среднюю утилизацию. При необходимости можно закрепить горутину за p (через LockOSThread не совсем то), но специального API нет.
Что будет, если все горутины находятся в локальных очередях, а глобальная пуста, и все p заняты?
Планировщик не будет воровать, так как нет idle p. Только когда p освобождается, запускается findrunnable → work stealing.

Как происходит переключение контекста между горутинами?

Краткий ответ (30–60 секунд)

Переключение контекста инициируется планировщиком: текущая горутина сохраняет свой контекст (PC, SP, g) в структуру g.sched и вызывает mcall для перехода на стек планировщика g0. Планировщик выбирает новую горутину, восстанавливает её контекст из g.sched через ассемблерную функцию gogo и возобновляет её исполнение. Это легковесная операция без участия ядра, затрагивающая лишь несколько регистров, что делает её значительно быстрее переключения потоков ОС.

Развёрнутый ответ

Точки переключения:

Вызов runtime.Gosched() или gopark(), блокировка на канале, таймере, преемпция.
Для добровольной передачи: runtime.mcall(fn), где fn — функция на системном стеке, например park_m или gosched_m. mcall сохраняет текущие регистры в g.sched, переключается на g0 стек и вызывает fn.
fn (например, schedule) работает на g0 и решает, какую горутину запустить следующей. Выбранная горутина загружается через gogo(&gp.sched). gogo восстанавливает SP, PC, BP и др., выполняет JMP на сохранённый PC.

При асинхронной преемпции sysmon посылает сигнал SIGURG, обработчик asyncPreempt сохраняет полный контекст (включая XMM регистры) в g.sigcontext, выставляет флаг preempt, и затем при возврате из сигнала, если флаг установлен, вызывает mcall(gopreempt_m) для перехода к планировщику.

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

Под капотом (internals)

Ассемблерная функция runtime.mcall (в asm_amd64.s): сохраняет текущий pc и sp в g.sched, загружает g0 стек в SP и вызывает аргумент-функцию. gogo делает обратное: MOVQ gobuf_sp(BX), SP, MOVQ gobuf_pc(BX), BX, JMP BX, предварительно восстановив g. Контекст включает также g, LR (для ARM) и CTXT для передачи аргументов. g.sched — структура gobuf с полями sp, pc, g, ctxt, lr. Переключение на новый g также обновляет m.curg и TLS.

Типичные ошибки кандидатов

Полагать, что переключение контекста сохраняет все регистры.
Сохраняются только те, которые использует Go ABI (callee-saved). Однако при асинхронной преемпции сохраняются почти все регистры (caller-saved) из-за сигнала. Исправление: различать добровольное и вынужденное переключение.
Считать, что планировщик выбирает горутину из глобального списка всегда.
Выбор сложный: несколько уровней очередей с приоритетами. Исправление: рассказать про runq, runnext, глобальную очередь.
Думать, что g0 — это особая горутина, которая тоже может быть запланирована.
g0 — это горутина планировщика с системным стеком, она не участвует в обычной очереди и не видна пользователю. Исправление: разъяснить роль g0 у каждого m.
Утверждать, что переключение происходит только при вызове функций.
До Go 1.14 да, с кооперативной преемпцией. После добавилась асинхронная преемпция в any safe-point. Исправление: уточнить про async preemption.

Возможные дополнительные вопросы интервьюера

Сколько примерно времени занимает переключение контекста горутин?
Порядка десятков наносекунд (сохранение/восстановление нескольких регистров, пара инструкций). Для сравнения, переключение потоков ОС — микросекунды.
Что такое gobuf и почему в нём нет всех регистров?
Добровольное переключение сохраняет только callee-saved регистры (PC, SP, BP, g). Остальные не нужны, потому что вызывающий код уже сохранил или не использует.
Может ли переключение контекста произойти в середине записи в канал?
Да, но канал защищён мьютексом и не пострадает; горутина заблокируется с удержанием мьютекса? Нет, рантайм освобождает мьютекс перед парковкой.

Как устроены `timers` и `ticker`?

Краткий ответ (30–60 секунд)

Таймеры в Go — это структуры runtime.timer, содержащие время срабатывания, интервал повторения и callback-функцию. Они хранятся в мини-куче на каждом p (до 64 таймеров) и в глобальной куче. time.NewTimer создаёт таймер, который после истечения отправляет значение в канал (или будит горутину). Ticker аналогичен, но период автоматически переустанавливается после каждого срабатывания. Проверка и обработка просроченных таймеров происходит в checkTimers во время планирования и в sysmon.

Развёрнутый ответ

Пользовательский API: time.NewTimer(d), time.NewTicker(d). Внутри вызывают runtime.addtimer(timer). Структура timer содержит:

when — абсолютное время срабатывания в наносекундах (монотонные часы).
period — интервал между срабатываниями для ticker (положительный).
f — функция-колбек, обычно sendTime для канала таймера или goroutineReady для time.Sleep.
arg — указатель на канал или g.

Каждый p имеет массив timers из 64 элементов, организованный как мин-куча (p.timer0When и p.timer0Heap). При добавлении таймера, если локальная куча переполнена, таймеры мигрируют в глобальную очередь sched.timers (защищена sched.lock). Проверка (checkTimers) вызывается при входе в планировщик (findrunnable), в sysmon и при изменении GOMAXPROCS. Она извлекает таймеры с when <= now, вызывает их колбек, и если period > 0, переустанавливает when += period и добавляет обратно. Таким образом, ticker генерирует периодические события.

Под капотом (internals)

runtime/time.go: addtimer, deltimer, modtimer, cleantimers, checkTimers. timer аллоцируется из кучи (обычно через new(timer) в пользовательском коде, но реализация перемещает в управляемый рантаймом участок? На самом деле time.NewTimer выделяет runtimeTimer, который оборачивает runtime.timer). Ticker реализован как runtimeTimer с периодическим колбеком tickerFunc, который каждый раз отправляет значение в канал, но не блокируется, если канал не готов — значение может потеряться (с версии Go 1.23 будет изменено поведение). На уровне рантайма период обрабатывается в checkTimers: после вызова f, если period > 0, when += period, и таймер перевставляется в кучу. Глобальная очередь — тоже куча; синхронизация через sched.lock.

Типичные ошибки кандидатов

Полагать, что time.Ticker гарантирует доставку каждого тика, даже если получатель медленный.
Начиная с Go 1.23, если канал ticker'а не читается, тики накапливаются в буфере? Буфера нет; если канал не готов, ticker может пропускать тики, чтобы не блокировать рантайм. Исправление: документировать поведение.
Думать, что таймеры GC собираются автоматически, даже если на них есть ссылки.
Timer содержит канал, который может удерживать GC. Если не вызвать Stop, ресурсы не освободятся до истечения. Исправление: всегда останавливать таймеры.
Забывать очищать канал после Stop у time.After для предотвращения утечек.
time.After создаёт таймер и канал. Если горутина выходит из select по другому case, таймер не будет остановлен, и его канал останется в памяти. Исправление: избегать time.After в циклах.
Считать, что таймеры используют один глобальный список.
Используется распределённая система: локальные кучи для снижения contention. Исправление: описать архитектуру.

Возможные дополнительные вопросы интервьюера

Как реализовать Reset таймера безопасно?
Необходимо гарантировать, что таймер не сработал до Reset, иначе чтение из канала может перемешать старые события. Правильный паттерн: if !t.Stop() { select { case <-t.C: default: } } t.Reset(d).
Почему таймеры не используют time.AfterFunc для периодических задач?
AfterFunc не удобен для периодичности; ticker спроектирован специально и управляется эффективнее.
Что происходит с таймером при изменении системного времени?
Используются монотонные часы, поэтому изменения системных часов не влияют на тайм-ауты.

Как runtime обрабатывает блокирующие системные вызовы в горутине?

Краткий ответ (30–60 секунд)

Когда горутина выполняет блокирующий системный вызов, рантайм заранее вызывает entersyscall, помечая p в состояние _Psyscall. Если syscall затягивается (более 20 мкс), sysmon отбирает p и передаёт его другому m, чтобы процессор не простаивал. После возврата из syscall горутина вызывает exitsyscall, пытаясь вернуть свой старый p или найти любой свободный. Если это не удаётся, горутина паркуется до появления доступного p.

Развёрнутый ответ

Последовательность:

Перед входом в syscall (например, syscall.Read) вызывается runtime.entersyscall(). Она блокирует GC для текущего g, сохраняет указатель на p, устанавливает p.status = _Psyscall, снимает связь m.p? Нет, связь остаётся, но p помечается как занятый syscall'ом.
Выполняется инструкция SYSCALL, горутина блокируется в ядре.
В это время sysmon может обнаружить, что p в _Psyscall более forcePreemptNS (20 мкс), и вызвать handoffp(p). Это разрывает связь m и p, p передаётся другому m или помещается в idle-пул. Поток m продолжает висеть в syscall'е без p.
Когда syscall завершается, управление возвращается к инструкции после SYSCALL. Вызывается runtime.exitsyscall(). Она проверяет состояние старого p:
- Если p всё ещё принадлежит этому m и в _Psyscall, быстро восстанавливается _Prunning.
- Если p украден, exitsyscall пытается захватить любой свободный p (pidleget). В случае успеха m продолжает выполнение горутины.
- Если свободного p нет, горутина помещается в глобальную очередь и вызывает mcall(gopark...), чтобы парковать m, пока не появится p.

Это позволяет избежать простоя CPU из-за блокирующих syscall’ов, но может привести к миграции горутин и потере кэша.

Под капотом (internals)

entersyscall (runtime/proc.go) вызывает reentersyscall на системном стеке, которая сохраняет pc и sp для профилирования, блокирует g для GC. exitsyscall пробует быстрый путь: сравнивает p и статус, затем вызывает exitsyscallfast; если не выходит — exitsyscall0, где горутина ставится в очередь и паркуется. handoffp выполняет startm(p) для поиска нового m или помещает p в idle. Механизм таймаута 20 мкс — константа forcePreemptNS. В Linux syscall обёртки живут в sys_linux_*.s, вызывая runtime·entersyscall и runtime·exitsyscall.

Типичные ошибки кандидатов

Полагать, что блокирующий вызов немедленно освобождает p.
Между моментом входа в syscall и передачей p существует задержка ~20 мкс. Исправление: упомянуть forcePreemptNS.
Думать, что p возвращается той же горутине гарантированно.
В большинстве случаев старый p теряется. Горутина потом работает на другом p, что разрушает локальность. Исправление: описать сценарий кражи.
Игнорировать увеличение задержки GC из-за entersyscall.
entersyscall блокирует g, из-за чего GC не может сканировать стек горутины, пока она в syscall'е. Если syscall долгий, это может отсрочить GC. Исправление: упомянуть влияние на GC.
Забывать, что при установленном LockOSThread поведение отличается.
С LockOSThread m не отдаст p другим горутинам, даже если p украден; но p всё равно может быть передан? Несовместимость: если горутина закреплена, она будет выполняться только на этом потоке, и handoffp всё равно отберёт p. Комбинация хитрая. Исправление: быть осторожным с утверждениями.

Возможные дополнительные вопросы интервьюера

Как рантайм определяет, что syscall завершился, если поток блокирован?
Не определяет; он просто ждёт возврата из syscall. Поток выходит из блокировки самостоятельно по завершению вызова.
Можно ли повлиять на таймаут 20 мкс перед handoff?
Нет, это константа в исходниках рантайма, не конфигурируется.
Что будет, если все p заняты и приходит много блокирующих syscall'ов?
Создаются дополнительные m (до maxmcount), которые после syscall могут искать p. Если свободных p нет, горутины ждут в глобальной очереди.

Как работает `fork`/`exec` в Go с учетом горутин?

Краткий ответ (30–60 секунд)

os/exec (и syscall.ForkExec) для запуска внешнего процесса вызывает fork (через системный вызов) и exec в дочернем процессе. Поскольку Go многопоточен и использует горутины, прямой вызов fork в многопоточном процессе опасен: после fork дочерний процесс наследует только один поток, но состояние блокировок и дескрипторов может быть испорчено. Go решает это, используя clone(CLONE_VFORK|CLONE_VM) или fork с последующими манипуляциями, но на практике стандартная библиотека обходит проблему через запуск отдельного процесса-посредника или использование clone с осторожными подготовками. Внутри os.StartProcess на Linux применяется forkLock и специальный порядок действий для безопасного fork/exec.

Развёрнутый ответ

Проблема: стандартный POSIX fork() в многопоточном процессе копирует адресное пространство, но только вызывающий поток становится активным. Другие потоки становятся мёртвыми в копии, что может оставить мьютексы в заблокированном состоянии, нарушить состояние аллокаторов и т.д. Go-рантайм многопоточен, поэтому fork небезопасен. Решение в Go (пакет syscall и os/exec):

Перед fork захватывается syscall.ForkLock (взаимный исключитель), чтобы гарантировать, что никакие другие потоки не входят в критические секции.
Выполняется rawClone с флагами CLONE_VFORK и CLONE_VM (на Linux), что не копирует всё адресное пространство, а приостанавливает родительский процесс до exec. Это уменьшает риск.
В дочернем процессе сразу после fork вызывается exec, завершая опасную фазу. До exec нельзя выделять память, вызывать Go-функции.
Если нужно выполнить код между fork и exec (например, dup2 stdin), используются только async-signal-safe функции, никакие горутины не работают. Для этого в syscall.ForkExec есть колбек syscall.SysProcAttr.Fork, который выполняется в дочернем процессе.

Под капотом (internals)

В runtime/sys_linux_amd64.s: runtime·fork реализует низкоуровневый clone с минимальными операциями. syscall.ForkLock в syscall/exec_unix.go — это sync.RWMutex. В syscall.forkExec захватывается ForkLock.Lock(); затем вызывается rawVforkSyscall или clone. После clone дочерний процесс возвращает 0, вызывает переданную fork функцию, затем exec. Родительский процесс освобождает ForkLock. В Windows используется CreateProcess, проблем с горутинами нет.

Типичные ошибки кандидатов

Считать, что Go может безопасно вызывать fork без подготовки.
Использование syscall.Fork напрямую без ForkLock и понимания ограничений может привести к дедлокам. Исправление: использовать os/exec или syscall.ForkExec.
Полагать, что после fork в дочернем процессе можно запускать горутины.
Дочерний процесс наследует память, но рантайм не инициализирован для многопоточности, и все m, кроме текущего, мёртвы. Любое использование горутин приведёт к краху. Исправление: до exec не выполнять Go-код.
Игнорировать необходимость закрытия лишних дескрипторов.
Go os/exec автоматически закрывает fds, помеченные как CloseOnExec, но не все. Исправление: вручную управлять через атрибуты SysProcAttr.Files.

Возможные дополнительные вопросы интервьюера

Почему syscall.ForkLock — это RWMutex и как он используется?
RWMutex позволяет множественные read-блокировки для обычной работы с дескрипторами, но fork ожидает эксклюзивную запись, чтобы никто не находился в критической секции.
Что будет, если в дочернем процессе вызвать panic между fork и exec?
Это приведёт к выводу сообщения в stderr, но корректного stack trace не будет, так как рантайм не готов. Лучше избегать.
Чем clone с CLONE_VFORK отличается от fork?
Родитель приостанавливается до тех пор, пока дочерний не вызовет exec или _exit. Это гарантирует, что родитель не будет менять память, пока дочерний копирует. Полезно для безопасности.

Что такое "spinning thread" и зачем он нужен?

Краткий ответ (30–60 секунд)

Spinning thread (крутящийся поток) — это поток m, который после неудачного поиска работы не сразу уходит в сон, а активно опрашивает очереди в течение короткого времени, ожидая, что работа вот-вот появится. Это уменьшает задержки пробуждения. В Go планировщик допускает до maxSpinning (4) таких потоков одновременно. Они проверяют netpoller, локальные и глобальную очереди, work stealing, не паркуясь. Если работа не появляется, поток паркуется.

Развёрнутый ответ

При переходе в idle поток выполняет findrunnable(). Если после всех проверок работа не найдена, он решает, уйти в сон или покрутиться. Решение основано на:

Количество текущих spinning потоков < maxSpinning (константа 4).
Наличие хотя бы одного занятого p (чтобы было у кого воровать).
Тогда m помечается как spinning (m.spinning = true), и в цикле (с подсчётом квантов) пытается найти работу: снова вызывает checkRunq, netpoll, work stealing. Spinning потоки не паркуются, потребляя CPU, но могут быстро подхватить новую горутину или украсть работу. Если за несколько итераций работа не появляется, spinning сбрасывается, и поток паркуется в список idle m.

Эта техника заимствована из планировщиков ядра Linux и потоковых библиотек. Она сокращает latency при бурстах активности.

Под капотом (internals)

В runtime/proc.go findrunnable(), после основного поиска, если результат nil, вызывается stopm(), но перед этим проверяется возможность spinning: если spinning < maxspinning и есть готовые p, m устанавливает m.spinning = true, nspinning++, и продолжает в цикле for waitReasonSpinning. В этом цикле периодически вызывается osyield для отдачи CPU. stealWork вызывается с флагом stealRunNextG = true для более агрессивной кражи. Выход из spinning происходит, если находится работа, или если вращение слишком долгое (по таймауту? На самом деле несколько итераций и уход в stopm). Spinning потоки учитываются в sched.nmspinning.

Типичные ошибки кандидатов

Считать, что spinning потоки всегда полезны и не потребляют ресурсы.
Они сжигают CPU и могут снижать производительность, если их слишком много. Ограничение maxSpinning=4 предотвращает чрезмерное потребление. Исправление: объяснять компромисс между latency и wasted CPU.
Путать spinning с ожиданием в select{} или busy-wait в коде.
Это внутренний механизм планировщика, не контролируемый пользователем. Исправление: различать уровни абстракции.
Думать, что spinning отключается при малом количестве ядер.
Ограничение применяется всегда, но на одноядерной системе spinning может быть менее выгоден; однако рантайм не адаптирует maxSpinning, кроме фиксированного числа.
Полагать, что потоки всегда сначала spinning, а потом паркуются.
Только при условии, что есть занятые p и разрешённый лимит spinning. В противном случае сразу паркуются.

Возможные дополнительные вопросы интервьюера

Как spinning влияет на энергопотребление?
Увеличивает энергопотребление на малозагруженных системах. В мобильных и встроенных сценариях это может быть недостатком.
Может ли spinning привести к голоданию потоков?
Нет, потому что spinning потоки быстро уходят в сон, если работа не появляется; они не захватывают работу навсегда.
Как osyield используется в spinning цикле?
osyield (sched_yield) временно отдаёт процессор, чтобы другие потоки могли поработать, включая потенциального производителя работы.

Что происходит с горутиной, когда она делает `ioutil.ReadFile`?

Краткий ответ (30–60 секунд)

ioutil.ReadFile (теперь os.ReadFile) открывает файл, считывает данные через os.File.Read, который в конечном счёте вызывает системный вызов read (или pread) на файловом дескрипторе. Поскольку диск I/O может быть блокирующим, а netpoller для обычных файлов не используется, рантайм вынужден выполнять блокирующий read в горутине, но чтобы не блокировать весь поток ОС, он создаёт отдельный поток (через entersyscallblock механизм). Горутина временно переходит в состояние ожидания, а её p передаётся другому m. После завершения чтения горутина получает p обратно и продолжает выполнение.

Развёрнутый ответ

В Go операции с обычными файлами (не сокетами) не интегрированы в netpoller из-за того, что poll/epoll на дисковых файлах всегда возвращают готовность, но реальный read может блокироваться в ядре. Поэтому пакет os на *nix использует блокирующие системные вызовы. Внутренняя реализация os.File.Read вызывает syscall.Read, который через entersyscall/exitsyscall (или entersyscallblock) переведёт горутину в блокирующий режим. С версии Go 1.11 существует механизм blocking poll — netpolllock? На самом деле os.File использует syscall.Read с syscall.Syscall. Для дисковых файлов fd.Read в рантайме может создавать специальный поток через entersyscallblock, если операция может быть долгой. syscall.Read обёрнут так: entersyscall, затем rawSyscall6(SYS_read), затем exitsyscall. Если read блокируется, поток входит в ядро, sysmon отбирает p, и горутина перепланируется позже. Но из-за отсутствия netpoller рантайм не узнает о завершении до возврата из syscall'а, поэтому поток будет ждать в ядре. Это может исчерпать лимит потоков (maxmcount), если много одновременных файловых операций. На практике Go ограничивает число одновременных блокирующих файловых операций через пул потоков? Нет, он полагается на то, что ОС сама планирует I/O, а рантайм создаёт дополнительные потоки при необходимости, но может упереться в maxmcount (10000).

Под капотом (internals)

В runtime/sys_linux_amd64.s: syscall.Read вызывает runtime.entersyscall, SYSCALL, runtime.exitsyscall. Для файлов без O_NONBLOCK вызов будет блокироваться в ядре. Рантайм не может избежать этого, но уменьшает вред: entersyscall помечает p как _Psyscall, и sysmon через 20 мкс передаст p другому m. Поток остаётся в ядре до завершения I/O. Когда чтение завершается, exitsyscall ищет p для продолжения.

Для уменьшения проблемы в больших файловых серверах рекомендуется использовать AIO или memory-mapped files, но стандартная библиотека пока этого не предоставляет. Также можно использовать os.File.Read в горутине, осознавая ограничения.

Типичные ошибки кандидатов

Считать, что os.ReadFile использует netpoller и не блокирует поток ОС.
Он блокирует поток в ядре на время дискового I/O. Исправление: чётко говорить о блокирующих системных вызовах для файлов.
Полагать, что горутина при этом не блокирует планировщик.
Планировщик теряет p, но может передать его другому потоку, а текущий поток блокирован. Исправление: объяснять handoff p.
Игнорировать риск превышения maxmcount при тысячах параллельных чтений файлов.
Каждый блокирующий read может занять поток ОС, и если заблокировано много потоков, новые операции не смогут создать потоки, что приведёт к панике. Исправление: упомянуть лимит maxmcount.

Возможные дополнительные вопросы интервьюера

Как Go обрабатывает запись в файл, асинхронно ли?
Аналогично чтению — блокирующий syscall write, если файл не сокет.
Есть ли планы интегрировать io_uring для асинхронного файлового I/O?
Обсуждается в community (issue #31908), но в стандартной библиотеке пока нет.
Как избежать блокировки потока при файловом I/O?
Использовать mmap, пакет golang.org/x/sys/unix с AIO или внешние библиотеки, либо вынести файловый I/O в отдельный пул горутин с контролируемым количеством.

Как runtime собирает и выводит стектрейс при панике?

Краткий ответ (30–60 секунд)

При необработанной панике рантайм вызывает runtime.fatalpanic, которая печатает сообщение паники и стектрейс всех горутин в stderr. Стектрейс собирается путём обхода стека текущей горутины с использованием call frame info (pc, sp, fp), сохранённого в стеке, и таблиц символов (symtab). Рантайм использует функции callers и traceback для обхода стека, определяя имена функций и файлов через FuncForPC. Для других горутин стек сканируется принудительно, что может требовать остановки их выполнения (не всегда). Вывод форматируется с указанием номера горутины, состояния и стека.

Развёрнутый ответ

Процесс (на примере паники):

gopanic вызывает fatalpanic после раскрутки всех defer без recover.
fatalpanic печатает "panic: " и аргумент, затем вызывает printpanics для цепочки паник.
Затем вызывается printallgs (если GOTRACEBACK не "none") или traceback для текущей g.
traceback (в runtime/traceback.go) обходит стек, начиная с текущего frame. Для каждого frame определяется PC, ищется функция в findfunc(pc), получается структура funcInfo (из модуля данных), печатается имя функции, файл и номер строки. Обход продолжается, пока не достигнут верхний frame (runtime.goexit).
Для вывода стектрейсов всех горутин printallgs проходит по списку всех горутин (allgs), для каждой, если возможно, захватывает её контекст (через сигналы или ожидание safe-point) и вызывает traceback с сохранённым sched или syscallpc.

Формат: имя горутины, состояние (running, waiting, etc.), стек от верхнего к нижнему или наоборот, в зависимости от глубины. Используются данные из .debug_info/.gopclntab (таблица функций и строк).

Под капотом (internals)

runtime/traceback.go: printtrace, traceback, tracebacktrap, traceback1. traceback использует gentraceback с флагами. gentraceback проходит через stkbar (барьеры стека) и использует frame.pc, frame.sp, frame.fp, сохранённые в стеке согласно ABI. Данные пакетов хранятся в секциях, создаваемых компилятором (runtime.functab, runtime.pclntab). При отсутствии точной информации (например, CGO-фрейм) могут быть пропуски. tracebackothers посылает сигнал SIGPROF или SIGUSR1 для принудительного получения контекста у других m.

Типичные ошибки кандидатов

Считать, что стектрейс выводится только для текущей горутины.
При GOTRACEBACK=all выводятся все горутины. По умолчанию (crash) выводится несколько. Исправление: знать о переменной окружения и debug.SetTraceback.
Думать, что стектрейс всегда точно показывает состояние горутины.
Для работающих горутин может быть показан последний сохранённый PC (при преемпции), что может не отражать реальное место. Исправление: понимать «прерванную» семантику.
Полагать, что все фреймы выводятся всегда.
При оптимизации inline’а функции, встроенные фреймы могут быть пропущены или упрощены. Исправление: ожидать inline-preprocessing.

Возможные дополнительные вопросы интервьюера

Как получить стектрейс текущей горутины программно?
debug.Stack() возвращает трассировку всех горутин, либо вручную через runtime.Callers.
Можно ли изменить формат вывода паники?
Нет, но можно перехватить панику и вывести свою информацию.
Как printallgs получает стеки других горутин?
Использует функцию tracebackAll с захватом g через allgs; для бегущих g — посылает SIGUSR1 и дожидается сохранения контекста.

Чем отличается поведение рантайма на Linux, macOS и Windows?

Краткий ответ (30–60 секунд)

Поведение схоже в основах (GMP, GC), но различается на уровне системных вызовов, обработки сигналов, сетевого поллинга и управления потоками. Linux использует прямые syscall и epoll, macOS — libSystem и kqueue (из-за нестабильного ABI ядра), Windows — IOCP и CreateThread. Рантайм абстрагирует эти различия через интерфейсы os_*.go, netpoll_*.go, но есть тонкие нюансы: на macOS невозможны прямые syscall и поведение при fork отличается, Windows требует осторожной обработки сигналов и трансляции исключений.

Развёрнутый ответ

Linux: основной эталон. Прямые системные вызовы (SYSCALL), epoll, futex, сигналы POSIX. Треды через clone. netpoller использует epoll_create1. sigaction для обработчиков. Производительность и возможности максимальны.
macOS (Darwin): ABI ядра нестабилен, поэтому рантайм вызывает libSystem.dylib через cgo-подобный механизм (но без cgo) — syscall_rawSyscall использует libc. Netpoller — kqueue и kevent. madvise для возврата памяти имеет особенности. Обработка сигналов: сигнальный поток должен быть создан особым образом из-за ограничений Mach.
Windows: собственная архитектура. Netpoller использует IOCP (I/O completion ports). Потоки создаются через CreateThread. Горутины не используют набор сигналов; вместо этого для преемпции используется SuspendThread / SetThreadContext? На самом деле асинхронная преемпция реализована через APC (Asynchronous Procedure Call) или QueueUserAPC, так как сигналов в Unix-смысле нет. Обработка исключений вместо SIGSEGV. Здесь рантайм сложнее, но API скрыто.

Различия также касаются управления памятью: mmap на *nix, VirtualAlloc на Windows. GODEBUG переменные работают кросс-платформенно. Планировщик в целом один, но некоторые константы (размер стека, forcePreemptNS) могут слегка варьироваться.

Под капотом (internals)

Файлы: runtime/os_linux.go, runtime/os_darwin.go, runtime/os_windows.go. Сигналы: runtime/signal_unix.go vs runtime/signal_windows.go. Netpoller: netpoll_epoll.go, netpoll_kqueue.go, netpoll_iocp.go. Для macOS syscall вызовы в sys_darwin_amd64.s используют libcCall вместо прямого SYSCALL. На Windows newosproc вызывает CreateThread, sysmon использует SetWaitableTimer и WaitForMultipleObjects.

Типичные ошибки кандидатов

Полагать, что код рантайма абсолютно одинаков на всех ОС.
Есть значительные платформенные файлы, и поведение в угловых случаях (сигналы, fork) разное. Исправление: упоминать ключевые различия.
Считать, что на Windows производительность горутин такая же высокая.
Из-за отличий в APC для преемпции и IOCP накладные расходы могут быть чуть выше, но в целом сопоставимо. Исправление: ссылаться на бенчмарки.
Игнорировать особенность macOS с блокировкой pthread_kill.
На macOS сигналы через pthread_kill могут вызывать проблемы, поэтому используется mach_exception_raise для SIGSEGV. Исправление: знать о сложности signal handling на Darwin.

Возможные дополнительные вопросы интервьюера

Как на Windows реализована асинхронная преемпция без сигналов?
Используется QueueUserAPC для запланирования вызова функции в контексте целевого потока, что аналогично сигналу.
Почему на macOS нельзя использовать прямые syscallы?
Apple не гарантирует стабильность номеров системных вызовов между версиями и требует использовать libSystem, которая экспортируема. Также существуют ограничения на страницы в guard-стеках.
Какой netpoller самый эффективный?
epoll и kqueue сопоставимы, IOCP также высокопроизводителен. Различия минимальны в типичных нагрузках.

Что такое `GODEBUG` и как его использовать для отладки?

Краткий ответ (30–60 секунд)

GODEBUG — переменная окружения в Go, позволяющая включать отладочный вывод и изменять параметры рантайма без перекомпиляции. Её значение — список пар ключ=значение, разделённых запятыми. Примеры: GODEBUG=gctrace=1 включает трассировку GC, schedtrace=1000 выводит состояние планировщика каждые 1000 мс, cgocheck=2 ужесточает проверки указателей в CGO. Предназначена для диагностики производительности, утечек, гонок и внутренних механизмов.

Развёрнутый ответ

Под капотом (internals)

Переменные окружения разбираются в runtime.osinit -> runtime.args. Для каждой опции вызывается соответствующая функция установки, часто изменяющая глобальные переменные: gcDebug, schedtrace, schedtracePeriod, debug.asyncpreemptoff и т.д. Трассировка GC использует tracegc. schedtrace реализован в proc.go в schedtrace (горутина schedtrace), которая по таймеру выводит статистику через print.

Типичные ошибки кандидатов

Полагать, что GODEBUG меняет поведение продакшен-сборок без вреда.
Некоторые опции (gctrace=1) снижают производительность и зашумляют вывод. Следует использовать только для отладки. Исправление: рекомендовать отключать в production.
Использовать недокументированные опции, которые могут исчезнуть в будущих версиях.
Да, многие GODEBUG опции нестабильны и исчезают. Следует сверяться с документацией (go doc runtime). Исправление: использовать только известные.
Думать, что GODEBUG работает только с переменной окружения.
Можно установить через runtime/debug.SetGCPercent и т.д. программно, но не все параметры доступны. Исправление: разделять env и API.

Возможные дополнительные вопросы интервьюера

Как включить trace выполнения всех горутин?
GODEBUG=schedtrace=100,scheddetail=1.
Можно ли в рантайме изменить GODEBUG динамически?
Нет, переменные разбираются только при старте. Для некоторых есть программный API.
Как GODEBUG влияет на init функции?
Никак, обрабатывается до их запуска.

Как работает `runtime.GOMAXPROCS`?

Краткий ответ (30–60 секунд)

runtime.GOMAXPROCS(n) устанавливает максимальное количество логических процессоров p, которые планировщик может использовать для одновременного выполнения горутин. По умолчанию равно числу доступных ядер CPU. Функция возвращает предыдущее значение. Она изменяет размер массива allp, добавляя или удаляя p, и может приостановить мир (STW) для реконфигурации. Это основной способ ограничения параллелизма и снижения contention в программе.

Развёрнутый ответ

При старте runtime.GOMAXPROCS устанавливается из GOMAXPROCS окружения или числа CPU (runtime.ncpu). При вызове во время выполнения происходит:

Захват глобальной блокировки sched.lock.
Остановка мира (stopTheWorld), чтобы внести изменения в allp безопасно.
Для уменьшения числа p: лишние p отбираются у потоков (становятся idle), а их горутины переносятся в глобальную очередь. Лишние p добавляются в список freed и позже освобождаются.
Для увеличения: создаются новые p, для них аллоцируются ресурсы (mcache и т.д.), выставляется статус _Pidle.
Мир запускается снова. Новые p могут быть захвачены спящими или новыми m.

Увеличение GOMAXPROCS повышает потенциальный параллелизм, но может усилить contention на общих ресурсах (каналы, мьютексы). Уменьшение — снижает параллелизм, но уменьшает накладные расходы. Разумная настройка особенно важна в контейнеризированных средах, где программе доступно меньше CPU, чем видит планировщик по умолчанию (проблема cpu.shares). Обычно стоит вручную установить GOMAXPROCS равным лимиту cgroups.

Под капотом (internals)

runtime/proc.go: func GOMAXPROCS(n int) int. Использует stopTheWorldWithSema для STW. При уменьшении, procresize(n int32) удаляет хвост allp, освобождает их ресурсы, перемещает горутины. Важно: во время STW все p становятся idle, так что консистентность гарантирована. После изменений startTheWorld будит потоки. Существует автоматическая интеграция с cgroups v2 через readUintStat (Go 1.19+), но по умолчанию не всегда.

Типичные ошибки кандидатов

Полагать, что GOMAXPROCS определяет количество горутин.
Это только количество параллельно выполняющихся горутин (уровней параллелизма). Количество горутин не ограничено. Исправление: чётко проводить различие.
Устанавливать GOMAXPROCS больше числа ядер для улучшения производительности.
Это увеличит contention и накладные расходы на переключение контекста, обычно ухудшая производительность. Исправление: рекомендовать ≤ числу ядер.
Не учитывать, что при изменении GOMAXPROCS все горутины могут мигрировать.
Изменение приводит к массовому перемещению горутин и инвалидации кэшей. Исправление: делать это редко, лучше на старте.
Забывать, что в контейнерах нужно принудительно выставлять лимит.
До недавних версий Go не читал cgroups лимиты, что приводило к установке GOMAXPROCS по числу хостовых CPU и деградации. Исправление: использовать automaxprocs или ручную установку.

Возможные дополнительные вопросы интервьюера

Какая функция обновляет GOMAXPROCS в контейнеризированных средах?
Пакет go.uber.org/automaxprocs или runtime/debug.SetMaxThreads косвенно, но в Go 1.19+ рантайм сам учитывает cgroups v2 лимит для runtime.NumCPU().
Что произойдёт с горутинами, привязанными к p при уменьшении GOMAXPROCS?
Они будут переведены в глобальную очередь и позже запланированы на других p. Привязка к p отсутствует; есть лишь привязка к m через LockOSThread.
Как GOMAXPROCS влияет на сборщик мусора?
GC использует до GOMAXPROCS/4 или подобную эвристику для фоновых маркеров. Увеличение GOMAXPROCS может ускорить GC за счёт большего параллелизма, но и увеличить STW из-за координации.

Как `runtime.GC()` влияет на выполнение программы?

Краткий ответ (30–60 секунд)

runtime.GC() принудительно запускает цикл сборки мусора немедленно. Вызов блокирует текущую горутину до завершения mark-фазы и ожидает завершения sweep фона. Это приводит к паузе STW (stop-the-world), во время которой все горутины останавливаются, что может вызвать задержки. Функция полезна для детерминированного освобождения памяти, бенчмаркинга или работы с финализаторами, но в production нежелательна: может нарушить тайминги, увеличить задержки и снизить пропускную способность.

Развёрнутый ответ

runtime.GC() вызывает gcStart(gcTriggerCycle) с флагом gcForceBlock. Это:

Принудительно начинает цикл GC, даже если куча не достигла порога.
Вызывает stopTheWorld для инициализации mark, затем запускает конкурентные маркеры, после завершения mark снова STW для termination, и обновляет статус.
Не возвращается, пока sweep не завершится для всех спанов (чтобы гарантировать, что память полностью готова к повторному использованию).

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

Сценарии использования:

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

Под капотом (internals)

runtime/mgc.go: func GC() { ... }. Устанавливает gcForce, gcForceMode, запускает gcStart. gcStart проверяет, не идёт ли уже GC, если нет — запускает с приоритетом gcForce. STW реализуется через stopTheWorldWithSema, которая ожидает достижения всеми потоками safe-point. В gcWaitOnMark ожидается завершение маркеров. После этого Sweep происходит в фоне, но GC() ждёт, пока sweepWaiters обнулится.

Типичные ошибки кандидатов

Регулярно вызывать runtime.GC() для «управления памятью» без понимания последствий.
Это может привести к частым паузам и снижению throughput. Исправление: доверять автоматической регулировке и тюнингу через GOGC/GOMEMLIMIT.
Полагать, что runtime.GC() мгновенный и не блокирует.
Он блокирует вызывающую горутину и останавливает мир. Исправление: упоминать STW.
Думать, что после runtime.GC() память сразу возвращается ОС.
Возврат происходит асинхронно через scavenger, не гарантируется немедленно. Исправление: упоминать debug.FreeOSMemory().
Использовать для освобождения закрытого файла.
Финализатор может не сработать сразу, а GC не закроет файл. Исправление: явно закрывать.

Возможные дополнительные вопросы интервьюера

Чем runtime.GC() отличается от debug.FreeOSMemory()?
runtime.GC() только запускает сборку; FreeOSMemory() дополнительно принудительно вызывает scavenger для возврата памяти ОС.
Может ли runtime.GC() уменьшить RSS процесса?
Не сразу, только после scavenging; RSS может снизиться позже.
Есть ли гарантия, что после runtime.GC() объект с финализатором будет обработан?
Да, если объект стал недостижим, финализатор будет поставлен в очередь и выполнен отдельной горутиной.

Что такое "асинхронная вытесняющая многозадачность" (async preemption)?

Краткий ответ (30–60 секунд)

Асинхронная преемпция — механизм, добавленный в Go 1.14, позволяющий планировщику принудительно вытеснять горутину, выполняющую CPU-bound работу без кооперативных точек (вызовов функций, каналов). Реализована через отправку сигнала SIGURG потоку ОС, который выполняет горутину. Обработчик сигнала выставляет флаг преемпции в g, и при возврате из обработчика в ближайшей safe-point горутина вызывает morestack и переходит к планировщику. Это гарантирует справедливое распределение CPU даже при наличии тугих циклов.

Развёрнутый ответ

До Go 1.14 преемпция была кооперативной: горутина могла занять поток надолго, если не вызывала функций. Это создавало проблемы с зависаниями и GC-паузами. Асинхронная преемпция использует сигналы POSIX (или эквивалент на Windows). Процесс:

sysmon определяет, что горутина работает более 10 мс, выставляет g.preempt = true.
sysmon вызывает preemptM(m) → signalM(m, sigPreempt), что на Linux вызывает tgkill(pid, thread, SIGURG).
Обработчик sighandler для SIGURG проверяет, что сигнал пришёл на правильный m, и вызывает doSigPreempt. Эта функция сохраняет текущий контекст в g.sigcontext, затем вызывает asyncPreempt, которая модифицирует g.sched так, чтобы при возврате из сигнала горутина перешла в asyncPreempt2.
asyncPreempt2 вызывает mcall(gopreempt_m), который передаёт управление планировщику через goschedImpl.

Для поддержки safe-point компилятор размечает инструкции, безопасные для прерывания (где GC может сканировать стек). Асинхронная преемпция возможна только в этих точках, но их достаточно много (практически все не prologue инструкции). Циклы без вызовов также имеют safe-point на back-edge, так что преемпция там срабатывает.

Под капотом (internals)

runtime/preempt.go содержит asyncPreempt, asyncPreempt2. Ассемблерный код runtime/asm_amd64.s сохраняет и восстанавливает все регистры. Сигналы: sigPreempt = _SIGURG. doSigPreempt в signal_unix.go проверяет флаг isAsyncSafePoint. Если горутина в системном вызове, сигнал игнорируется. Для GC асинхронная преемпция помогает быстрее достигать safe-point.

Типичные ошибки кандидатов

Полагать, что асинхронная преемпция может прервать горутину в любой точке, например, в середине записи в глобальную переменную.
Прерывание только в safe-point, где состояние стека консистентно для GC. Компилятор гарантирует это. Исправление: объяснять концепцию safe-point.
Считать, что асинхронная преемпция полностью устраняет необходимость в runtime.Gosched.
В высококонкурентных сценариях Gosched всё ещё может быть полезен для снижения задержек, но не обязателен. Исправление: различать ручной yield и автоматическую преемпцию.
Думать, что асинхронная преемпция работает на всех платформах без исключений.
На Windows используется другой механизм (QueueUserAPC), на некоторых архитектурах может быть не поддержана или отключена по умолчанию. Исправление: проверять платформенную документацию.

Возможные дополнительные вопросы интервьюера

Можно ли отключить асинхронную преемпцию?
Да, GODEBUG=asyncpreemptoff=1.
Влияет ли асинхронная преемпция на производительность?
Минимально: накладные расходы на сигнал около сотни наносекунд, срабатывает редко (когда горутина заняла CPU >10 мс).
Как рантайм гарантирует, что SIGURG не попадёт в пользовательский обработчик?
Рантайм устанавливает обработчик и не позволяет программе перехватить его через signal.Notify (вызывает панику).

Как работает `runtime.Gosched()`?

Краткий ответ (30–60 секунд)

runtime.Gosched() приостанавливает текущую горутину и передаёт управление планировщику, который может запустить другую готовую горутину на этом же p. Это кооперативная передача процессора. Текущая горутина помещается в очередь готовых и будет возобновлена позже. Полезно для предотвращения монополизации CPU длительными вычислениями (в версиях до 1.14 было необходимо; сейчас остаётся как тонкая настройка).

Развёрнутый ответ

Реализация: Gosched вызывает mcall(gosched_m). gosched_m снимает текущую горутину с выполнения, помещает её в очередь runq текущего p (локальную) через globrunqputbatch? Нет, локально: runqput(pp, gp, true). Затем вызывает schedule() на стеке g0, что приводит к выбору новой горутины.

Отличие от gopark: gopark переводит горутину в состояние ожидания и требуется отдельный механизм пробуждения; Gosched оставляет горутину в состоянии _Grunnable, так что она будет перепланирована в ближайшее время. Gosched не гарантирует, что управление получит конкретная горутина, зависит от планировщика. Это аналог sched_yield в потоках POSIX.

Современный код редко нуждается в Gosched благодаря асинхронной преемпции, но он может использоваться для:

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

Под капотом (internals)

runtime/proc.go: func Gosched() { mcall(gosched_m) }. gosched_m вызывает goschedImpl(gp). goschedImpl выставляет статус _Grunnable, кладёт в runq через runqput, и вызывает schedule(). Никаких блокировок, кроме возможно локальной очереди (lock-free).

Типичные ошибки кандидатов

Использовать Gosched для синхронизации или как способ ожидания.
Это неэффективно и может приводить к непредсказуемым задержкам. Исправление: использовать каналы, мьютексы.
Полагать, что Gosched гарантирует выполнение другой горутины немедленно.
Планировщик может снова выбрать ту же горутину, если она единственная в очереди. Исправление: не полагаться на конкретный порядок.
Думать, что Gosched аналогичен time.Sleep(0).
time.Sleep(0) вызывает gopark с немедленным пробуждением, тогда как Gosched просто перепланирует без изменения состояния ожидания. Исправление: сравнивать нюансы.
Забывать о возможности ухудшить производительность частыми Gosched.
Каждый вызов вызывает mcall и переключение контекста, что добавляет задержки. Исправление: использовать только при необходимости.

Возможные дополнительные вопросы интервьюера

Можно ли вызвать Gosched из CGO-кода?
Нет, в C-коде рантайм Go недоступен. Поток должен быть в контексте горутины.
Чем Gosched полезен при отладке проблем с конкурентностью?
Может помочь в воспроизведении race conditions, искусственно создавая переключения.
В каких версиях Go Gosched был обязателен для предотвращения зависания?
До 1.14, особенно в CPU-bound циклах без вызовов функций.

Что произойдет с горутиной, если она зациклится без системных вызовов?

Краткий ответ (30–60 секунд)

С версии Go 1.14 такая горутина не заблокирует планировщик навсегда: асинхронная преемпция через сигнал SIGURG вытеснит её спустя ~10 мс, даже если внутри цикла нет вызовов функций. Без этой возможности горутина могла бы бесконечно удерживать поток, не позволяя другим горутинам работать на этом p, и потенциально мешала бы GC. В версиях до 1.14 бесконечный цикл без вызовов приводил к зависанию потока.

Развёрнутый ответ

До Go 1.14 планировщик полагался на кооперативные точки — преемпция происходила только при вызове функций (через morestack). Бесконечный цикл for {} без вызова функций вообще не имел таких точек, и горутина могла занять поток навсегда, блокируя все остальные горутины на этом p. Это требовало ручного runtime.Gosched() или введения вызовов.

Начиная с 1.14 асинхронная преемпция решает проблему: sysmon засекает длительную работу горутины (>10 мс), отправляет сигнал SIGURG потоку. Обработчик сигнала проверяет, находится ли инструкция в safe-point (почти все инструкции, включая back-edge цикла, являются таковыми). Если да, то выставляет флаг preempt и модифицирует pc, чтобы горутина при возврате из сигнала попала в asyncPreempt2 и вызвала планировщик. Таким образом, горутина вытесняется, и p освобождается для других горутин.

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

Под капотом (internals)

safe-point разметка: компилятор генерирует PCDATA и FUNCDATA для указания safe-point. Почти все инструкции безопасны, за исключением некоторых прологов/эпилогов. В sighandler для SIGURG вызывается isAsyncSafePoint, проверяющая, можно ли здесь прервать. Если нет, сигнал игнорируется, и sysmon попробует снова позже (но маловероятно, что цикл не содержит safe-point хотя бы раз в 10 мс). Фактически, любой прыжок назад имеет safe-point.

Типичные ошибки кандидатов

Утверждать, что такая горутина навсегда повесит поток, как в ранних версиях Go.
Нужно уточнить версию. В современных — нет.
Полагать, что преемпция происходит мгновенно.
Есть задержка 10 мс, иногда больше при большой загрузке sysmon.
Думать, что асинхронная преемпция работает в CGO-коде или ассемблерных функциях.
Нет, только в Go-коде, где поддерживается safe-point инфраструктура. В CGO-блоках преемпция невозможна, и долгий C-вызов может блокировать поток.

Возможные дополнительные вопросы интервьюера

Можно ли написать Go-код, который нельзя прервать асинхронно?
Да, намеренно обходя safe-point, но это требует ассемблера и крайне не рекомендуется.
Как убедиться, что цикл с большим объёмом вычислений не мешает GC?
Добавить if shouldYield() { runtime.Gosched() } для ручного кооперативного прерывания.
Что будет, если все горутины зациклены без вызовов?
sysmon будет вытеснять их по очереди каждые 10 мс, прогресс будет медленным, но возможным.

Как работает `runtime.NumGoroutine()`?

Краткий ответ (30–60 секунд)

runtime.NumGoroutine() возвращает текущее количество существующих горутин в программе. Это значение равно len(allgs) - ngsys, где allgs — слайс всех горутин, включая системные (например, sysmon, g0). Функция не блокирует планировщик и работает за O(1) (по некоторому счётчику или длине слайса). Используется для мониторинга и отладки, но не для синхронизации.

Развёрнутый ответ

Реализация: в runtime/proc.go, func NumGoroutine() int возвращает gcount(). gcount вычисляется как len(allgs) - sched.ngsys. allgs — глобальный массив указателей на g, который пополняется при создании горутины (через allgadd). ngsys — количество системных горутин (тех, что созданы с systemstack или g0), которые обычно не учитываются в пользовательском числе. Значение обновляется атомарно? При добавлении горутины allgs расширяется с мьютексом sched.lock, но len читается без блокировки, что может дать слегка устаревшее значение, но в целом безопасно. При удалении горутины (после завершения) allgs не сжимается, но горутина помечается как мёртвая и может быть удалена из allgs только при следующей сборке? На самом деле, allgs только растёт, мёртвые горутины не удаляются для упрощения; количество мёртвых горутин ngdead вычитается из общего числа. Так что gcount может включать завершённые горутины? В современных версиях мёртвые горутины переводятся в список свободных (gfree) и удаляются из allgs. Поэтому цифра относительно точна.

Под капотом (internals)

runtime/runtime2.go: var allgs []*g — защищён sched.lock при добавлении. При завершении горутины goexit0 вызывает gfput, которая может вернуть g в кэш или в список свободных, и при этом allgs не уменьшается, но g помечается как _Gdead. gcount учитывает только горутины со статусом не _Gdead? Там формула len(allgs) - sched.ngsys. ngsys не включает умершие. Мёртвые горутины исключаются из allgs в периодической очистке shrinkstack? Сложно. Но для практики число совпадает с тем, что видно в pprof.

Типичные ошибки кандидатов

Полагать, что NumGoroutine блокирует планировщик.
Это быстрое чтение без блокировок. Исправление: уточнять, что нет STW.
Использовать как точный индикатор утечек в реальном времени для принятия решений.
Из-за отложенного удаления мёртвых горутин число может временно не уменьшаться. Исправление: комбинировать с профилированием.
Считать, что в счёт входят системные горутины, такие как sysmon.
Они вычитаются через ngsys. Исправление: знать о вычете.
Думать, что функция даёт количество работающих горутин.
Это общее количество, включая спящие и ожидающие. Для количества работающих нет прямой функции.

Возможные дополнительные вопросы интервьюера

Как получить число горутин в конкретном состоянии?
Через /debug/pprof/goroutine, парсить вывод или через runtime.GoroutineProfile.
Почему allgs не уменьшается при завершении горутины?
Для простоты и производительности; очистка происходит отложено.
Может ли NumGoroutine вернуть 0 при работающей main?
Нет, main горутина всегда существует.

Как работает `runtime.SetBlockProfileRate`?

Краткий ответ (30–60 секунд)

runtime.SetBlockProfileRate(rate) включает профилирование блокировок (задержек на мьютексах и каналах). Параметр rate задаёт долю событий блокировки, которые записываются в профиль (1 — все, 0 — отключено). Каждое событие блокировки дольше порога (по умолчанию ~0) собирает стек вызова и длительность. Профиль извлекается через pprof и помогает выявлять «узкие места» в синхронизации. Внутренне реализована через сэмплирование и хеш-таблицу blockprofilerate.

Развёрнутый ответ

Когда горутина блокируется на sync.Mutex.Lock, sync.RWMutex, chan send/receive, select, рантайм вызывает runtime.blockevent с указанием причины и длительности ожидания. Если профилирование включено (blockprofilerate > 0), и случайное число (на основе fastrand) меньше rate, событие записывается. Запись содержит стек вызовов (PC), причину блокировки, длительность. Данные агрегируются в хеш-таблицу blockprofilerate, где ключом является стек. Позже при запросе профиля через /debug/pprof/block или runtime/pprof.Lookup("block") эти данные агрегируются и выдаются.

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

Под капотом (internals)

runtime/mprof.go: blockevent проверяет blockprofilerate. Стек сохраняется с помощью callers. Данные сохраняются в mbuckets — бакеты на основе хеша стека. Структура blockRecord содержит count и cycles. Сборка мусора не очищает профили, пока не вызовется runtime.GC? Профили хранятся в отдельной памяти, не связанной с GC-кучей напрямую. Для получения профиля pprof читает бакеты и формирует ответ.

Типичные ошибки кандидатов

Полагать, что SetBlockProfileRate включает профилирование всех блокировок, включая time.Sleep.
Он включает только блокировки на мьютексах и каналах. Исправление: уточнить список.
Думать, что rate — это количество событий в секунду.
Это доля событий для сэмплирования, безразмерная. Исправление: правильно объяснять параметр.
Забывать, что ненулевое значение добавляет накладные расходы (стектрейс + хеш).
В высоконагруженных системах может снизить производительность. Исправление: предупреждать об overhead.
Использовать в продакшене с настройкой rate=1 без ограничений.
Это может привести к значительным замедлениям. Исправление: использовать умеренные значения.

Возможные дополнительные вопросы интервьюера

Как получить профиль блокировок в Go-программе?
runtime.SetBlockProfileRate(1), затем зарегистрировать pprof handler и открыть /debug/pprof/block.
Что означает отрицательное значение параметра rate?
Не допускается, приведёт к панике или игнорированию.
Можно ли профилировать только мьютексы, исключая каналы?
Нет, блокировочный профиль собирает всё вместе. Можно разделить анализом причин.

Что такое "mutex profile" и как его получить?

Краткий ответ (30–60 секунд)

Mutex profile (профиль мьютексов) — это инструмент профилирования задержек, вызванных ожиданием на sync.Mutex и sync.RWMutex. Показывает, где горутины проводят время в попытке захвата. Включается через runtime.SetMutexProfileFraction(rate > 0), где rate — доля событий для записи (аналогично block профилю). Профиль извлекается через pprof.Lookup("mutex") или /debug/pprof/mutex. Позволяет найти самые горячие точки contention.

Развёрнутый ответ

По умолчанию мутекс-профилирование отключено. Для включения нужно вызвать runtime.SetMutexProfileFraction(rate). При rate = 1 регистрируется каждое событие ожидания, при rate = 1000 — примерно 1 из 1000. Когда горутина пытается захватить мьютекс и блокируется, рантайм вызывает mutexevent с длительностью ожидания и стеком. Данные агрегируются аналогично блок-профилю, но в отдельной таблице. Это помогает отличить проблемы именно в синхронизации через мьютексы от каналов.

Профиль содержит для каждого стека: общее время ожидания и количество событий. Отличие от block profile: block профиль включает все блокировки (каналы, select), mutex — только мьютексы. Поэтому тоньше детализация.

Под капотом (internals)

runtime/mprof.go: SetMutexProfileFraction устанавливает mutexprofilerate. mutexevent (в runtime/lock_futex.go или подобном) вызывается при разблокировке? На самом деле sync.Mutex реализован в runtime/sema.go, но профилирование встроено: при semacquire вызывается mutexevent с сохранённым временем начала. В sync.Mutex.Lock используется runtime.semacquire с возможностью профилирования. Данные хранятся в mbuckets с типом mutexRecord.

Типичные ошибки кандидатов

Путать block profile и mutex profile.
Block — более общий (каналы, select), mutex — только мьютексы. Исправление: чётко различать.
Утверждать, что mutex profile показывает, кто удерживает мьютекс.
Он показывает только ожидающих, но не владельца (для этого нужен более сложный анализ). Исправление: пояснять ограничения.
Забывать вызвать SetMutexProfileFraction и ожидать данных в pprof.
По умолчанию пусто. Исправление: напомнить о включении.

Возможные дополнительные вопросы интервьюера

Можно ли включить mutex profile без block profile?
Да, они независимы.
Как профили мьютексов помогают в оптимизации?
Выявляют горячие точки contention, позволяют пересмотреть алгоритм, добавить шардирование или lock-free структуры.

Как Go runtime обрабатывает сигналы `SIGSEGV`?

Краткий ответ (30–60 секунд)

При возникновении SIGSEGV (segmentation fault) рантайм перехватывает его через установленный обработчик sigtramp. Если нарушение вызвано обращением к nil-указателю или выходом за пределы кучи, не связанным с расширением стека, sighandler вызывает sigpanic, которая инициализирует панику с сообщением «invalid memory address or nil pointer dereference» и продолжает выполнение горутины в точке паники, что запускает нормальный механизм panic/recover. Если нарушение произошло на guard-странице стека горутины, рантайм расширяет стек и повторяет инструкцию. Все остальные случаи приводят к немедленному краху программы.

Развёрнутый ответ

Сигнал SIGSEGV доставляется ядром процессу при недопустимом обращении к памяти. Рантайм Go устанавливает обработчик для этого сигнала, чтобы отличать ожидаемые ситуации (расширение стека) от неожиданных (нулевые указатели). В обработчике (на ассемблере: runtime.sigtramp) сохраняются все регистры и вызывается runtime.sigtrampgo, которая определяет причину:

Stack overflow: Если faulting address находится в диапазоне guard-страницы стека горутины, вызывается runtime.morestack. Она расширяет стек, и обработчик возвращает управление так, что инструкция повторяется успешно.
Nil-pointer dereference: Если адрес — нулевой или рядом, sighandler вызывает runtime.sigpanic. sigpanic модифицирует g.sig, g.sigcode0, и меняет pc горутины на адрес функции runtime.sigpanic. Когда сигнал завершается, горутина продолжает выполнение с sigpanic, которая формирует аргумент паники и вызывает panic.
Некорректная операция в unsafe коде, порча памяти: Если адрес не nil и не guard, рантайм скорее всего не сможет восстановиться и вызывает throw с фатальной ошибкой.

Таким образом, обычный nil-dereference превращается в recoverable panic.

Под капотом (internals)

runtime/os_linux.go: setsig для _SIGSEGV устанавливает sigtramp. В runtime/signal_unix.go: sigtrampgo диспетчеризует. sigpanic находится в runtime/panic.go. Важный момент: синхронные сигналы обрабатываются на том же потоке и в контексте той же горутины. После sigpanic горутина находится в состоянии, аналогичном вызову panic. GC может сканировать её стек.

Типичные ошибки кандидатов

Считать, что любое SIGSEGV неминуемо завершает программу.
В Go это не так благодаря описанному механизму. Исправление: объяснять sigpanic.
Полагать, что можно перехватить SIGSEGV через signal.Notify и продолжить работу.
signal.Notify позволяет получить сигнал, но после его обработки программа всё равно упадёт, так как рантайм уже среагировал. Исправление: указывать, что sigpanic встроен.
Думать, что recover может перехватить панику, вызванную SIGSEGV из стека, который повреждён.
Если повреждение обширное, восстановление невозможно, и программа упадёт с runtime error.

Возможные дополнительные вопросы интервьюера

Что произойдёт, если произойдёт SIGSEGV в CGO-коде?
Сигнал может быть обработан, если C-код не устанавливает свой обработчик; стандартный рантайм Go может поймать и попытаться преобразовать в панику, но это ненадёжно.
Как рантайм различает guard-страницу стека от обычного нарушения?
Сравнивает адрес с g.stack.lo и g.stack.hi и знает, где guard.
Можно ли намеренно вызвать SIGSEGV для проверки восстановления?
Да, var p *int; *p = 0; recover() поймает панику.

Как работает `pprof` на уровне сэмплирования?

Краткий ответ (30–60 секунд)

pprof профилирует использование CPU путём периодического сэмплирования счётчика команд (PC) всех горутин с заданной частотой (по умолчанию 100 Гц). Для этого используется таймер ОС (setitimer), который генерирует сигнал SIGPROF. Обработчик сигнала захватывает текущий PC (и стек) горутины на каждом m и добавляет в хеш-таблицу профиля. Таким образом, чем больше времени горутина проводит в функции, тем чаще её сэмплы попадают в профиль. Также существуют heap, block, mutex профили на основе событий.

Развёрнутый ответ

CPU profiling запускается через pprof.StartCPUProfile(w). Функция устанавливает интервальный таймер setitimer(ITIMER_PROF, 1/rate). При каждом тике сигнал SIGPROF доставляется произвольному потоку. Обработчик sighandler вызывает runtime·sigprof с предоставленным контекстом. sigprof проверяет, что это был профилировочный сигнал, получает текущую горутину g и стек вызовов (через callers). Если g выполняла пользовательский код, стек сжимается, хешируется и записывается в buckets профиля. Если в момент сигнала горутина была в системном вызове или idle, сэмпл не берётся (или записывается как special).

Частота сэмплирования — 100 Гц. Накладные расходы: сигнал + обход стека занимают микросекунды, что примерно 0.1% CPU. Профиль стека агрегируется, после остановки записывается в protobuf формат и может быть визуализирован go tool pprof.

Под капотом (internals)

runtime/cpuprof.go: cpuprof.startcpu создаёт cpuprof, аллоцирует буфер, запускает тикер. Обработчик сигнала в runtime/signal_unix.go вызывает sigprof (файл runtime/proc.go). sigprof использует gentraceback для получения стека, затем cpuprof.add для учёта. Данные хранятся в cpuprof.h — хеш-таблица, каждая запись — cpuprofEntry со стеком и счётчиком. При остановке профиля данные считываются в pprof writer.

Типичные ошибки кандидатов

Полагать, что профилирование CPU измеряет точное время выполнения каждой функции.
Это статистический сэмплер, он даёт приблизительное распределение, основанное на частоте появлений. Исправление: говорить о сэмплировании.
Думать, что SIGPROF может быть перехвачен пользователем.
Рантайм уже использует его, пользовательский signal.Notify для SIGPROF не допускается (паника). Исправление: знать о защите.
Игнорировать, что профилирование отключает некоторые оптимизации (escape analysis?).
Влияние минимально, но включение pprof может незначительно изменить поведение из-за дополнительного сигнала.
Забывать, что профиль не включает время ожидания (блокировок).
CPU-профиль показывает только время, когда горутина активно выполняется на CPU. Для блокировок нужны block/mutex профили.

Возможные дополнительные вопросы интервьюера

Как получить профиль кучи?
pprof.WriteHeapProfile(w) или через handler, он показывает текущее распределение объектов, а не времени.
Можно ли увеличить частоту сэмплирования для повышения точности?
Да, через runtime.SetCPUProfileRate(rate), но увеличивается overhead.
Как работает профилирование goroutine?
Это не сэмплирование, а мгновенный снимок состояния всех горутин.

Какова роль ассемблера в исходном коде Go runtime?

Краткий ответ (30–60 секунд)

Ассемблер в Go runtime используется для низкоуровневых операций, которые невозможно или неэффективно выразить на Go: переключение контекста горутин, сохранение/восстановление регистров, системные вызовы, сигнальные трамплины, манипуляции TLS, синхронизации с аппаратными барьерами, работа со стеком (gogo, mcall, morestack), а также для стартовой инициализации процесса. Он абстрагирует платформенно-зависимые детали, обеспечивая производительность и корректность.

Развёрнутый ответ

Основные файлы ассемблера: runtime/asm_$GOARCH.s (например, asm_amd64.s), rt0_$GOOS_$GOARCH.s. Важнейшие функции:

_rt0_amd64 — точка входа программы.
mcall(fn) — переключение на g0 и вызов fn.
gogo(buf *gobuf) — восстановление контекста горутины и переход.
morestack — расширение стека.
systemstack(fn) — выполнение функции на системном стеке.
asmcgocall(fn) — переключение на C-стек.
Сигнальные трамплины: sigtramp — сохраняет контекст сигнала и вызывает Go-обработчик.
Системные вызовы: syscall, rawSyscall.
Атомарные операции на уровне процессора (хотя многие реализованы через internal/atomic на Go с asm).
get_tls и манипуляции с thread-local storage.
jmpdefer для управления отложенными вызовами.

Ассемблерные функции обеспечивают минимальные накладные расходы и точный контроль над регистрами и флагами, что критично для планировщика и GC (например, барьеры записи). Ассемблер также используется для вставки отладочных меток и точек останова.

Под капотом (internals)

Планировщик: runtime.mcall сохраняет только callee-saved регистры в g.sched, загружает g0 стек. gogo восстанавливает и делает JMP. Для async preemption в ассемблере asyncPreempt сохраняет все XMM регистры и вызывает asyncPreempt2. Сисколы на amd64: MOVQ аргументов в регистры, SYSCALL, проверка результата. Важная деталь: ассемблер Go использует планарный синтаксис с символом · (middle dot) в идентификаторах.

Типичные ошибки кандидатов

Полагать, что ассемблер не нужен и всё можно написать на Go.
Без ассемблера невозможно переключение стеков, так как нужно прямое управление SP и PC, что не позволяет безопасный язык. Исправление: объяснять низкоуровневые требования.
Считать, что ассемблерные вставки замедляют код.
Наоборот, они устраняют overhead высокоуровневых конструкций.
Думать, что ассемблер Go совместим с синтаксисом NASM/AT&T.
Используется собственный синтаксис планарного ассемблера, отличный от макросов Plan 9. Исправление: упоминать особенности синтаксиса.

Возможные дополнительные вопросы интервьюера

Как написать свою ассемблерную функцию в Go?
Создать файл .s с сигнатурой TEXT ·MyFunc(SB),NOSPLIT,$0, реализовать логику.
Почему Go не использует C-ассемблер для вставок?
Потому что рантайм должен быть самодостаточен и не зависеть от внешних тулчейнов; кроме того, планарный ассемблер лучше интегрирован с инфраструктурой стека.

Как `go:linkname` используется в рантайме и чем это опасно?

Краткий ответ (30–60 секунд)

go:linkname — директива компилятора, которая позволяет объявить локальный символ одного пакета доступным из другого пакета, связывая их на этапе линковки. В рантайме широко используется для экспорта внутренних символов (например, runtime.morestack) в пакеты sync, syscall, time без экспорта в публичное API. Это опасно, так как обходит систему типов и версионирование: может привести к неопределённому поведению, панике или поломке при обновлении версии Go, так как имена и сигнатуры внутренних символов нестабильны.

Развёрнутый ответ

Синтаксис: в файле, где требуется использовать символ из другого пакета, пишут import _ "unsafe" и объявление функции без тела: //go:linkname runtimeFunc runtime.runtimeFunc. Компилятор и линковщик разрешают символ runtimeFunc в текущем пакете на символ runtime.runtimeFunc в пакете runtime. Это позволяет пользовательским пакетам (и стандартной библиотеке) вызывать неэкспортируемые функции рантайма. Например, sync.Mutex использует runtime.Semacquire и runtime.Semrelease через go:linkname. Без этого пришлось бы экспортировать множество деталей реализации, загрязняя API.

Опасности для пользовательского кода:

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

Тем не менее, рантайм использует go:linkname для внутренней модульности, и это задокументированная, но опасная практика. Вне стандартной библиотеки применять не рекомендуется.

Под капотом (internals)

Файлы рантайма: runtime/sema.go экспортирует semacquire и semrelease через go:linkname. Компилятор обрабатывает директиву, линковщик (cmd/link) при разрешении символов связывает их. При этом проверка типов отсутствует — ответственность программиста обеспечить соответствие сигнатур. Несоответствие приводит к неопределённому поведению.

Типичные ошибки кандидатов

Считать, что go:linkname — безопасный способ обойти экспорт.
Это хак, который может сломаться в любое обновление. Исправление: предупреждать об опасности.
Использовать go:linkname для доступа к внутренностям рантайма в production коде.
Пример: прямой вызов runtime.mallocgc. Это ведёт к катастрофическим последствиям. Исправление: отговаривать.
Полагать, что можно переопределить символ рантайма через go:linkname для модификации поведения.
Это может привести к конфликтам символов и непредсказуемому поведению линковщика. Исправление: объяснять, что линковщик разрешает символы однозначно.
Забывать, что go:linkname требует импорта unsafe даже если не используется явно.
Без импорта не сработает. Исправление: упоминать.

Возможные дополнительные вопросы интервьюера

Как узнать, какие символы доступны через go:linkname?
Просмотреть исходники, особенно файлы с //go:linkname внутри runtime. Внешнего списка нет.
Может ли go:linkname использоваться для связи между двумя пользовательскими пакетами?
Да, технически возможно, но не рекомендуется.
Что такое «псевдоним» через go:linkname для обхода проверок?
Можно создать локальную функцию с другой сигнатурой, которая ссылается на рантайм, и передать неправильные типы — вызовет крах.

Что такое «закрепление горутины за потоком» и зачем это нужно для некоторых операций?

Краткий ответ (30–60 секунд)

Закрепление горутины за потоком (LockOSThread) гарантирует, что горутина будет выполняться строго на одном и том же потоке ОС, пока не вызовет UnlockOSThread. Это необходимо, когда вызываемый код (CGO, low-level libraries) использует thread-local storage (TLS) или требует стабильного идентификатора потока (например, для pthread_self). Без закрепления горутина могла бы мигрировать на другой поток после системного вызова или преемпции, разрушая контекст TLS.

Развёрнутый ответ

Пакет runtime предоставляет функции LockOSThread() и UnlockOSThread(). Поток ОС (m) после блокировки помечается lockedg = g, а горутина — lockedm = m. Планировщик, выбирая эту горутину для выполнения, проверяет, привязана ли она к потоку. Если да, то горутина может выполняться только на этом потоке. Если поток занят или заблокирован, горутина будет ждать его. Аналогично, если поток хочет взять другую горутину, но к нему привязана определённая, он должен ждать её готовности.

Сценарии:

CGO и системные библиотеки: например, OpenGL контексты привязаны к потоку. Нужно закрепить горутину, выполняющую рендеринг.
Низкоуровневые вызовы pthread: инициализация или изменение атрибутов потока.
Обработка сигналов на уровне ОС: некоторые вызовы сигнальнобезопасны только на определённом потоке.
Работа с unshare/setns: изменение пространств имён Linux требует стабильного потока.
Goroutine-local storage эмуляция: хотя не рекомендуется, можно хранить данные в thread-local памяти, закрепив горутину.

Важно: закрепление не мешает потоку входить в syscall и блокироваться; при этом p отбирается, но m сохраняет привязку и продолжит выполнять только эту горутину.

Под капотом (internals)

В runtime/proc.go: LockOSThread увеличивает m.locked, устанавливает m.lockedg. В schedule, когда выбирается новый g, проверяется g.lockedm. Если он не nil, вызывается startlockedm(gp), которая паркует текущий m (если это не тот самый m) и пробуждает привязанный m для выполнения. Если привязанный m уже выполняет другую горутину? Он не может, так как lockedg ограничивает.

Типичные ошибки кандидатов

Использовать LockOSThread для «оптимизации» производительности (привязка к CPU-кэшу).
Это не даёт гарантии выполнения на конкретном ядре, только на конкретном потоке ОС. Неэффективно и ограничивает параллелизм. Исправление: не использовать без крайней необходимости.
Забывать разблокировать поток после использования.
Поток навсегда остаётся привязанным, что ведёт к утечке потоков или снижению параллелизма. Исправление: defer runtime.UnlockOSThread().
Полагать, что привязанный поток не может блокироваться.
Может, но это блокирует и горутину, и потенциально может вызвать нехватку потоков. Исправление: понимать последствия.

Возможные дополнительные вопросы интервьюера

Как LockOSThread взаимодействует с GOMAXPROCS?
GOMAXPROCS не влияет на привязку; привязанный поток всё равно требует p для выполнения, но p может быть украден во время syscall, но поток сохранит горутину.
Можно ли привязать несколько горутин к одному потоку последовательно?
Да, после UnlockOSThread другой горутина может закрепиться за этим потоком.

Как работает `syscall.RawSyscall` и в чем его отличие от `syscall.Syscall`?

Краткий ответ (30–60 секунд)

syscall.RawSyscall выполняет системный вызов напрямую, без вызова entersyscall и exitsyscall из рантайма. Он используется в очень ограниченных случаях, например, в обработчиках сигналов, где нельзя трогать состояние рантайма. Главное отличие: Syscall безопасен для планировщика, блокирует p и разрешает преемпцию, RawSyscall — нет. Неправильное применение RawSyscall может нарушить работу GC и планировщика.

Развёрнутый ответ

Оба в конечном счёте делают инструкцию SYSCALL. Но Syscall оборачивает её в runtime.entersyscall (помечает p как _Psyscall, блокирует g для GC) и runtime.exitsyscall (восстанавливает). Это гарантирует, что рантайм знает о блокировке и может перераспределить p. RawSyscall делает только сам вызов без взаимодействия с рантаймом. Поэтому:

Syscall: для большинства системных вызовов (read, write, open). Безопасен, но имеет накладные расходы на учет.
RawSyscall: для случаев, когда рантайм уже находится в нестабильном состоянии (например, внутри signal handler, до инициализации рантайма, или при выполнении на системном стеке g0). Там нельзя вызывать entersyscall, так как это может нарушить целостность.

Также RawSyscall должен использоваться только для быстрых вызовов, которые гарантированно не блокируются (например, gettid, getpid). Блокирующий RawSyscall приведёт к зависанию потока без возможности sysmon отобрать p, что в итоге снижает утилизацию CPU.

Под капотом (internals)

В runtime/sys_linux_amd64.s: TEXT runtime·syscall(SB) ... включает entersyscall / exitsyscall. TEXT runtime·rawSyscall(SB) ... выполняет только SYSCALL. В пакете syscall экспортируются обе функции. RawSyscall определён как //syscall с тегом raw.

Типичные ошибки кандидатов

Использовать RawSyscall для обычного read из файла ради производительности.
Это уберёт безопасное взаимодействие с планировщиком и может привести к деградации. Исправление: использовать Syscall или syscall.Read.
Полагать, что RawSyscall не влияет на GC.
Влияет, потому что GC не знает, что поток блокирован, и может пытаться остановить мир, что приведёт к долгой паузе или зависанию. Исправление: осознавать риск.
Вызывать RawSyscall в пользовательской горутине для блокирующего вызова.
Это может навсегда занять поток без возможности уступить p. Исправление: только в крайнем случае.

Возможные дополнительные вопросы интервьюера

Где в рантайме применяется RawSyscall?
Внутри futexsleep, sigsend, sysmon для некоторых операций, где нельзя тревожить планировщик.
Можно ли из пользовательского кода безопасно вызвать RawSyscall?
Теоретически да, но только для неблокирующих операций и с полным пониманием последствий; рекомендуется использовать x/sys/unix обёртки.
Как RawSyscall ведёт себя при преемпции?
Преемпция невозможна во время выполнения; поток не может быть прерван сигналом в середине SYSCALL, но сразу после возврата, если не было entersyscall, планировщик не узнает, что горутина блокировалась.

Чем отличается `runtime.KeepAlive()` от простого использования переменной?

Краткий ответ (30–60 секунд)

runtime.KeepAlive(x) — это явное указание компилятору и GC, что переменная x должна считаться живой до этой точки программы, предотвращая её преждевременную сборку мусора. Простое использование переменной после некоторой операции может быть оптимизировано компилятором (перенесено или удалено), а KeepAlive гарантирует, что x не будет собрана и её финализатор не запустится до вызова. Это критично при работе с unsafe.Pointer или системными ресурсами.

Развёрнутый ответ

Проблема: GC может решить, что объект недостижим, сразу после последнего обращения к нему в исходном коде, даже до завершения функции, если компилятор решит, что ссылка больше не нужна. Например:

f, _ := os.Open(...)
// работа с f
// без явной ссылки на f в конце функции

Компилятор может оптимизировать и опустить ссылку на f после последнего использования, и GC может собрать f и вызвать финализатор (закрытие файла) до фактического завершения работы. runtime.KeepAlive(f) в конце функции говорит компилятору: «оставь f живым до этого места».

Особенно важно при передаче указателей в C через unsafe.Pointer, где Go-компилятор не видит использование в C-коде и может преждевременно освободить память. KeepAlive гарантирует, что память не будет собрана до возврата из C-функции.

KeepAlive реализован как func KeepAlive(interface{}), которая ничего не делает, но вызов с x предотвращает удаление ссылки на x до этого вызова (escape analysis удерживает x живым).

Под капотом (internals)

runtime/KeepAlive — это пустая функция с сигнатурой func KeepAlive(interface{}). Её вызов заставляет компилятор считать x достижимым в точке вызова, потому что аргумент должен быть передан. Компилятор не может удалить вызов, так как это нарушило бы гарантии. В ассемблере это пустая заглушка, но эффект достигается за счёт семантики компилятора.

Типичные ошибки кандидатов

Считать, что финализатор или сборка не могут сработать до конца функции.
Могут, если компилятор оптимизирует ссылку. Исправление: использовать KeepAlive.
Полагать, что runtime.GC() достаточно для предотвращения сборки.
Он не помогает, так как проблема в компиляторной оптимизации. Исправление: знать разницу между явным GC и удержанием живучести.
Передавать unsafe.Pointer в C без KeepAlive после вызова.
Риск, что память будет освобождена до того, как C-функция реально использует указатель. Исправление: KeepAlive(p) после C-вызова.

Возможные дополнительные вопросы интервьюера

Может ли компилятор встроить KeepAlive и удалить?
Нет, компилятор знает семантику этой функции и не может исключить её.
Нужно ли использовать KeepAlive для каналов?
Канал обычно живёт дольше из-за ссылок, но в сомнительных случаях не помешает.
Как KeepAlive связан с runtime.Pin?
runtime.Pin (Go 1.21+) предотвращает перемещение объекта GC, но не удерживает его живым; KeepAlive только продлевает жизнь. Они дополняют друг друга.

Как работает диспетчеризация сигналов в рантайме?

Краткий ответ (30–60 секунд)

Рантайм создаёт выделенный поток-маскировщик сигналов (signal thread), который получает все асинхронные сигналы и направляет их нужному m через очередь m.sig. Для синхронных сигналов (SIGSEGV) обработка происходит непосредственно на потоке, где произошло событие. Диспетчеризация гарантирует, что обработка сигнала происходит в контексте конкретной горутины и безопасна для GC. Основные этапы: маскирование, захват сигнала, помещение в очередь, пробуждение целевого m, обработка на стеке горутины.

Развёрнутый ответ

Инициализация: В runtime.signal_init создаётся специальный поток signal_thread с маской, разрешающей только сигналы, интересующие рантайм. Для всех остальных потоков сигналы маскируются.
Доставка сигнала: Асинхронные сигналы (SIGURG, SIGALRM) доставляются signal thread. Он вызывает sigsend(sig), которая атомарно помещает сигнал в глобальную очередь sig.m и затем проверяет, нужно ли послать сигнал какому-либо m. Синхронные сигналы (SIGSEGV) доставляются непосредственно выполняющему потоку; signal thread не участвует.
Обработка: Целевой m в безопасных точках (например, при выходе из syscall, планировании) вызывает sigrecv для получения ожидающих сигналов и обрабатывает их. Для преемпции SIGURG просто выставляет флаг преемпции. Для SIGPROF накапливает профиль.
Контекст: Обработка происходит на стеке горутины (через ассемблерный trampoline), с сохранением регистров, чтобы не повредить выполнение.

Такая архитектура избегает проблем reentrancy и позволяет безопасно взаимодействовать с планировщиком.

Под капотом (internals)

runtime/os2_linux.go? Основное в runtime/signal_unix.go, runtime/sigqueue.go. sigsend добавляет сигнал в sig.m (массив флагов), затем через tgkill (или kill) будит signal thread. Функция sigrecv извлекает сигналы. Для синхронных сигналов обработка сразу в sigtramp на том же потоке.

Типичные ошибки кандидатов

Считать, что все сигналы обрабатываются на signal thread.
Signal thread только принимает асинхронные и распределяет их. Обработка — на целевом m. Исправление: разграничивать приём и обработку.
Думать, что обработка сигнала прерывает горутину в произвольный момент без сохранения контекста.
Контекст сохраняется, после обработки горутина продолжается как ни в чём не бывало (или с изменениями PC при панике). Исправление: описывать механизм trampoline.
Игнорировать, что для пользовательских сигналов используется та же инфраструктура.
signal.Notify тоже использует рантаймовую диспетчеризацию, но в отдельную горутину.

Возможные дополнительные вопросы интервьюера

Как signal.Notify передаёт сигнал в канал?
Рантайм вызывает функцию обратного вызова, которая отправляет значение в зарегистрированный канал.
Может ли обработчик сигнала быть вызван на g0?
Да, некоторые части могут работать на системном стеке для обеспечения безопасности.

Как `runtime.Caller()` получает информацию о стеке вызовов?

Краткий ответ (30–60 секунд)

runtime.Caller(skip) возвращает pc, файл, строку и успех вызова для заданной глубины стека. Он обходит стековые фреймы, начиная с текущей функции, используя метаданные компилятора — таблицу функций (pclntab) для трансляции программного счётчика в информацию об исходнике. Это достигается с помощью callers (заполняет срез pc) и FunForPC. Обход стека не требует остановки мира и работает быстро.

Развёрнутый ответ

Функция Caller(skip) вызывает callers(0, rpc, skip+1), которая заполняет массив rpc счётчиками команд фреймов. Затем для первого элемента вызывается FunForPC(pc) для получения runtime.Func, откуда извлекается файл и строка через func.fileLine(pc). FunForPC использует таблицу findfunc(pc), которая ищет в двоичном дереве (или хеш-таблице) диапазонов адресов функций, построенных при линковке. Адресация строк основана на pcln — таблице линейной информации, генерируемой компилятором, которая сопоставляет pc и номер строки.

Внутренняя реализация runtime.Callers собирает pc с помощью gentraceback, который следует по сохранённым в стеке bp/sp, используя информацию о фреймах (размер, регистры). Это работает и для inline-функций: с версии Go 1.12 встроенные функции раскрываются, и Caller может вернуть самый внешний встроенный вызов.

Под капотом (internals)

runtime/traceback.go: callers, gentraceback. gentraceback для получения стека использует stkbar и frame.pc. findfunc в runtime/symtab.go ищет в массиве functab, отсортированном по entry, через FindFunc. Данные хранятся в секции .gopclntab ELF-файла. Конвертация pc -> file/line через pclntab.step (кодирование разницы строк).

Типичные ошибки кандидатов

Полагать, что Caller обходит стек с помощью debug.ReadBuildInfo.
Нет, он использует внутренние таблицы, собранные компилятором.
Считать, что Caller дорог и его следует избегать в production.
Он относительно лёгок (без блокировок), но имеет сложность O(глубина) и может добавить задержки при частом вызове.
Думать, что Caller может вернуть информацию для CGO-фреймов.
Если нет символов, файл может быть пустым или "?".
Игнорировать влияние inline-функций.
Caller может вернуть файл/строку встроенной функции, а не самой вызываемой, если не использовать специальные флаги. Исправление: учитывать runtime.CallersFrames для полной картины.

Возможные дополнительные вопросы интервьюера

Как получить полный стектрейс в виде слайса строк?
runtime.CallersFrames заполняет runtime.Frames из собранных pc.
Влияет ли escape analysis на доступность стека для Caller?
Нет, стек всегда доступен.
Может ли Caller прочитать стек другой горутины?
С помощью runtime.Stack (читает буфер), но не через Caller напрямую.

Что такое «состояние гонки» в самом планировщике Go и как его избегают?

Краткий ответ (30–60 секунд)

Гонка в планировщике — это состояние, когда несколько потоков одновременно пытаются изменить общие структуры (глобальную очередь, списки idle m/p, поля p), что может привести к потере горутины, двойному выполнению или повреждению данных. Для предотвращения планировщик использует комбинацию замков (sched.lock), lock-free структур (локальные очереди p), атомарных операций и протоколов владения (только владелец p может менять его runq без синхронизации). Асинхронная преемпция и кража работы также тщательно синхронизированы.

Развёрнутый ответ

Критические области и механизмы:

Глобальная очередь (sched.runq): защищена sched.lock. При добавлении/извлечении из глобальной очереди берётся блокировка.
Локальная очередь (p.runq): lock-free single-producer (владелец p) / multiple-consumer (воры). Владелец кладёт в голову, воры забирают с хвоста с использованием атомарных CAS над индексами. Гонка между владельцем и вором разрешается порядком операций: владелец обновляет tail, воры читают tail атомарно, вычисляют доступные элементы. Если владелец и вор пытаются модифицировать хвост, атомарный CAS гарантирует согласованность.
Списки idle m/p: защищены sched.lock или атомарными списками для быстрых операций (p.runnext не защищён? Он только владельцем).
Поиск работы: findrunnable проходит цепочку, каждая операция атомарна либо без гонок по дизайну (проверка глобальной очереди без блокировки? Нет, с блокировкой, но кратко). Work stealing использует runqsteal — CAS над хвостом.
Передача p при syscall: handoffp захватывает sched.lock для изменения статуса p и постановки в idle-список.
Преемпция: отправка сигнала SIGURG безопасна, но обработка флага preempt требует атомарного чтения/записи, что гарантируется выравниванием и атомарными типами.

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

Под капотом (internals)

p.runq определён как [256]guintptr; индексы head и tail выровнены. Владелец пишет tail с atomic.Store, воры читают с atomic.Load. runqput использует atomic.Cas для head? Нет, владелец не использует CAS при обычной вставке, но при переполнении и перемещении в глобальную очередь захватывается блокировка. runqsteal атомарно обновляет tail через atomic.Cas. Это классический паттерн single-producer/multiple-consumer ring buffer.

Типичные ошибки кандидатов

Считать, что весь планировщик работает под одной глобальной блокировкой.
Это разрушило бы масштабируемость; на самом деле, много операций без блокировок. Исправление: описывать lock-free подходы.
Думать, что runq полностью защищён мьютексом.
Только глобальная очередь; локальные используют lock-free. Исправление: различать.
Предполагать, что гонки могут возникать при одновременных schedule на разных p без синхронизации.
Поскольку каждый p имеет собственный runq, конкуренции нет, пока не начинается воровство. Исправление: объяснять изоляцию.
Полагать, что асинхронная преемпция может создать гонку за g.preempt.
Флаг обновляется атомарно, и проверка происходит в safe-point, где гонки исключены.

Возможные дополнительные вопросы интервьюера

Как отлаживать гонки в планировщике?
Включить -race для детектора гонок в пользовательском коде, но для самого рантайма — использовать внутреннюю трассировку и санитайзеры, поставляемые Google.
Что такое runqgrab и как он гарантирует отсутствие гонок?
Он атомарно читает head/tail, вычисляет количество, и CAS’ом обновляет tail, обеспечивая эксклюзивный доступ к области буфера.
Могут ли гонки возникнуть при добавлении горутины в глобальную очередь из разных p?
Нет, используется sched.lock.

Архитектура Runtime: ядро рантайма, GMP и аппаратная синергия

Ключевые модули исходного кода рантайма (src/runtime/)

Навигатор по вопросам главы

Что такое runtime Go?

Краткий ответ (30–60 секунд)

Развёрнутый ответ

Под капотом (internals)

Типичные ошибки кандидатов

Возможные дополнительные вопросы интервьюера

Что входит в runtime?

Краткий ответ (30–60 секунд)

Развёрнутый ответ

Под капотом (internals)

Типичные ошибки кандидатов

Возможные дополнительные вопросы интервьюера

Как runtime управляет памятью?

Краткий ответ (30–60 секунд)

Развёрнутый ответ

Под капотом (internals)

Типичные ошибки кандидатов

Возможные дополнительные вопросы интервьюера

Как runtime управляет горутинами (goroutines)?

Краткий ответ (30–60 секунд)

Развёрнутый ответ

Под капотом (internals)

Типичные ошибки кандидатов

Возможные дополнительные вопросы интервьюера

Что такое планировщик (scheduler)?

Краткий ответ (30–60 секунд)

Развёрнутый ответ

Под капотом (internals)

Типичные ошибки кандидатов

Возможные дополнительные вопросы интервьюера

Что такое sysmon?

Краткий ответ (30–60 секунд)

Развёрнутый ответ

Под капотом (internals)

Типичные ошибки кандидатов

Возможные дополнительные вопросы интервьюера

Как работает sysmon и зачем он нужен?

Краткий ответ (30–60 секунд)

Развёрнутый ответ

Под капотом (internals)

Типичные ошибки кандидатов

Возможные дополнительные вопросы интервьюера

Что такое netpoller?

Краткий ответ (30–60 секунд)

Развёрнутый ответ

Под капотом (internals)

Типичные ошибки кандидатов

Возможные дополнительные вопросы интервьюера

Как runtime взаимодействует с ОС?

Краткий ответ (30–60 секунд)

Развёрнутый ответ

Под капотом (internals)

Типичные ошибки кандидатов

Возможные дополнительные вопросы интервьюера

Что такое системный вызов (syscall)?

Краткий ответ (30–60 секунд)

Развёрнутый ответ

Под капотом (internals)

Типичные ошибки кандидатов

Возможные дополнительные вопросы интервьюера

Что такое CGO?

Краткий ответ (30–60 секунд)

Развёрнутый ответ

Под капотом (internals)

Типичные ошибки кандидатов

Возможные дополнительные вопросы интервьюера

Почему CGO дорог?

Краткий ответ (30–60 секунд)

Развёрнутый ответ

Под капотом (internals)

Типичные ошибки кандидатов

Возможные дополнительные вопросы интервьюера

Как происходит запуск программы на Go (bootstrap)?

Краткий ответ (30–60 секунд)

Развёрнутый ответ

Под капотом (internals)

Типичные ошибки кандидатов

Ключевые модули исходного кода рантайма (`src/runtime/`)

Что такое `sysmon`?

Как работает `sysmon` и зачем он нужен?

Что такое `netpoller`?

Что такое `CGO`?

Почему `CGO` дорог?

Какие основные структуры данных использует runtime (`g`, `m`, `p`, `schedt`)?

Как работает `time.Sleep`?

Как работает `runtime.LockOSThread` и когда это нужно?

Как работает `recover` и `panic` на уровне runtime?

Как устроен `channel` и его буфер в памяти (структура `hchan`)?

Как работает `select` на уровне runtime?

Как устроены `timers` и `ticker`?