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

Короткий ответ: Интерфейс задаёт поведение через сигнатуры методов. Любой тип с нужным набором методов реализует его неявно. Функция, принимающая этот интерфейс, работает с разными конкретными типами, а вызов метода использует реализацию сохранённого динамического значения.

type Speaker interface{ Speak() string }
type Cat struct{}
type Dog struct{}
func (Cat) Speak() string { return "meow" }
func (Dog) Speak() string { return "woof" }

func announce(s Speaker) {
    fmt.Println(s.Speak())
}

func main() {
    announce(Cat{}) // meow
    announce(Dog{}) // woof
}

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

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

Важно: «В Go нет наследования классов» не означает «в Go нет динамической диспетчеризации». Её дают интерфейсные вызовы. Само по себе встраивание не заставляет метод внутреннего значения вызывать одноимённый внешний метод.

Источники: Документация Go 1, Документация Go 2.

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

Примеры: Парсер возвращает error для некорректного пользовательского ввода. Helper MustParse может намеренно паниковать при инициализации с фиксированным значением разработчика. Рантайм также паникует при некоторых некорректных операциях, например выходе индекса за границы.

Паника выполняет defer при раскрутке текущей горутины. Если она дошла до вершины горутины без recover, процесс завершается. Восстановление на осознанной границе может локализовать сбой — например, HTTP-сервер обрабатывает панику handler, — но нельзя выдавать неудачную операцию за успешную или считать общее состояние гарантированно целым.

Механизм не равен тяжести: Обычная возвращённая ошибка тоже может быть фатальной для приложения. Паника не доказывает повреждение всего процесса. Выбирай контракт API и границу восстановления по тому, что безопасно продолжать; не добавляй blanket recover в каждую горутину и не используй panic для обычной валидации.

Подробнее: Документация Go · Документация Go

Короткий ответ: Горутина — конкурентное выполнение, которым управляет рантайм Go. Поток ОС планируется операционной системой. Go распределяет множество горутин по потокам ОС, а стек каждой горутины может расти и уменьшаться.

Подробно:

1. Горутина запускается через go f(). Вызывающий код продолжает работу без ожидания; если завершение важно, нужна явная синхронизация.
2. Стек горутины начинается с небольшого размера (исторически около 2 КиБ в стандартном рантайме). Начальный размер и политика роста — детали реализации. Размер стека потока ОС зависит от платформы и настроек.
3. Когда горутина блокируется на канале или поддерживаемом сетевом I/O, рантайм может выполнить другую горутину на доступном потоке. Блокирующие системные вызовы и cgo могут потребовать дополнительных потоков ОС.
4. Планирование рантаймом обычно дешевле создания отдельного потока ОС на задачу. Точная стоимость и допустимое число зависят от нагрузки; горутины всё равно занимают память и удерживают объекты по ссылкам.

done := make(chan struct{})
go func() {
    fmt.Println("work")
    close(done)
}()
<-done // дождаться завершения этой горутины

Важно: Конкурентность означает возможность независимого продвижения задач, параллелизм — одновременное выполнение. Горутины дают конкурентность; число CPU и GOMAXPROCS ограничивают параллельное выполнение Go-кода. Возврат из main завершает программу без ожидания других горутин.

Источники: Документация Go 1, Документация Go 2.

Короткий ответ: Mutex допускает одну критическую секцию одновременно. RWMutex позволяет нескольким читателям работать под RLock, а Lock исключает и читателей, и других писателей. Начни с простого замка; выбирай RWMutex, когда измерения показывают пользу параллельного чтения.

Как рассуждать: Все обращения к защищаемому инварианту должны использовать один замок. Под RLock можно только читать: изменение позиции LRU или ленивая инициализация поля — уже запись. Нельзя повысить RLock до Lock; повторный захват RLock может привести к deadlock, если писатель уже ждёт.

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

Пример: Длительное чтение конфигурации может выиграть от параллельных читателей. Короткий инкремент счётчика — не обязательно. Универсального соотношения чтений и записей нет: измеряй реальную нагрузку.

Подробнее: Документация Go

Короткий ответ: GOMAXPROCS ограничивает число потоков ОС, одновременно исполняющих Go-код. Он не ограничивает число горутин, потоков в блокирующих syscall или конкурентных I/O-операций.

Значение по умолчанию зависит от версии: До Go 1.25 это было число логических CPU, доступных при старте. Go 1.25+ также может учитывать CPU affinity и, на Linux, cgroup-лимит CPU, периодически обновляя значение. Настройки совместимости для старой версии языка в модуле могут сохранять прежнее поведение.

Текущий рантайм обычно выбирает минимум из числа CPU, affinity и округлённой вверх квоты cgroup, но только из-за квоты не опускается ниже двух. Это деталь реализации: GOMAXPROCS не равен Kubernetes CPU requests и не всегда равен runtime.NumCPU().

n := runtime.GOMAXPROCS(0) // прочитать без изменения
fmt.Println(n)

Переменная окружения или runtime.GOMAXPROCS(n) с положительным значением отключают автоматические обновления. В Go 1.25+ runtime.SetDefaultGOMAXPROCS() восстанавливает значение рантайма и обновления. При диагностике throttling проверяй toolchain, версию модуля и GODEBUG.

Подробнее: Документация Go · Документация Go