Библиотека Go для собеса | вопросы с собеседований

❓ Может ли стек горутины быть ограниченным по памяти или он растёт сколько угодно

По умолчанию максимальный размер стека горутины — 1 ГБ на 64-битных системах. Это задаётся рантаймом Go и контролируется переменной runtime/debug.SetMaxStack или просто константой в рантайме.

import "runtime/debug"

debug.SetMaxStack(512 * 1024 * 1024) // установить лимит 512 МБ

Если горутина превысит этот лимит, то будет паника.

🐸 Библиотека Go для собеса

❓ Как работает механизм избирательного пробуждения горутин в sync.Cond на уровне структуры notifyList

notifyList содержит два счётчика: wait (сколько горутин встало в очередь) и notify (сколько горутин уже получили сигнал). Когда горутина вызывает Wait(), она атомарно получает текущий тикет из wait, инкрементирует wait и засыпает. Тикет — это её уникальный порядковый номер в очереди.

При вызове Signal() (который внутри вызывает notifyListNotifyOne) атомарно инкрементируется notify. Затем метод проходит по связанному списку горутин и ищет ту, чей тикет равен новому значению notify - 1. Именно она и пробуждается через goready.

Такой подход гарантирует строгий FIFO-порядок пробуждения: горутины получают управление в том же порядке, в котором вставали в очередь. Это исключает голодание и делает поведение sync.Cond предсказуемым при конкурентном доступе.

🐸 Библиотека Go для собеса

❓ Когда пригодится default в select

default в Go превращает select в неблокирующую операцию. Если ни один канал не готов, выполнение сразу идёт дальше, без ожидания.

Где это полезно:

Таймауты и поллинг — мгновенно возвращаем управление, если данные ещё не пришли, вместо того чтобы зависнуть в ожидании.

Event loop — default берёт на себя фоновые задачи и проверки состояния, пока основной поток не простаивает в блокировке.

🐸 Библиотека Go для собеса

❓ Какие состояния есть у горутины

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

Чаще всего говорят о двух состояниях живой горутины:

Работает — выполняет код, либо спит через time.Sleep, ожидает системный вызов/сеть, но с точки зрения модели конкурентности она считается работающей.​

Заблокирована — стоит на ожидании, например, по WaitGroup.Wait, чтению/записи в канал, мьютексу и не может продолжать выполнение, пока условие не выполнится.

Новая горутина после go f() стартует в работающем состоянии и может переходить в блокировку и обратно.

Внутренние статусы рантайма Go

_Gidle — горутина аллоцирована, но ещё не проинициализирована.

_Grunnable — готова к запуску, лежит в локальной или глобальной очереди планировщика.

_Grunning — сейчас исполняет пользовательский код на привязанном M и P.

_Gwaiting — заблокирована рантаймом, ожидает в очереди канала, мьютекс, GC, и не стоит в run-queue.

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

_Gcopystack — в процессе реаллокации стека, код не выполняется.

_Gpreempted — принудительно остановлена из-за тайм-слайса и будет переведена в обычное ожидание и затем в runnable.

🐸 Библиотека Go для собеса

❓ Как синхронизировать мапу

Стандартная мапа в Go не потокобезопасна — при одновременном доступе из нескольких горутин без синхронизации неизбежен race condition.

Есть три основных подхода:

sync.Mutex / sync.RWMutex — самый распространённый способ. Mutex даёт полное взаимоисключение: только одна горутина работает с мапой в каждый момент. RWMutex умнее: несколько горутин могут читать одновременно, блокировка на запись возникает только при изменениях.

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

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

Также стоит помнить про sync.Map из стандартной библиотеки — она подходит для случаев, когда ключи пишутся один раз, а читаются многократно.

🐸 Библиотека Go для собеса

Последний шанс: 3 курса по цене 1 и запуск AI-агентов в продакшн

Архитектурные вопросы на Go-собеседованиях всё чаще касаются высоких нагрузок и ИИ. Как маршрутизировать мультиагентные системы под нагрузкой, контролировать затраты на токены и не нарушить 152-ФЗ?

Обновлённая программа делает упор на жёсткий инжиниринг и вывод в прод. Вы научитесь строить ReAct-циклы, работать с LangGraph и AutoGen, внедрять продвинутый RAG, протоколы MCP и AgentOps. Все ключевые навыки в одном месте: измеримость систем, time-travel дебаггинг, управление браузером, human-in-the-loop и развёртывание в закрытых контурах.

Почему нельзя откладывать:

— масштабная акция «3 курса по цене 1» сгорает уже сегодня;
— промокод Agent на скидку 10 000 рублей действует последние часы;
— сразу после оформления открываются материалы для подготовки — начать учиться можно прямо сейчас.

Забронировать место на курсе и забрать бонусы до конца дня

❓ Чем отличается реляционная БД от нереляционной

Реляционная или SQL — это база, где данные хранятся в таблицах, между которыми есть связи через внешние ключи. Примеры: PostgreSQL, MySQL, SQLite.

Нереляционная или NoSQL — данные хранятся в других форматах: документы (MongoDB), ключ-значение (Redis), колонки (Cassandra), графы (Neo4j). Схема гибкая или вообще отсутствует, данные часто денормализованы.

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

NoSQL проще масштабировать горизонтально, они быстрее на простых операциях чтения, но жертвуют консистентностью — там eventual consistency, то есть данные не гарантированно консистентны прямо сейчас, но в конечном счёте все ноды синхронизируются и придут к одному состоянию.

🐸 Библиотека Go для собеса

❓ Чем отличается реляционная БД от нереляционной

Реляционная или SQL — это база, где данные хранятся в таблицах, между которыми есть связи через внешние ключи. Примеры: PostgreSQL, MySQL, SQLite.

Нереляционная или NoSQL — данные хранятся в других форматах: документы (MongoDB), ключ-значение (Redis), колонки (Cassandra), графы (Neo4j). Схема гибкая или вообще отсутствует, данные часто денормализованы.

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

NoSQL проще масштабировать горизонтально, они быстрее на простых операциях чтения, но жертвуют консистентностью — там eventual consistency, то есть данные не гарантированно консистентны прямо сейчас, но в конечном счёте все ноды синхронизируются и придут к одному состоянию.

🐸 Библиотека Go для собеса

❓ Может ли горутина общаться сама с собой через канал

Да, но только через буферизированный канал.

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

func main() {
    ch := make(chan int, 1) // буфер = 1

    ch <- 42       // записали, не заблокировались
    val := <-ch    // прочитали
    fmt.Println(val) // 42
}

Почему с небуферизированным не работает:

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

func main() {
    ch := make(chan int) // без буфера

    ch <- 42      // горутина блокируется здесь навсегда
    val := <-ch   // до этой строки никогда не дойдёт
    fmt.Println(val)
}
// fatal error: all goroutines are asleep - deadlock!

🐸 Библиотека Go для собеса

За год мы провели три потока курса по ИИ-агентам, а теперь запускаем масштабное обновление!

В новом, четвёртом потоке мы учли все пожелания студентов, добавили большой блок про AgentOps и сместили фокус с базовых концепций на суровый инжиниринг. Рассказать про устройство горутин на собеседовании легко, а вот заставить ИИ-агента стабильно работать под высокой нагрузкой в проде и не сливать бюджет — задача со звёздочкой.

В программе:

— практика с первого занятия: Jupyter-ноутбуки с автопроверкой;
— оркестрация в LangGraph: human-in-the-loop и механизм time-travel;
— продвинутый RAG для продакшена и парсинг сложных документов;
— контроль экономики агентов: маршрутизация и кеширование запросов;
— развёртывание локальных опенсорс-моделей с соблюдением 152-ФЗ.

В честь старта продаж действует спецпредложение: 3 курса по цене 1 (два дополнительных курса в подарок).

Доступ к материалам для предварительной подготовки откроется сразу после оплаты.

По промокоду Agent забирайте скидку 10 000 ₽ (89 000 ₽ вместо 99 000 ₽). Успейте занять место до 28 февраля!

👉 Присоединиться к четвёртому потоку и вывести агентов в прод