Подготовка к собеседованию — Go-разработчик

Короткий ответ: Полиморфизм даёт неявная (структурная) реализация интерфейсов: тип удовлетворяет интерфейсу автоматически, если у него есть нужный набор методов — никакого implements. Вместо наследования — композиция через встраивание (embedding), а инкапсуляция — регистром первой буквы имени.

Подробно:

1. Структурная типизация (duck typing) — «если крякает как утка». Тип и интерфейс нигде явно не связывают; связь проверяется по сигнатурам методов на этапе компиляции.
2. Композиция вместо наследования — встраивание продвигает методы встроенного типа наружу, но это has-a, а не is-a.
3. Инкапсуляция — имя с заглавной буквы экспортируется, со строчной — приватно внутри пакета.

type Stringer interface{ String() string }

type Point struct{ X, Y int }

func (p Point) String() string { // Point реализует Stringer
    return fmt.Sprintf("(%d,%d)", p.X, p.Y)
} // без "implements Stringer" — достаточно совпадения метода

⚠️ Частая ошибка: называть embedding «наследованием». Здесь нет подтипов и виртуальных вызовов: внешний тип не приводится к встроенному, а метод встроенного типа не «переопределяется» и не видит полей внешнего.

Короткий ответ: Горутина — это лёгкая единица выполнения, которой управляет рантайм Go, а не ядро ОС. Её стек стартует с ~2 КБ и растёт динамически, тогда как поток ОС резервирует мегабайты фиксированного стека. Рантайм мультиплексирует тысячи горутин на небольшое число потоков по модели M:N, поэтому в одном процессе спокойно живут сотни тысяч горутин.

Подробно:

1. Стек — горутина: ~2 КБ с ростом/сжатием по мере надобности; поток ОС: фиксированные 1–8 МБ, зарезервированные заранее.
2. Планировщик — горутины планирует рантайм Go (модель GMP: G — горутина, M — поток ОС, P — процессор-контекст) в user space; потоки планирует ядро.
3. Стоимость переключения — переключение горутины не заходит в ядро и на порядки дешевле переключения контекста потока.
4. Масштаб — потоков реалистично тысячи, горутин — сотни тысяч и больше.

⚠️ Частая ошибка: ответить «это лёгкий поток» и остановиться. Без упоминания планировщика рантайма и модели M:N ответ звучит по-джуновски — интервьюер ждёт именно механику.

Короткий ответ: Mutex даёт эксклюзивный доступ — одна горутина в критической секции в любой момент. RWMutex разделяет блокировку на две: под RLock() читатели заходят параллельно, а Lock() писателя эксклюзивен и ждёт, пока все читатели выйдут. RWMutex оправдан только там, где чтений заметно больше, чем записей.

Подробно:

1. Mutex — простой замок: Lock()/Unlock(), всегда один владелец. Дефолтный выбор.
2. RWMutex — RLock() для читателей (можно много одновременно), Lock() для писателя (один, эксклюзивно).
3. Когда переходить на RWMutex — только если профилирование показало contention на чтениях и соотношение read:write велико (условно 10:1 и выше), а критическая секция не микроскопическая.

⚠️ Частая ошибка: ставить RWMutex «на всякий случай» и пугать голоданием писателей. В Go его нет: RWMutex write-preferring — ожидающий Lock() блокирует новых читателей (побочный эффект: рекурсивный RLock() в одной горутине может дать дедлок). Реальная цена — более дорогой захват: на коротких секциях обычный Mutex часто быстрее.

Короткий ответ: GOMAXPROCS задаёт число P — максимум потоков ОС, одновременно исполняющих Go-код. По умолчанию он равен числу логических CPU (runtime.NumCPU()) — так с Go 1.5.

Подробно:

1. Что именно ограничивает. Только параллельное исполнение Go-кода. Горутины, заблокированные на syscall или сетевом I/O, в лимит не входят — потоков в процессе может быть куда больше, чем GOMAXPROCS.
2. Как менять. Через переменную окружения GOMAXPROCS или в рантайме runtime.GOMAXPROCS(n).
3. Ловушка контейнеров. Исторически дефолт брал число ядер всей ноды, игнорируя CPU-лимит cgroup: на 64-ядерной ноде с лимитом «2 CPU» рантайм поднимал 64 P — лишние переключения контекста и троттлинг. Классическое лечение — uber-go/automaxprocs.
4. Свежий Go. С Go 1.25 рантайм по умолчанию учитывает CPU-лимит cgroup — на Linux дефолт округляется вверх от лимита, поэтому проверяйте версию, прежде чем тащить костыль.

// GOMAXPROCS=4 ./app — через переменную окружения
runtime.GOMAXPROCS(4)      // или в рантайме
n := runtime.GOMAXPROCS(0) // 0 — прочитать текущее значение, не меняя

⚠️ Частая ошибка: на Go < 1.25 положиться на дефолт в Kubernetes с CPU-лимитом. Без automaxprocs рантайм видит все ядра ноды, а не выделенную квоту.

Короткий ответ: Через fmt.Errorf с глаголом %w: fmt.Errorf("read config: %w", err). Именно %w вшивает исходную ошибку в цепочку Unwrap, так что errors.Is/errors.As продолжают её видеть. Глаголы %v и %s вставляют только текст и обрывают цепочку.

Подробно:

1. %w сохраняет цепочку — оборачивает ошибку, оставляя доступ к оригиналу через Unwrap. Добавляй короткий контекст: что делал код, а не пересказ ошибки.
2. %v/%s рвут цепочку — годятся только когда исходную ошибку намеренно скрываешь от вызывающего (граница абстракции).
3. Контекст по слоям — на каждом уровне добавляй свой префикс; получается читаемый след open user file: read config: permission denied.

if err != nil {
    return fmt.Errorf("read config %q: %w", path, err)
}
// errors.Is(err, os.ErrPermission) по-прежнему работает

⚠️ Частая ошибка: обрабатывать ошибку дважды — и залогировать, и вернуть её наверх. Каждый слой либо оборачивает и возвращает, либо (на самом верху) логирует — не одновременно, иначе логи задваиваются.