Открытое собеседование на Go-разработчика | Навыки

Сегодня мы разберем собеседование на позицию Go-разработчика, в ходе которого кандидат демонстрирует уверенное владение базовыми и продвинутыми концепциями языка — от горутин и каналов до работы с контекстом, интерфейсами, ошибками и механизмами синхронизации. Интервьюер последовательно углубляется в детали внутреннего устройства Go: планировщик, сборщик мусора, работа с памятью, отличия от потоков и процессов, а также затрагивает вопросы производительности, масштабирования и архитектуры распределённых систем. Кандидат показывает практический опыт и умение рассуждать о trade-offs различных решений, хотя местами допускает неточности в терминологии и поверхностно отвечает на вопросы по сетям и IPC.

Вопрос 1. Что такое слайс в Go, как он устроен и из каких элементов состоит?

Таймкод: 00:03:59

Ответ собеседника: Правильный. Слайс — это структура из трёх машинных слов: capacity, length и указатель на данные. Похож на вектор из C++. При append может выделиться новый базовый массив при нехватке capacity.

Правильный ответ:

Слайс в Go — это динамическая обёртка над массивом, которая предоставляет удобный интерфейс для работы с последовательностями элементов одного типа.

Внутреннее устройство (Slice Header)

Слайс в Go — это структура runtime.SliceHeader, которая содержит ровно три поля:

type SliceHeader struct {
    Data uintptr  // указатель на первый элемент базового массива
    Len  int      // текущая длина (количество доступных элементов)
    Cap  int      // ёмкость (количество элементов от начала среза до конца базового массива)
}

На 64-битной системе это занимает 24 байта: 8 байт на Data + 8 байт на Len + 8 байт на Cap.

Базовый массив (Backing Array)

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

arr := [5]int{10, 20, 30, 40, 50}
s1 := arr[1:4]  // [20, 30, 40], len=3, cap=4
s2 := s1[1:3]   // [30, 40], len=2, cap=2
// s1 и s2 делят один backing array — arr

Механизм роста при append

Когда вызывается append и текущей ёмкости (Cap) не хватает, происходит следующее:

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

Стратегия роста (до Go 1.17 и после немного менялась): для маленьких слайсов (cap < 256) ёмкость удваивается; для больших — растёт примерно на 25%. Точная формула в runtime:

// упрощённая логика из runtime.growslice
newcap := old.cap
if newcap < 256 {
    newcap = newcap * 2
} else {
    newcap += newcap / 4  // +25%
}

Важные нюансы и подводные камни

1. Разделяемый backing array. Два слайса, созданные из одного источника, могут неожиданно влиять друг на друга:

original := []int{1, 2, 3, 4, 5}
sub := original[1:3]  // [2, 3], cap=4
sub = append(sub, 99) // original[3] тоже станет 99!
fmt.Println(original) // [1 2 3 99 5]

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

func getFirstTwo(huge []int) []int {
    return huge[:2] // держит весь huge в памяти!
}

Решение — явное копирование:

func getFirstTwoSafe(huge []int) []int {
    result := make([]int, 2)
    copy(result, huge[:2])
    return result
}

3. Проверка на nil vs пустой слайс. Nil-слайс (var s []int) и пустой слайс (s := []int{}) — разные вещи, хотя len и cap у обоих равны 0. Nil-слайс не имеет выделенного backing array, и его Data == 0. Это влияет на поведение reflect.DeepEqual, сериализацию в JSON и сравнение.

4. Трёхиндексный срез (slice expression with cap). Начиная с Go 1.2, можно ограничить ёмкость подслайса, чтобы предотвратить перезапись элементов исходного массива:

s := []int{1, 2, 3, 4, 5}
sub := s[1:3:3]  // [2, 3], len=2, cap=2
sub = append(sub, 99) // выделит новый массив, не затронет s

Сравнение с массивом

Характеристика	Массив [N]T	Слайс []T
Размер	Фиксирован на этапе компиляции	Динамический
Передача в функцию	Копируется целиком (по значению)	Копируется заголовок (24 байта)
Сравнимость	Да (через ==)	Нет (только с nil)
Backing array	Является значением	Отдельная сущность

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

Вопрос 2. Есть ли разница в объёме передаваемых данных при передаче слайса с 10 элементами и слайса с 50 элементами (тип int64) в функцию?

Таймкод: 00:05:27

Ответ собеседника: Правильный. Разницы нет — передаётся структура слайса (length, capacity, указатель) фиксированного размера. В отличие от массивов, где размер зависит от количества элементов.

Правильный ответ:

Разницы нет. В функцию всегда передаётся только заголовок слайса (slice header), размер которого фиксирован и не зависит от количества элементов.

Детали

Заголовок слайса на 64-битной системе — это 24 байта:

┌──────────────┬──────────────┬──────────────┐
│   Data (8B)  │   Len (8B)   │   Cap (8B)   │
└──────────────┴──────────────┴──────────────┘

Неважно, содержит слайс 10 или 50 элементов типа int64 — в любом случае копируются лишь эти 24 байта. Базовый массив (backing array) при этом не копируется, а передаётся по указателю. Это делает передачу слайса в функцию O(1) по стоимости копирования.

Контраст с массивом

С массивами ситуация принципиально иная — массив в Go является значением и копируется целиком:

func processSlice(s []int64) {
    // скопировано 24 байта (slice header)
}

func processArray(a [50]int64) {
    // скопировано 50 * 8 = 400 байт!
}

func main() {
    slice := make([]int64, 50)   // 24 байта при передаче
    array := [50]int64{}          // 400 байт при передаче
    processSlice(slice)
    processArray(array)
}

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

Важный нюанс: мутация элементов

Хотя заголовок копируется, указатель Data ссылается на тот же backing array. Поэтому изменение элементов внутри функции видно вызывающей стороне:

func modify(s []int) {
    s[0] = 999  // изменит элемент в исходном backing array
}

func main() {
    data := []int{1, 2, 3}
    modify(data)
    fmt.Println(data) // [999 2 3]
}

Однако сам append внутри функции может создать новый backing array (при нехватке capacity), и оригинальный слайс вызывающей стороны этого не увидит. Если нужно изменить слайс-заголовок (len/cap/ptr), нужно либо возвращать новый слайс, либо передавать указатель на слайс *[]int.

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

Таймкод: 00:06:29

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

Правильный ответ:

Это один из самых частых источников багов в Go. Поведение зависит от типа мутации.

Изменение элементов по индексу — всегда видно снаружи

Заголовок слайса копируется при передаче в функцию, но поле Data (указатель на backing array) остаётся тем же. Поэтому любая мутация существующих элементов через индекс затрагивает общий базовый массив:

func mutateElements(s []int) {
    for i := range s {
        s[i] *= 10
    }
}

func main() {
    data := []int{1, 2, 3}
    mutateElements(data)
    fmt.Println(data) // [10 20 30]
}

Append — зависит от того, произошла ли переаллокация

append — это функция, которая возвращает новый слайс-заголовок. Этот новый заголовок записывается в локальную переменную внутри функции и не влияет на оригинальный слайс вызывающей стороны.

Случай 1: capacity хватает — переаллокации нет, но изменений всё равно не видно для len/cap

func tryAppend(s []int) {
    s = append(s, 99) // capacity достаточно, переаллокации нет
    fmt.Println("inside:", s) // [1 2 3 99]
}

func main() {
    data := make([]int, 3, 10)
    data[0], data[1], data[2] = 1, 2, 3
    tryAppend(data)
    fmt.Println("outside:", data) // [1 2 3] — длина не изменилась!
}

Даже без переаллокации оригинальный слайс data имеет len=3, и добавленный элемент 99 находится за пределами его видимой длины. Однако он физически записан в общий backing array:

func main() {
    data := make([]int, 3, 10)
    data[0], data[1], data[2] = 1, 2, 3
    tryAppend(data)
    fmt.Println(data[:4]) // [1 2 3 99] — если расширить вручную, элемент на месте
}

Случай 2: capacity не хватает — переаллокация

func reallocAppend(s []int) {
    s = append(s, 99) // capacity исчерпан, новый backing array
    s[0] = 42         // изменяет НОВЫЙ массив
}

func main() {
    data := []int{1, 2, 3} // cap=3, ровно столько же
    reallocAppend(data)
    fmt.Println(data) // [1 2 3] — ничего не изменилось
}

Как правильно изменить слайс внутри функции

Вариант 1: Вернуть новый слайс

func appendAndReturn(s []int, val int) []int {
    return append(s, val)
}

data := []int{1, 2, 3}
data = appendAndReturn(data, 4)
fmt.Println(data) // [1 2 3 4]

Вариант 2: Передать указатель на слайс

func appendViaPointer(s *[]int, val int) {
    *s = append(*s, val)
}

data := []int{1, 2, 3}
appendViaPointer(&data, 4)
fmt.Println(data) // [1 2 3 4]

Сводная таблица

Операция	Backing array тот же?	Изменения видны снаружи?
s[i] = val	Да	Да
append без переаллокации	Да	Нет (len/cap не обновлены у оригинала)
append с переаллокацией	Нет	Нет

Ключевое правило: если нужно изменить слайс (добавить/удалить элементы), всегда возвращайте новый слайс или используйте указатель на слайс.

Вопрос 4. Что произойдёт при обращении по индексу к слайсу, объявленному через var без инициализации, в цикле?

Таймкод: 00:07:56

Ответ собеседника: Правильный. Будет ошибка out of range. Слайс через var имеет len=0, cap=0, nil-указатель. Память не выделена, обращение по любому индексу вызовет панику. Нужно использовать make.

Правильный ответ:

При объявлении слайса через var без инициализации получается nil-слайс:

var s []int
// s == nil → true
// len(s) == 0
// cap(s) == 0
// s.Data == 0 (nil pointer)

Что произойдёт при обращении по индексу

Любое обращение по индексу s[i] вызовет runtime panic: index out of range [i] with length 0:

var s []int
for i := 0; i < 5; i++ {
    s[i] = i * 10 // panic: index out range [0] with length 0
}

Это происходит потому, что оператор s[i] в Go проверяет: if i >= len(s) → panic. При len == 0 любой индекс выходит за границы.

Чем nil-слайс отличается от пустого слайса

var nilSlice []int          // nil-слайс
emptySlice := []int{}       // пустой слайс (non-nil, но len=0)
madeSlice := make([]int, 0) // слайс через make (non-nil, len=0)

Все три имеют len=0 и cap=0, и обращение по индексу к любому из них вызовет panic. Однако они ведут себя по-разному в других контекстах:

fmt.Println(nilSlice == nil)  // true
fmt.Println(emptySlice == nil) // false
fmt.Println(madeSlice == nil)  // false

// JSON-сериализация
json.Marshal(nilSlice)   // null
json.Marshal(emptySlice) // []

Как правильно инициализировать слайс для записи по индексу

Вариант 1: make с заданной длиной

s := make([]int, 5) // len=5, cap=5, заполнен нулями
for i := 0; i < 5; i++ {
    s[i] = i * 10 // OK
}

Вариант 2: make с нулевой длиной и заданной capacity, затем append

s := make([]int, 0, 5) // len=0, cap=5
for i := 0; i < 5; i++ {
    s = append(s, i*10) // OK, без переаллокаций
}

Вариант 3: литерал слайса

s := []int{0, 0, 0, 0, 0} // len=5, cap=5
for i := 0; i < 5; i++ {
    s[i] = i * 10 // OK
}

Важно помнить

append работает даже с nil-слайсом, потому что append сам выделяет память, если backing array отсутствует:

var s []int           // nil-слайс
s = append(s, 1)      // OK, len=1, cap=1
s = append(s, 2)      // OK, len=2, cap=2
fmt.Println(s)        // [1 2]

Именно поэтому идиоматичный способ построить слайс — начать с var s []T или s := make([]T, 0, estimatedCap) и использовать append, а не обращение по индексу.

Вопрос 5. Потокобезопасен ли слайс в Go? Можно ли безопасно передавать слайс через каналы и использовать в нескольких горутинах?

Таймкод: 00:09:10

Ответ собеседника: Правильный. Слайс не потокобезопасен. Append из нескольких горутин приведёт к гонкам при переаллокации. Нужны мьютексы или передача только для чтения. Каналы потокобезопасны, но слайс внутри — нет.

Правильный ответ:

Слайс не является потокобезопасным. Ни одна из операций над слайсом (чтение, запись по индексу, append) не гарантирует атомарность при конкурентном доступе.

Какие именно проблемы возникают

1. Конкурентная запись по индексу — data race

Если две горутины пишут в разные индексы одного слайса, формально они обращаются к разным областям памяти, но Go race detector всё равно может зафиксировать гонку, потому что компилятор не может доказать безопасность. На практике запись в разные элементы массива — это разные адрема памяти, но формально это всё равно data race по спецификации Go memory model:

func main() {
    s := make([]int, 10)
    var wg sync.WaitGroup
    for i := 0; i < 10; i++ {
        wg.Add(1)
        go func(i int) {
            defer wg.Done()
            s[i] = i * 10 // data race!
        }(i)
    }
    wg.Wait()
}

Запуск с go run -race покажет гонку. Хотя на уровне железа запись в s[0] и s[1] — это разные адреса, по модели памяти Go любая конкурентная запись/чтение к одной и той же переменной (а слайс-заголовок — это одна переменная) без синхронизации является гонкой.

2. Конкурентный append — повреждение данных и panic

append модифицирует и заголовок (len, cap, ptr), и данные в backing array. Конкурентный append — это гарантированное повреждение памяти:

func main() {
    s := make([]int, 0, 100)
    var wg sync.WaitGroup
    for i := 0; i < 100; i++ {
        wg.Add(1)
        go func(val int) {
            defer wg.Done()
            s = append(s, val) // гонка на len, cap, Data и на данных
        }(i)
    }
    wg.Wait()
}

3. Конкурентное чтение + запись — data race

Даже если одна горутина читает, а другая пишет — это классическая гонка данных.

Способы безопасной работы со слайсом в конкурентной среде

А. Мьютекс

type SafeSlice struct {
    mu sync.RWMutex
    data []int
}

func (s *SafeSlice) Append(val int) {
    s.mu.Lock()
    defer s.mu.Unlock()
    s.data = append(s.data, val)
}

func (s *SafeSlice) Get(i int) int {
    s.mu.RLock()
    defer s.mu.RUnlock()
    return s.data[i]
}

Б. Каналы (share by communicating)

Вместо общего доступа к слайсу — передача владения через канал. После передачи слайса в канал отправитель больше не должен к нему обращаться:

func main() {
    ch := make(chan []int, 1)
    ch <- []int{1, 2, 3} // отправляем владение

    go func() {
        s := <-ch
        // теперь только эта горутина владеет s
        s = append(s, 4)
        fmt.Println(s) // [1 2 3 4]
    }()

    time.Sleep(time.Second)
}

В. sync/atomic для счётчиков (ограниченный случай)

Если нужно просто конкурентно собирать результаты, можно заранее выделить массив и использовать atomic.AddUint64 для индекса:

func main() {
    const workers = 10
    results := make([]int, workers)
    var wg sync.WaitGroup
    for i := 0; i < workers; i++ {
        wg.Add(1)
        go func(i int) {
            defer wg.Done()
            results[i] = i * 10 // безопасно — каждая горутина пишет в свой индекс
        }(i)
    }
    wg.Wait()
    fmt.Println(results)
}

Г. Паттерн fan-out с последующим merge

Каждая горутина работает со своим слайсом, результаты объединяются после завершения:

func processChunk(chunk []int) []int {
    result := make([]int, 0, len(chunk))
    for _, v := range chunk {
        result = append(result, v*2)
    }
    return result
}

func main() {
    data := make([]int, 1000)
    for i := range data {
        data[i] = i
    }

    const workers = 4
    chunkSize := len(data) / workers
    results := make([][]int, workers)
    var wg sync.WaitGroup

    for w := 0; w < workers; w++ {
        wg.Add(1)
        go func(w int) {
            defer wg.Done()
            start := w * chunkSize
            end := start + chunkSize
            results[w] = processChunk(data[start:end])
        }(w)
    }
    wg.Wait()

    // объединение — в одной горутине, безопасно
    merged := make([]int, 0, len(data)
    for _, r := range results {
        merged = append(merged, r...)
    }
}

Ключевой принцип Go: «Don't communicate by sharing memory; share memory by communicating.» Если слайс передаётся через канал и отправитель больше к нему не обращается — это безопасно. Если несколько горутин обращаются к одному слайсу — нужна синхронизация.

Вопрос 6. Как устроена строка в Go? Можно ли обратиться к строке по индексу и получить корректный символ для Unicode (кириллица, иероглифы)?

Таймкод: 00:10:31

Ответ собеседника: Правильный. Строка — это слайс байт. Обращение по индексу даёт байт, а не символ, что некорректно для многобайтовых Unicode-символов. Нужно конвертировать в []rune для индексации по символам.

Правильный ответ:

Внутреннее устройство строки

Строка в Go — это структура из двух полей (string header):

type StringHeader struct {
    Data uintptr  // указатель на массив байт
    Len  int      // длина в байтах (не в символах!)
}

На 64-битной системе это 16 байт. Строка в Go неизменяема (immutable) — после создания содержимое строки нельзя изменить.

Данные строки хранятся в кодировке UTF-8. Это значит, что разные символы занимают разное количество байт:

Диапазон кодов	Символы	Байт на символ
U+0000 — U+007F	ASCII (латиница, цифры)	1
U+0080 — U+07FF	Кириллица, арабский	2
U+0800 — U+FFFF	Иероглифы CJK, эмодзи базовые	3
U+10000 — U+10FFFF	Редкие символы, эмодзи	4

Обращение по индексу — даёт байт, а не символ

s := "Привет"
fmt.Println(s[0]) // 208 — это первый байт символа 'П', а не сам символ 'П'
fmt.Printf("%c\n", s[0]) // выведет мусор, т.к. 208 — неполный UTF-8 символ

Символ П (U+041F) в UTF-8 кодируется двумя байтами: 0xD0 0x9F. s[0] вернёт только первый байт 0xD0 (208), что само по себе не является валидным символом.

s := "Hello, 世界"
fmt.Println(len(s))   // 13, а не 9! (запятая и пробел — 1 байт каждый, каждый иероглиф — 3 байта)
fmt.Println(s[7])     // 228 — первый байт иероглифа '世'

Как правильно работать с символами

Вариант 1: конвертация в []rune

s := "Привет"
runes := []rune(s)
fmt.Println(runes[0])  // 1055 — код символа 'П'
fmt.Printf("%c\n", runes[0]) // П
fmt.Println(len(runes)) // 6 — количество символов

rune — это псевдоним для int32, представляющий один Unicode code point (один символ). Конвертация []rune(s) декодирует UTF-8 и создаёт слайс из 4 байт на символ, что увеличивает потребление памяти (для кириллицы — в 2 раза, для CJK — в 1.3 раза).

Вариант 2: итерация через range

s := "Привет"
for i, r := range s {
    fmt.Printf("index=%d, rune=%c, code=%d\n", i, r, r)
}
// index=0, rune=П, code=1055
// index=2, rune=р, code=1088
// index=4, rune=и, code=1080
// ...

При итерации через range Go автоматически декодирует UTF-8. Обратите внимание: i — это байтовый индекс, а не порядковый номер символа. Для кириллицы он увеличивается на 2.

Вариант 3: пакет utf8

import "unicode/utf8"

s := "Привет"
fmt.Println(utf8.RuneLen('П'))    // 2
fmt.Println(utf8.RuneCountInString(s)) // 6 — количество символов
r, size := utf8.DecodeRuneInString(s)
fmt.Printf("%c, занимает %d байт\n", r, size) // П, 2

Подсчёт символов

s := "Hello, 世界"

// Неправильно — вернёт количество байт:
len(s) // 13

// Правильно — количество символов:
utf8.RuneCountInString(s) // 9
len([]rune(s))            // 9 (менее эффективно по памяти)

Важный нюанс: суррогатные пары и графемные кластеры

Даже rune (code point) не всегда равен «символу» в привычном понимании. Некоторые видимые символы состоят из нескольких code points:

// Флаг страны — два regional indicator символа
flag := "🇷🇺"
fmt.Println(len([]rune(flag))) // 2 code points
fmt.Println(len(flag))          // 8 байт

// Эмодзи с модификатором кожи
wave := "👋🏽"
fmt.Println(len([]rune(wave))) // 2 code points (👋 + модификатор тона)

Для корректной работы с графемными кластерами (визуальными символами) нужна сторонняя библиотека, например github.com/rivo/uniseg.

Итого

• Строка = неизменяемый массив байт в UTF-8.
• s[i] — байт, а не символ. Для ASCII совпадает, для кириллицы/иероглифов — нет.
• []rune(s) или range — правильный способ работы с Unicode-символами.
• utf8.RuneCountInString — правильный способ подсчитать количество символов.

Вопрос 7. Как правильно обратиться к строке по символам в Go, чтобы корректно поддерживать Unicode (иероглифы, кириллицу)?

Таймкод: 00:11:14

Ответ собеседника: Правильно. Использовать for range (итерация по рунам), преобразование в []rune, или strings.Split. При for i := 0 идёт итерация по байтам, при for range — по рунам.

Правильный ответ:

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

Три основных способа

1. Конвертация в []rune — индексация по символам

s := "Hello, 世界"
runes := []rune(s)
fmt.Printf("%c\n", runes[7])  // 世
fmt.Printf("%c\n", runes[8])  // 界
fmt.Println(len(runes))        // 9

Плюсы: произвольный доступ по индексу O(1). Минусы: дополнительная аллокация (4 байта на символ вместо 1–4 в UTF-8).

2. Итерация через range — без аллокаций

s := "Привет"
for byteIdx, r := range s {
    fmt.Printf("байт %d: символ %c (U+%04X)\n", byteIdx, r, r)
}
// байт 0: символ П (U+041F)
// байт 2: символ р (U+0440)
// байт 4: символ и (U+0438)
// байт 6: символ в (U+0432)
// байт 8: символ е (U+0435)
// байт 10: символ т (U+0442)

byteIdx — это байтовое смещение в оригинальной строке, а не порядковый номер символа. Для кириллицы шаг = 2, для CJK — 3.

3. Пакет unicode/utf8 — ручное декодирование

import "unicode/utf8"

s := "Привет"
r, size := utf8.DecodeRuneInString(s)
fmt.Printf("%c, байт: %d\n", r, size) // П, 2

// Декодировать все руны по одной:
for len(s) > 0 {
    r, size := utf8.DecodeRuneInString(s)
    fmt.Printf("%c ", r)
    s = s[size:]
}
// П р и в е т

Чего делать не стоит

s := "Привет"

// НЕПРАВИЛЬНО — итерация по байтам:
for i := 0; i < len(s); i++ {
    fmt.Printf("%c", s[i]) // мусор для многобайтовых символов
}

// НЕПРАВИЛЬНО — длина в байтах:
charCount := len(s) // 12, а не 6!

Выбор подхода

Задача	Рекомендация
Пройти по всем символом	for range
Обратиться к символу по номеру	[]rune(s)[i]
Подсчитать символы	utf8.RuneCountInString
Разбить на подстроки	strings.Split (уже работает с UTF-8)
Высокая производительность без аллокаций	utf8.DecodeRuneInString

Для большинства задач for range по строке — идиоматичный и достаточно производительный способ работы с Unicode в Go.

Вопрос 8. Сколько байт занимает строка при передаче в функцию — зависит ли это от длины строки (например, 100 КБ)?

Таймкод: 00:12:17

Ответ собеседника: Правильный. Строка — структура из двух полей (длина и указатель), 16 байт на 64-битной системе. При передаче копируется только заголовок, не данные. Строки неизменяемы, capacity нет.

Правильный ответ:

Нет, размер при передаче не зависит от длины строки. В функцию копируется только string header — фиксированные 16 байт на 64-битной системе.

String Header

type StringHeader struct {
    Data uintptr  // 8 байт — указатель на данные
    Len  int      // 8 байт — длина в байтах
}

В отличие от слайса (24 байта: Data + Len + Cap), у строки нет Cap, потому что строка неизменяема и не нуждается в отслеживании ёмкости для роста.

Пример

func measureString(s string) {
    fmt.Println(unsafe.Sizeof(s)) // всегда 16 на 64-битной системе
}

func main() {
    small := "hi"
    large := strings.Repeat("x", 100_000) // 100 КБ

    measureString(small) // 16
    measureString(large) // 16
}

Данные строки (100 КБ) лежат в куче или в read-only секции (для строковых литералов), и копируется только указатель на них.

Последствия неизменяемости

Поскольку строки неизменяемы, любая операция «модификации» создаёт новую строку:

s := "Hello"
s += ", World" // создаётся НОВАЯ строка, старая "Hello" остаётся в памяти

Это безопасно для конкурентного доступа — несколько горутин могут одновременно читать одну и ту же строку без синхронизации, потому что никто не может её изменить.

Сравнение с передачей слайса

Тип	Размер заголовка (64-bit)	Копируются данные?
string	16 байт	Нет
[]int (слайс)	24 байта	Нет
[1000]int (массив)	8000 байт	Да, целиком

Именно поэтому строки и слайсы эффективно передать в функции — копируется только заголовок, а данные разделяются по ссылке.

Вопрос 9. Что такое хэш-таблица, как работает вставка и чтение, что такое коллизии и как они разрешаются?

Таймкод: 00:14:20

Ответ собеседника: Правильный. Хэш-таблица обеспечивает O(1) вставку/чтение в лучшем случае. Коллизия — когда два ключа дают одинаковый хэш. В Go используются цепочки или поиск в следующей ячейке. При удалении ячейка помечается как удалённая, чтобы не нарушить цепочку поиска.

Правильный ответ:

Хэш-таблица (Hash Map) — структура данных, обеспечивающая отображение ключ → значение со средней сложностью O(1) для вставки, поиска и удаления.

Принцип работы

1. Хеш-функция преобразует ключ в целочисленный хеш:

hash(key) → integer

2. Модульная арифметика преобразует хеш в индекс массива:

index = hash(key) % array_size

3. Данные хранятся в массиве (bucket array) по вычисленному индексу.

Операции

Вставка:

1. Вычислить hash(key)
2. Вычислить index = hash % bucket_count
3. Записать пару (key, value) в bucket[index]
4. Если bucket занят другим ключом — обработать коллизию

Чтение:

1. Вычислить hash(key)
2. Вычислить index = hash % bucket_count
3. Сравнить искомый ключ с ключом в bucket[index]
4. Если совпал — вернуть value
5. Если не совпал (коллизия) — искать по правилу разрешения коллизий

Коллизия — ситуация, когда два разных ключа дают один и тот же индекс: hash(k1) % N == hash(k2) % N.

Методы разрешения коллизий

А. Метод цепочек (Separate Chaining)

Каждый элемент массива — это связный список (или слайс) пар. При коллизии новая пара добавляется в список.

bucket[3] → ("apple", 1) → ("grape", 7) → nil
bucket[4] → ("banana", 2) → nil

Поиск: вычислить индекс, линейно пройти список. Сложность в худшем случае O(n), если все ключи попали в один bucket.

Используется в: Java HashMap, C++ unordered_map (в некоторых реализациях).

Б. Открытая адресация (Open Addressing)

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

Линейное пробирование:

index = (hash(key) + i) % N, где i = 0, 1, 2, ...

Квадратичное пробирование:

index = (hash(key) + i²) % N

Двойное хеширование:

index = (hash1(key) + i * hash2(key)) % N

Используется в: Go map, Python dict (с CPython 3.6+).

Реализация map в Go

Go использует открытую адресацию с вариацией линейного пробирования. Внутренняя структура (runtime.hmap):

type hmap struct {
    count     int        // количество элементов
    flags     uint8
    B         uint8      // log2 количества бакетов (2^B бакетов)
    noverflow uint16
    hash0     uint32     // seed для хеш-функции (рандомизация)

    buckets    unsafe.Pointer // массив бакетов
    oldbuckets unsafe.Pointer // предыдущий массив (при росте)
    nevacuate  uintptr        // прогресс эвакуации

    extra *mapextra // overflow-указатели
}

Каждый bucket — это структура из 8 пар ключ-значение:

┌────────────────────────────────────────────┐
│  tophash[8]  │ байты хешей для быстрого сравнения  │
│  keys[8]     │ ключи                               │
│  values[8]   │ значения                            │
│  overflow    │ указатель на дополнительный bucket  │
└────────────────────────────────────────────┘

При коллизии в Go:

1. Ищется следующая свободная ячейка в том же bucket.
2. Если bucket заполнен — создаётся overflow bucket (связанный список бакетов).
3. При поиске — сначала проверяется tophash (старшие байты хеша), затем полное сравнение ключей.

При удалении ячейка помечается специальным флагом (tombstone / empty), чтобы не прервать цепочку пробирования для других элементов.

Фактор загрузки (Load Factor)

Когда отношение count / bucket_count превышает порог (~6.5 для Go), таблица растёт: количество бакетов удваивается, все элементы перехешируются.

Load Factor = 6.5 → рост таблицы

Это обеспечивает амортизированную O(1) сложность операций.

Сложность

Операция	Средний случай	Худший случай
Вставка	O(1)	O(n)
Поиск	O(1)	O(n)
Удаление	O(1)	O(n)

Худший случай достигается, когда все ключи попадают в один bucket (плохая хеш-функция или атака на коллизии). Go защищается от этого рандомизацией хеш-функции через hash0 (seed, генерируемый при создании map).

Вопрос 10. Упорядочена ли map в Go? Можно ли получить ключи в порядке вставки? Появится ли ordered map в стандартной библиотеке?

Таймкод: 00:16:54

Ответ собеседника: Правильный. Map не упорядочена, порядок итерации не гарантирован. Ordered map в стандартной библиотеке пока нет, возможно появится с дженериками.

Правильный ответ:

Map в Go не упорядочена. Порядок итерации по ключам не определён и не гарантируется спецификацией языка.

Как устроена итерация по map

При вызове range по map рантайм случайным образом выбирает начальный bucket, а затем итерирует все бакеты последовательно:

// внутренняя логика runtime.mapiterinit
func mapiterinit(t *maptype, h *hmap, it *hmapiter) {
    // выбрать случайный стартовый bucket
    r := uintptr(fastrand())
    it.bucket = r & bucketMask(h.B)
    // ...
}

Это сделано намеренно — чтобы разработчики не полагались на порядок итерации. Если порядок был бы детерминированным, многие программы случайно зависели бы от него, и любое изменение в runtime могло бы сломать код.

Порядок может меняться между запусками и даже между итерациями:

m := map[string]int{"a": 1, "b": 2, "c": 3}

for k := range m {
    fmt.Print(k) // может вывести "bca", "acb", "cab" — что угодно
}

Как получить ключи в определённом порядке

Сортировка ключей:

m := map[string]int{"cherry": 3, "apple": 1, "banana": 2}

keys := make([]string, 0, len(m))
for k := range m {
    keys = append(keys, k)
}
sort.Strings(keys) // алфавитный порядок

for _, k := range keys {
    fmt.Printf("%s: %d\n", k, k, m[k])
}
// apple: 1
// banana: 2
// cherry: 3

Порядок вставки — через вспомогательную структуру:

type OrderedMap struct {
    keys   []string
    values map[string]int
}

func NewOrderedMap() *OrderedMap {
    return &OrderedMap{
        keys:   make([]string, 0),
        values: make(map[string]int),
    }
}

func (om *OrderedMap) Set(key string, value int) {
    if _, exists := om.values[key]; !exists {
        om.keys = append(.keys, key)
    }
    om.values[key] = value
}

func (om *OrderedMap) Iterate() []string {
    return om.keys // порядок вставки
}

Ordered map в стандартной библиотеке

На момент Go 1.24 (2025) в стандартной библиотеке появился пакет maps (Go 1.21+) с утилитами для работы с map, но упорядоченной map там нет.

Пакет golang.org/x/exp/maps предоставляет дополнительные функции, но тоже не содержит ordered map.

Для ordered map обычно используют:

• Собственные обёртки (как выше)
• Сторонние библиотеки, например github.com/elliotchance/orderedmap
• slices пакет (Go 1.21+) для сортировки ключей

sync.Map — тоже не упорядочена

sync.Map из стандартной библиотеки — конкуренто-безопасная map, но она тоже не гарантирует порядок итерации через .Range().

Вывод: если нужен порядок — сортируйте ключи явно или используйте вспомогательный слайс. Полагаться на порядок итерации map в Go нельзя по дизайну языка.

Вопрос 11. Как правильно объявлять map в Go — через var, make или литерал? Что будет при объявлении через var без инициализации?

Таймкод: 00:18:21

Ответ собеседника: Правильный. Через make (с указанием типа и опционально начального размера) или литерал. При var без инициализации map будет nil, запись вызовет панику. Нужно использовать make или литерал.

Правильный ответ:

Три способа объявления map

1. Через var — nil map

var m map[string]int
// m == nil → true
// len(m) == 0

Память под хеш-таблицу не выделена. Чтение из nil map безопасно (возвращает zero value), но запись вызывает panic:

var m map[string]int
v := m["key"] // OK, v = 0 (zero value)
m["key"] = 1  // panic: assignment to entry in nil map

2. Через make — пустая инициализированная map

m := make(map[string]int)       // пустая map
m := make(map[string]int, 100)  // с подсказкой начальной ёмкости

Внутри вызывается runtime.makemap, который выделяет память под bucket array. Подсказка ёмкости (второй аргумент) позволяет избежать перехеширования при известном количестве элементов.

3. Через литерал

m := map[string]int{}                    // пустая инициализированная map
m := map[string]int{"a": 1, "b": 2}      // с начальными значениями

Пустая литерал-инициализация map[string]int{} и make(map[string]int) функционально эквивалентны — обе создают выделенную хеш-таблицу.

Сравнение

Способ	nil?	Запись	Чтение	Пример
var m map[K]V	Да	Panic	Zero value	var m map[string]int
make(map[K]V)	Нет	OK	Zero value	make(map[string]int)
map[K]V{}	Нет	OK	Zero value	map[string]int{}
map[K]V{...}	Нет	OK	Значение	map[string]int{"a":1}

Когда использовать подсказку ёмкости

Если заранее известно примерное количество элементов, make(map[K]V, n) позволяет избежать многократного роста таблицы:

// Без подсказки: несколько перехеширований при добавлении 10к элементов
m := make(map[string]int)

// С подсказкой: память выделена сразу, перехеширования минимизированы
m := make(map[string]int, 10_000)

Подсказка n — это количество элементов, а не количество бакетов. Go сам вычисляет нужное число бакетов: B = ceil(log2(n / 6.5)).

Проверка на nil

var m map[string]int
if m == nil {
    fmt.Println("map не инициализирована")
}

Итого: если map будет использоваться для записи — всегда инициализируйте через make или литерал. Nil map безопасна только для чтения (что редко бывает полезно на практике).

Вопрос 12. Потокобезопасна ли map в Go? Можно ли безопасно читать из map из нескольких горутин без синхронизации?

Таймкод: 00:18:57

Ответ собеседника: Правильный. Map не потокобезопасна. Одновременное чтение безопасно только при отсутствии записи. При параллельной записи и чтении — гонка данных и panic. Нужны Mutex, RWMutex или sync.Map.

Правильный ответ:

Map в Go не является потокобезопасной ни для каких комбинаций конкурентного доступа, кроме одного исключения.

Что безопасно

Только конкурентное чтение (когда map полностью инициализирована и больше никогда не модифицируется):

// Инициализация в одной горутине, до запуска читателей
data := map[string]int{"a": 1, "b": 2}

// После этого — безопасное конкурентное чтение
for i := 0; i < 100; i++ {
    go func() {
        v := data["a"] // OK, если нет записи
    }()
}

Это работает, потому что runtime map не модирует внутренние структуры при чтении — только при записи/удалении.

Что НЕ безопасно

Конкурентная запись + чтение (даже разные ключи):

m := make(map[string]int)
go func() { m["a"] = 1 }()
go func() { _ = m["b"] }()
// fatal error: concurrent map read and map write

Конкурентная запись + запись:

m := make(map[string]int)
go func() { m["a"] = 1 }()
go func() { m["b"] = 2 }()
// fatal error: concurrent map writes

Go runtime детектирует конкурентный доступ к map и вызывает fatal error (не panic — его нельзя перехватить через recover). Это сделано намеренно: повреждение внутренней структуры хеш-таблицы может привести к непредсказуемому поведению, утечкам памяти и бесконечным циклам.

Способы безопасной работы

1. sync.RWMutex — для большинства случаев

type SafeMap struct {
    mu sync.RWMutex
    m  map[string]int
}

func NewSafeMap() *SafeMap {
    return &SafeMap{m: make(map[string]int)}
}

func (s *SafeMap) Get(key string) (int, bool) {
    s.mu.RLock()
    defer s.mu.RUnlock()
    v, ok := s.m[key]
    return v, ok
}

func (s *SafeMap) Set(key string, value int) {
    s.mu.Lock()
    defer s.mu.Unlock()
    s.m[key] = value
}

RWMutex оптимален, когда чтений значительно больше, чем записей: множество горутин могут одновременно удерживать RLock, а Lock блокирует всех.

2. sync.Map — для специфических паттернов

var m sync.Map

// Запись
m.Store("key", 42)

// Чтение
if v, ok := m.Load("key"); ok {
    fmt.Println(v.(int))
}

// Атомарное чтение-or-создание
v, loaded := m.LoadOrStore("key", 100)

sync.Map оптимизирован для двух паттернов:

• Ключи, которые пишутся один раз, но читаются много раз (кэши)
• Множество горутин читают и пишут непересекающиеся наборы ключей

sync.Map НЕ является универсальной заменой map + Mutex — при частых записях в одни и те же ключи он может быть медленнее.

3. Каналы (share by communicating)

type request struct {
    key   string
    value int
    op    string // "get" or "set"
    resp  chan response
}

type response struct {
    value int
    ok    bool
}

func mapWorker(ch chan request) {
    m := make(map[string]int)
    for req := range ch {
        switch req.op {
        case "set":
            m[req.key] = req.value
            req.resp <- response{}
        case "get":
            v, ok := m[req.key]
            req.resp <- response{v, ok}
        }
    }
}

Выбор стратегии

Сценарий	Рекомендация
Много чтений, мало записей	sync.RWMutex + map
Ключи пишутся один раз, читаются много	sync.Map
Непересекающиеся наборы ключей	sync.Map
Простота и предсказуемость	sync.Mutex + map
Высокая нагрузка с разделением по ключам	Sharded map (shard per key range)

Вопрос 13. Почему map в Go не сделали потокобезопасной по умолчанию? Какие альтернативы существуют для потокобезопасной работы с map?

Таймкод: 00:20:06

Ответ собеседня: Правильный. Из-за стоимости мьютексов — не всегда нужна потокобезопасность. Альтернативы: Mutex/RWMutex, sync.Map (хранит interface{}), каналы, lock-free подходы.

Правильный ответ:

Это уточняющий вопрос к предыдущему. Приведу дополнительные детали по причинам и альтернативам.

Почему map не потокобезопасна по умолчанию

1. Принцип нулевой стоимости (zero-cost abstraction)

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

Операции с map — одни из самых частых в типичной программе. Даже наносекундный overhead на каждую операцию суммируется в значительное замедление.

2. Гранулярность блокировки

Если бы map имела встроенный мьютекс, он защищал бы всю таблицу целико. Но на практике часто нужна синхронизация на уровне более высоких операций — например, «проверить наличие ключа, и если его нет — вычислить значение и записать» (check-then-act). Встроенный мьютекс не решал бы эту проблему:

// Даже с "потокобезопасной" map это всё равно гонка:
if _, ok := m["key"]; !ok {
    // другая горутина могла записать "key" между проверкой и записью
    m["key"] = expensiveComputation()
}

Для этого нужны явные блокировки или sync.Map.LoadOrStore.

3. Согласованность с остальными типами

Никакие встроенные типы Go (слайсы, указатели, каналы для данных) не являются потокобезопасными. Каналы потокобезопасны для передачи сообщений, но не для хранения данных. Если бы map была исключением, это нарушило бы единообразие.

Альтернативы с деталями

А. Sharded map — для высоконагруженных сценариев

Вместо одного мьютекса на всю map — несколько шардов, каждый со своим мьютексом:

const shardCount = 32

type ShardedMap struct {
    shards [shardCount]map[string]int
    mu     [shardCount]sync.RWMutex
}

func (sm *ShardedMap) getShard(key string) int {
    h := fnv32(key)
    return int(h) % shardCount
}

func (sm *ShardedMap) Get(key string) (int, bool) {
    idx := sm.getShard(key)
    sm.mu[idx].RLock()
    defer sm.mu[idx].RUnlock()
    v, ok := sm.shards[idx][key]
    return v, ok
}

func (sm *ShardedMap) Set(key string, value int) {
    idx := sm.getShard(key)
    sm.mu[idx].Lock()
    defer sm.mu[idx].Unlock()
    if sm.shards[idx] == nil {
        sm.shards[idx] = make(map[string]int)
    }
    sm.shards[idx][key] = value
}

func fnv32(key string) uint32 {
    h := uint32(2166136261)
    for i := 0; i < len(key); i++ {
        h ^= uint32(key[i])
        h *= 16777619
    }
    return h
}

Это снижает конкуренцию: горутины, работающие с разными шардами, не блокируют друг друга.

Б. Lock-free map через sync/atomic и unsafe

Для экстремальной производительности можно реализовать lock-free hash map через CAS-операции, но это крайне сложно и подвержено багам (ABA problem и т.д.). На практике используются готовые библиотеки.

В. Паттерн single writer

Одна горутина владеет map, остальные общаются с ней через каналы:

type command struct {
    action string        // "get", "set", "delete"
    key    string
    value  int
    result chan<- result
}

type result struct {
    value int
    ok    bool
}

func mapOwner(commands <-chan command) {
    m := make(map[string]int)
    for cmd := range commands {
        switch cmd.action {
        case "set":
            m[cmd.key] = cmd.value
            cmd.result <- result{}
        case "get":
            v, ok := m[cmd.key]
            cmd.result <- result{v, ok}
        case "delete":
            delete(m, cmd.key)
            cmd.result <- result{}
        }
    }
}

Этот подход идиоматичен для Go и полностью исключает гонки на уровне map.

Выбор стратегии

Сценарий	Подход
Простой случай, немного горутин	sync.Mutex + map
Много чтений, мало записей	sync.RWMutex + map
Высокая конкуренция, много ядер	Sharded map
Write-once, read-many	sync.Map
Идиоматичный Go-стиль	Каналы + single writer
Кэш с TTL	sync.Map или специализированная библиотека

Вопрос 14. Как объединить map и мьютекс в структуру для потокобезопасности? Можно ли создать обёртку над map с мьютексом?

Таймкод: 00:22:26

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

Правильный ответ:

Да, это стандартный идиоматичный подход в Go. Приведу полноценный пример с различными вариациями.

Базовая обёртка с RWMutex

type SafeMap struct {
    mu sync.RWMutex
    m  map[string]int
}

func NewSafeMap() *SafeMap {
    return &SafeMap{
        m: make(map[string]int),
    }
}

func (s *SafeMap) Get(key string) (int, bool) {
    s.mu.RLock()
    defer s.mu.RUnlock()
    v, ok := s.m[key]
    return v, ok
}

func (s *SafeMap) Set(key string, value int) {
    s.mu.Lock()
    defer s.mu.Unlock()
    s.m[key] = value
}

func (s *SafeMap) Delete(key string) {
    s.mu.Lock()
    defer s.mu.Unlock()
    delete(s.m, key)
}

func (s *SafeMap) Len() int {
    s.mu.RLock()
    defer s.mu.RUnlock()
    return len(s.m)
}

func (s *SafeMap) Keys() []string {
    s.mu.RLock()
    defer s.mu.RUnlock()
    keys := make([]string, 0, len(s.m))
    for k := range s.m {
        keys = append(keys, k)
    }
    return keys
}

Продвинутая версия: GetOrSet (check-then-act)

Частый паттерн — «если ключ есть, верни; если нет — вычисли и сохрани». Это должно быть атомарным:

func (s *SafeMap) GetOrSet(key string, fn func() int) int {
    // Сначала пробуем прочитать с read lock
    s.mu.RLock()
    if v, ok := s.m[key]; ok {
        s.mu.RUnlock()
        return v
    }
    s.mu.RUnlock()

    // Ключа нет — берём write lock
    s.mu.Lock()
    defer s.mu.Unlock()

    // Двойная проверка: другая горутина могла записать между RUnlock и Lock
    if v, ok := s.m[key]; ok {
        return v
    }

    v := fn()
    s.m[key] = v
    return v
}

Версия с дженериками (Go 1.18+)

type ConcurrentMap[K comparable, V any] struct {
    mu sync.RWMutex
    m  map[K]V
}

func NewConcurrentMap[K comparable, V any]() *ConcurrentMap[K, V] {
    return &ConcurrentMap[K, V]{m: make(map[K]V)}
}

func (c *ConcurrentMap[K, V]) Get(key K) (V, bool) {
    c.mu.RLock()
    defer c.mu.RUnlock()
    v, ok := c.m[key]
    return v, ok
}

func (c *ConcurrentMap[K, V]) Set(key K, value V) {
    c.mu.Lock()
    defer c.mu.Unlock()
    c.m[key] = value
}

func (c *ConcurrentMap[K, V]) Delete(key K) {
    c.mu.Lock()
    defer c.mu.Unlock()
    delete(c.m, key)
}

func (c *ConcurrentMap[K, V]) LoadOrSet(key K, fn func() V) V {
    c.mu.RLock()
    if v, ok := c.m[key]; ok {
        c.mu.RUnlock()
        return v
    }
    c.mu.RUnlock()

    c.mu.Lock()
    defer c.mu.Unlock()
    if v, ok := c.m[key]; ok {
        return v
    }
    v := fn()
    c.m[key] = v
    return v
}

// Использование:
// m := NewConcurrentMap[string, int]()
// m.Set("key", 42)
// v, _ := m.Get("key")

Важные нюансы

1. Не возвращайте указатели на значения из map — это обходит защиту мьютекса:

// ПЛОХО — вызывающий может менять значение без блокировки:
func (s *SafeMap) GetPtr(key string) *int {
    s.mu.RLock()
    defer s.mu.RUnlock()
    v := s.m[key] // копируем значение
    return &v      // возвращаем указатель на копию — безопасно, но бесполезно
}

// ЕЩЁ ХУЖЕ — если бы map хранила указателями:
// return s.m[key] — вызывающий получит доступ к данным без блокировки

2. Не забывайте про defer при panic — defer s.mu.RUnlock() гарантирует разблокировку даже при panic в вызывающем коде.

3. RWMutex vs Mutex: RWMutex эффективнее только когда чтений значительно больше записей (примерно 10:1 и более). При равном соотношении Mutex может быть быстрее из-за более простой внутренней реализации.

Вопрос 15. Чем отличается sync.RWMutex от обычного sync.Mutex?

Таймкод: 00:23:34

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

Правильный ответ:

sync.Mutex — исключающая блокировка: в любой момент времени только одна горутина может удерживать блокировку.

sync.RWMutex — разделяющая блокировка с двумя режимами:

Операция	Метод	Когда разрешено
Read Lock	RLock() / RUnlock()	Много горутин одновременно, пока нет писателя
Write Lock	Lock() / Unlock()	Только одна горутина, при отсутствии читателей и других писателей

Правила:

1. Множество горутин могут одновременно удерживать RLock.
2. Lock ждёт, пока все RLock не будут отпущены.
3. Пока удерживается Lock — никакие RLock не могут быть взяты.
4. Если писатель ждёт Lock, новые читатели тоже блокируются (чтобы писатель не голодал).

Внутренняя реализация (упрощённо)

type RWMutex struct {
    w           Mutex        // защищает внутреннее состояние
    writerSem   uint32       // семафор для писателей
    readerSem   uint32       // семафор для читателей
    readerCount int32        // количество активных читателей
    readerWait  int32        // количество читателей, которых нужно отпустить
}

Когда использовать RWMutex, а когда Mutex

RWMutex эффективен при:

• Соотношение чтений к записям ≥ 10:1
• Операции чтения быстрые (не удерживают RLock долго)
• Много конкурентных читателей

Mutex лучше при:

• Равном соотношении чтений и записей
• Очень коротких критических секциях (overhead RWMutex может превысить выгоду)
• Простоте кода важнее микро-оптимизации

Бенчмарк для иллюстрации

func BenchmarkMutexRead(b *testing.B) {
    var mu sync.Mutex
    m := map[string]int{"key": 42}
    b.RunParallel(func(pb *testing.PB) {
        for pb.Next() {
            mu.Lock()
            _ = m["key"]
            mu.Unlock()
        }
    })
}

func BenchmarkRWMutexRead(b *testing.B) {
    var mu sync.RWMutex
    m := map[string]int{"key": 42}
    b.RunParallel(func(pb *testing.PB) {
        for pb.Next() {
            mu.RLock()
            _ = m["key"]
            mu.RUnlock()
        }
    })
}

При 100% чтений RWMutex обычно в 3–5 раз быстрее на многоядерной системе. При 50% записей разница минимальна или в пользу Mutex.

Проблема голодания писателя (writer starvation)

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

Важно помнить

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

Вопрос 16. Можно ли пройтись по слайсу быстрее, чем по map? Почему обращение к элементу слайса может быть быстрее, чем к элементу map?

Таймкод: 00:24:58

Ответ собеседника: Правильный. Слайс быстрее — используется адресная арифметика (вычисление смещения в памяти). Map требует вызова хеш-функции при каждом обращении, что добавляет накладные расходы.

Правильный ответ:

Да, итерация по слайсу и произвольный доступ по индексу в слайсе быстрее, чем аналогичные операции с map. Причин несколько.

1. Хеш-функция

При каждом обращении к map (m[key]) Go вычисляет хеш ключа:

// Упрощённая схема доступа к map:
hash := alg.hash(key, h.hash0)   // вычисление хеша
bucket := hash & bucketMask(h.B) // определение бакета
// затем поиск в бакете с сравнением ключей

Хеш-функция для строковых ключей проходит по всем байтам строки — это O(len(key)) операций. Для слайса же адрес элемента вычисляется одной операцией арифметики:

// Упрощённая схема доступа к слайсу:
addr := slice.Data + index * elemSize

2. Локальность данных (cache locality)

Слайс — это непрерывный блок памяти. При последовательной итерации процессорный кэш работает максимально эффективно:

Память: [elem0][elem1][elem2][elem3][elem4]...
         ↑
       CPU cache line (64 байта) загружает сразу несколько элементов

Map хранит данные в бакетах, которые могут быть разбросаны по памяти. При итерации через range процессор прыгает между бакетами, что приводит к большему числу cache miss:

Бакет 0: [пара1][пара2]...  ← адрес 0x1000
Бакет 1: [пара3][пара4]...  ← адрес 0x5000
Бакет 2: [пара5]...         ← адрес 0x2000

3. Предсказуемость ветвлений (branch prediction)

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

4. Накладные расходы на сравнение ключей

При поиске в map, после вычисления хеша, нужно сравнить ключ с ключами в бакете (сначала по tophash, затем полное сравнение). Для строковых ключей — это побайтовое сравнение. В слайсе индекс — это уже готовый адрес, сравнение не нужно.

Бенчмарк для иллюстрации

func BenchmarkSliceIteration(b *testing.B) {
    s := make([]int, 10000)
    for i := range s {
        s[i] = i
    }
    b.ResetTimer()
    for i := 0; i < b.N; i++ {
        sum := 0
        for _, v := range s {
            sum += v
        }
        _ = sum
    }
}

func BenchmarkMapIteration(b *testing.B) {
    m := make(map[int]int, 10000)
    for i := 0; i < 10000; i++ {
        m[i] = i
    }
    b.ResetTimer()
    for i := 0; i < b.N; i++ {
        sum := 0
        for _, v := range m {
            sum += v
        }
        _ = sum
    }
}

Типичные результаты: итерация по слайсу в 3–8 раз быстрее, чем по map.

Когда это важно

• Горячие циклы с миллионами итераций
• Обработка данных в реальном времени
• Высокочастотные операции (парсеры, сериализация)

Когда это не важно

• Размер данных маленький (разница в наносекундах)
• Доступ по ключу, а не итерация (map O(1) vs линейный поиск в слайсе O(n))
• I/O-bound операции (база данных, сеть — они на порядки медленнее)

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

Вопрос 17. Что такое каналы в Go? Чем отличаются буферизированные и небуферизированные каналы?

Таймкод: 00:26:23

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

Правильный ответ:

Канал (channel) — типизированная очередь для безопасной передачи данных между горутинами. Реализует принцип CSP (Communicating Sequential Processes): «Don't communicate by sharing memory; share memory by communicating.»

Внутреннее устройство

Канал — это указатель на структуру runtime.hchan:

type hchan struct {
    qcount   uint           // текущее количество элементов в очереди
    dataqsiz uint           // размер буфера (0 для unbuffered)
    buf      unsafe.Pointer // кольцевой буфер
    sendx    uint           // индекс для записи
    recvx    uint           // индекка для чтения
    recvq    waitq          // очередь ожидающих получателей
    sendq    waitq          // очередь ожидающих отправителей
    lock     mutex          // защита всех полей
}

Небуферизированный канал (unbuffered)

Создаётся без указания размера: make(chan int) или make(chan int, 0).

Отправитель → [нет буфера] → Получатель

Правило синхронизации (handshake): отправка блокируется, пока кто-то не прочитает, и наоборот. Это гарантирует, что отправитель и получатель синхронизированы во времени:

ch := make(chan int)

go func() {
    ch <- 42        // блокируется, пока main не прочитает
    fmt.Println("sent")
}()

time.Sleep(time.Second)
fmt.Println(<-ch)   // 42
// "sent" напечатается после получения

Свойства:

• Ёмкость = 0
• Каждая отправка требует готового получателя
• Используется для синхронизации и сигнализации

Буферизированный канал (buffered)

Создаётся с указанием размера: make(chan int, 5).

Отправитель → [буфер: _ _ _ _ _] → Получатель

Правило: отправитель блокируется только когда буфер полон. Получатель блокируется только когда буфер пуст:

ch := make(chan int, 3)
ch <- 1 // OK, буфер: [1, _, _]
ch <- 2 // OK, буфер: [1, 2, _]
ch <- 3 // OK, буфер: [1, 2, 3]
ch <- 4 // БЛОКИРОВКА — буфер полон

go func() {
    time.Sleep(time.Second)
    fmt.Println(<-ch) // 1, буфер: [_, 2, 3]
}()
ch <- 4 // теперь OK, буфер: [4, 2, 3]

Свойства:

• Ёмкость = N (заданный размер)
• Отправитель не блокируется, пока есть место в буфере
• Получатель не блокируется, пока есть данные в буфере
• Используется для развязывания производителя и потребителя

Сравнение

Характеристика	Unbuffered	Buffered
Создание	make(chan T)	make(chan T, N)
Буфер	Нет	Кольцевой буфер размера N
Отправка без получателя	Блокируется	Не блокируется (пока буфер не полон)
Чтение без отправителя	Блокируется	Не блокируется (пока буфер не пуст)
Синхронизация	Строгая (handshake)	Ослабленная
Типичное использование	Сигнализация, синхронизация	Очереди задач, rate limiting

Закрытие канала

ch := make(chan int, 3)
ch <- 1
ch <- 2
close(ch)

// Чтение из закрытого канала:
v, ok := <-ch  // v=1, ok=true
v, ok = <-ch   // v=2, ok=true
v, ok = <-ch   // v=0 (zero value), ok=false

// Отправка в закрытый канал — panic:
// ch <- 3  // panic: send on closed channel

Важные правила:

• Только отправитель должен закрывать канал (никогда — получатель)
• Закрывать канал должен тот, кто его создал или владеет логикой отправки
• Двойное закрытие — panic
• Закрытие уже закрытого канала — panic

Направленность каналов

// Двунаправленный (по умолчанию):
ch := make(chan int)
ch <- 1
<-ch

// Только для отправки:
var sendCh chan<- int = ch
sendCh <- 1
// <-sendCh  // ошибка компиляции

// Только для чтения:
var recvCh <-chan int = ch
<-recvCh
// recvCh <- 1  // ошибка компиляции

Направленные каналы полезны для явного указания контракта функции:

// Функция только пишет в канал:
func producer(ch chan<- int) {
    for i := 0; i < 10; i++ {
        ch <- i
    }
    close(ch)
}

// Функция только читает из канала:
func consumer(ch <-chan int) {
    for v := range ch {
        fmt.Println(v)
    }
}

nil-канал

var ch chan int // nil-канал

// Отправка и чтение блокируются навсегда:
// ch <- 1   // deadlock (блокировка навсегда)
// <-ch      // deadlock (блокировка навсегда)

// close(ch) // panic: close of nil channel

Nil-каналы иногда используются для динамического отключения case в select:

var activeCh chan int    // nil — этот case никогда не сработает
var inactiveCh = make(chan int)

select {
case v := <-activeCh:    // никогда не выберется (nil)
    fmt.Println("active:", v)
case v := <-inactiveCh:  // работает нормально
    fmt.Println("inactive:", v)
}

Вопрос 18. Что происходит, если несколько горутин пишут в небуферизированный канал, и никто не читает? Как называется эта ситуация?

Таймкод: 00:28:00

Ответ собеседника: Правильный. Все горутины-отправители блокируются и ждут чтения. Это утечка горутин (goroutine leak) — горутины висят в памяти, не выполняя полезной работы. Отследить сложно, pprof не всегда помогает.

Правильный ответ:

Ситуация называется goroutine leak (утечка горутин).

Что происходит технически

При отправке в небуферизированный канал горутина-отправитель блокируется и помещается в очередь sendq структуры hchan. Она остаётся заблокированной до тех пор, пока не появится получатель. Если получатель никогда не появится — горутина висит вечно:

func main() {
    ch := make(chan int)

    // 1000 горутин пишут в канал, но никто не читает
    for i := 0; i < 1000; i++ {
        go func(val int) {
            ch <- val // блокируется навсегда
        }(i)
    }

    time.Sleep(5 * time.Second)
    // 1000 горутин зависли в памяти — goroutine leak
}

Каждая заблокированная горутина потребляет память (стек начинается с ~2 КБ, может расти). При большом количестве утечек это приводит к росту потребления памяти.

Почему это опасно

1. Горутины не собираются GC — заблокированная горутина считается живой, пока она не завершится.
2. Утечка накапливается — если горутины создаются в цикле (например, обработчики HTTP-запросов), утечка растёт со временем.
3. Сложно диагностировать — программа не падает, а просто потребляет всё больше памяти.

Как обнаружить

1. runtime.NumGoroutine():

fmt.Println("goroutines:", runtime.NumGoroutine())
// Если число постоянно растёт — есть утечка

2. pprof:

import _ "net/http/pprof"

go func() {
    log.Println(http.ListenAndServe("localhost:6060", nil))
}()

Затем: go tool pprof http://localhost:6060/debug/pprof/goroutine

3. go-leakcheck или аналоги:

import "go.uber.org/goleak"

func TestMain(m *testing.M) {
    goleak.VerifyTestMain(m)
}

Как предотвратить

А. Контекст с отменой (самый распространённый способ):

func worker(ctx context.Context, ch chan int) {
    for {
        select {
        case <-ctx.Done():
            return // корректное завершение
        case ch <- doWork():
        }
    }
}

func main() {
    ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
    defer cancel()

    ch := make(chan int)
    go worker(ctx, ch)

    // После отмены контекста горутина завершится
    <-ctx.Done()
}

Б. Буферизированный канал (если допустима потеря данных):

ch := make(chan int, 100)
// Горутина заблокируется только при полном буфере

В. select с default (non-blocking send):

select {
case ch <- value:
    // отправлено
default:
    // канал заполнен — пропускаем или обрабатываем иначе
    log.Println("channel full, dropping value")
}

Г. Закрытие канала как сигнал завершения:

func worker(ch chan int, done chan struct{}) {
    for {
        select {
        case <-done:
            return
        case ch <- doWork():
        }
    }
}

// Сигнал завершения:
close(done)

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

Вопрос 19. Какие операции с каналами безопасны, а какие вызывают панику? Можно ли писать в закрытый канал, читать из закрытого канала, закрыть канал несколько раз?

Таймкод: 00:29:20

Ответ собеседника: Правильный. Писать в закрытый канал — panic. Читать из закрытого — безопасно (оставшиеся значения, затем zero value). Закрыть дважды — panic. При нескольких писателях нужна координация (WaitGroup или отдельный канал).

Правильный ответ:

Сводная таблица операций с каналами

Операция	Состояние канала	Результат
Отправка (ch <- v)	Открыт, неполон	OK
Отправка	Открыт, полон (buffered)	Блокировка
Отправка	Открыт, нет получателя (unbuffered)	Блокировка
Отправка	Закрыт	Panic: send on closed channel
Отправка	nil	Блокировка навсегда
Чтение (<-ch)	Открыт, непуст	OK
Чтение	Открыт, пуст	Блокировка
Чтение	Закрыт, непуст	OK (оставшиеся значения)
Чтение	Закрыт, пуст	Zero value, ok=false
Чтение	nil	Блокировка навсегда
close(ch)	Открыт	OK
close(ch)	Уже закрыт	Panic: close of closed channel
close(ch)	nil	Panic: close of nil channel

Чтение из закрытого канала — подробнее

ch := make(chan int, 3)
ch <- 1
ch <- 2
close(ch)

v, ok := <-ch  // v=1, ok=true
v, ok = <-ch   // v=2, ok=true
v, ok = <-ch   // v=0, ok=false — канал пуст и закрыт
v, ok = <-ch   // v=0, ok=false — мгновенно, без блокировки

Именно поэтому for range по каналу завершается автоматически при закрытии:

for v := range ch {
    fmt.Println(v) // напечатает 1, 2, затем цикл завершится
}

Паника при отправке в закрытый канал

ch := make(chan int, 1)
close(ch)
ch <- 1 // panic: send on closed channel

Паника при двойном закрытии

ch := make(chan int)
close(ch)
close(ch) // panic: close of closed channel

Координация закрытия при нескольких писателях

Проблема: если несколько горутин пишут в один канал, кто должен его закрыть? Если одна горутина закроет канал, а другая попытается писать — panic.

Решение 1: sync.WaitGroup + отдельная горутина-закрыватель

func main() {
    ch := make(chan int)
    var wg sync.WaitGroup

    // Запускаем писателей
    for i := 0; i < 5; i++ {
        wg.Add(1)
        go func(id int) {
            defer wg.Done()
            for j := 0; j < 3; j++ {
                ch <- id*10 + j
            }
        }(i)
    }

    // Отдельная горутина закрывает канал после завершения всех писателей
    go func() {
        wg.Wait()
        close(ch)
    }()

    // Читатель
    for v := range ch {
        fmt.Println(v)
    }
}

Решение 2: канал закрытия (done channel)

func worker(id int, ch chan int, done chan struct{}) {
    defer func() {
        // Сигнализируем о завершении
        done <- struct{}{}
    }()
    for j := 0; j < 3; j++ {
        ch <- id*10 + j
    }
}

func main() {
    ch := make(chan int)
    done := make(chan struct{}, 5) // буфер = количество писателей

    for i := 0; i < 5; i++ {
        go worker(i, ch, done)
    }

    // Ждём завершения всех писателей и закрываем канал
    go func() {
        for i := 0; i < 5; i++ {
            <-done
        }
        close(ch)
    }()

    for v := range ch {
        fmt.Println(v)
    }
}

Решение 3: один писатель — один канал (fan-in)

func merge(channels ...<-chan int) <-chan int {
    merged := make(chan int)
    var wg sync.WaitGroup

    output := func(c <-chan int) {
        defer wg.Done()
        for v := range c {
            merged <- v
        }
    }

    wg.Add(len(channels))
    for _, c := range channels {
        go output(c)
    }

    go func() {
        wg.Wait()
        close(merged)
    }()

    return merged
}

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

Вопрос 20. Как работает select в Go? Для чего он используется в контексте каналов?

Таймкод: 00:32:10

Ответ собеседника: Правильный. Select аналогичен switch для каналов — ожидает готовности одного из каналов и выполняет соответствующий кейс. Используется для чтения из нескольких каналов, таймаутов, завершения горутин. Без default блокируется, с default — неблокирующий.

Правильный ответ:

select — конструкция для мультиплексирования операций с несколькими каналами. Блокируется до готовности хотя бы одного case.

Базовый синтаксис

select {
case v := <-ch1:
    fmt.Println("ch1:", v)
case v := <-ch2:
    fmt.Println("ch2:", v)
case ch3 <- 42:
    fmt.Println("sent to ch3")
case <-time.After(5 * time.Second):
    fmt.Println("timeout")
default:
    fmt.Println("no channel ready")
}

Порядок выполнения

1. Все каналы во всех case проверяются одновременно (не последовательно).
2. Если готов один case — выполняется он.
3. Если готовы несколько — выбирается случайный один (равномерное распределение).
4. Если ни один не готов:
   • С default — выполняется default (неблокирующий).
   • Без default — блокируется до готовности любого case.

Типичные паттерны

1. Таймаут

select {
case result := <-workCh:
    fmt.Println("result:", result)
case <-time.After(3 * time.Second):
    fmt.Println("timeout!")
}

Важно: time.After создаёт новый таймер при каждом вызове. В горячих циклах это приводит к утечке таймеров. Лучше использовать context.WithTimeout или time.NewTimer с ручным сбросом.

2. Завершение горутины (graceful shutdown)

func worker(workCh <-chan int, done <-chan struct{}) {
    for {
        select {
        case v := <-workCh:
            process(v)
        case <-done:
            cleanup()
            return
        }
    }
}

3. Неблокирующее чтение/запись

// Неблокирующее чтение:
select {
case v := <-ch:
    fmt.Println("got:", v)
default:
    fmt.Println("channel empty")
}

// Неблокирующая запись:
select {
case ch <- value:
    fmt.Println("sent")
default:
    fmt.Println("channel full, dropping")
}

4. Fan-in (мультиплексирование нескольких каналов)

func fanIn(ch1, ch2 <-chan int) <-chan int {
    out := make(chan int)
    go func() {
        for {
            select {
            case v := <-ch1:
                out <- v
            case v := <-ch2:
                out <- v
            }
        }
    }()
    return out
}

5. Ticker + работа + завершение

ticker := time.NewTicker(1 * time.Second)
defer ticker.Stop()

for {
    select {
    case <-ticker.C:
        doPeriodicWork()
    case <-ctx.Done():
        return
    }
}

Случайный выбор при готовности нескольких каналов

ch1 := make(chan int, 1)
ch2 := make(chan int, 1)
ch1 <- 1
ch2 <- 2

// 50/50 — какой case сработает:
select {
case v := <-ch1:
    fmt.Println("ch1:", v)
case v := <-ch2:
    fmt.Println("ch2:", v)
}

Случайность — важное свойство. Если бы select всегда выбирал первый готовый case, это приводило бы к голоданию последних case.

Пустой select

select {}
// Блокируется навсегда — эквивалентно для создания deadlock
// Иногда используется намеренно, чтобы горутина не завершалась

Select с nil-каналом

Nil-канал никогда не готов, поэтому соответствующий case никогда не сработает:

var ch1 chan int     // nil
ch2 := make(chan int, 1)
ch2 <- 1

select {
case v := <-ch1:     // никогда не выберется
    fmt.Println("ch1:", v)
case v := <-ch2:     // сработает
    fmt.Println("ch2:", v)
}

Это используется для динамического включения/выключения case:

var activeCh <-chan int  // nil — отключён

// Позже можно активировать:
activeCh = realChannel

select {
case v := <-activeCh:    // работает только когда activeCh != nil
    process(v)
case <-ctx.Done():
    return
}

Ограничение select

Все case в select должны быть операциями с каналами (отправка или чтение). Нельзя использовать произвольные условия — в отличие от switch.

Вопрос 21. Для чего используется пакет context в Go? Какие возможности даёт создание дочерних контекстов?

Таймкод: 00:33:22

Ответ собеседника: Правильный. Context управляет жизненным циклом горутин — сигнал отмены через всё приложение. Используется для graceful shutdown (SIGTERM), хранения значений (ID пользователя), передачи по цепочке вызовов. Дочерние контексты наследуют отмену родителя.

Правильный ответ:

Пакет context решает три задачи: распространение сигнала отмены, управление дедлайнами и передача scoped-данных через границы API.

Интерфейс context.Context

type Context interface {
    Deadline() (deadline time.Time, ok bool)
    Done() <-chan struct{}
    Err() error
    Value(key any) any
}

• Done() — канал, закрывающийся при отмене контекста
• Err() — причина отмены (context.Canceled или context.DeadlineExceeded)
• Deadline() — дедлайн, если установлен
• Value() — получение значения по ключу

Три функции создания дочерних контекстов

1. context.WithCancel — ручная отмена

ctx, cancel := context.WithCancel(parentCtx)
defer cancel() // отменяет ctx и все его потомков

go func() {
    select {
    case <-ctx.Done():
        cleanup()
        return
    case result := <-doWork():
        process(result)
    }
}()

// Где-то в другом месте:
cancel() // отменяет всех потомков ctx

2. context.WithTimeout — отмена по таймауту

ctx, cancel := context.WithTimeout(parentCtx, 5*time.Second)
defer cancel()

result, err := database.Query(ctx, "SELECT ...")
if errors.Is(err, context.DeadlineExceeded) {
    log.Println("query timed out")
}

3. context.WithDeadline — отмена к конкретному времени

ctx, cancel := context.WithDeadline(parentCtx, time.Now().Add(5*time.Second))
defer cancel()

4. context.WithValue — передача значений

type contextKey string

const userIDKey contextKey = "userID"

func middleware(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        userID := authenticate(r)
        ctx := context.WithValue(r.Context(), userIDKey, userID)
        next.ServeHTTP(w, r.WithContext(ctx))
    })
}

func handler(w http.ResponseWriter, r *http.Request) {
    userID := r.Context().Value(userIDKey).(int)
    // используем userID
}

Иерархия контекстов и каскадная отмена

context.Background()
    └── ctx1, cancel1 := WithCancel(parent)
        ├── ctx2, cancel2 := WithTimeout(ctx1, 5s)
        │   └── ctx4 := WithValue(ctx2, "key", "val")
        └── ctx3 := WithValue(ctx1, "other", 42)

При вызове cancel1():

• Отменяются ctx1, ctx2, ctx3, ctx4 — все потомки.
• Но ctx2 также может быть отранён по своему таймауту (5 секунд), независимо от cancel1.

Важно: отмена распространяется только вниз (от родителя к потомкам). Отмена потомка НЕ отменяет родителя.

Graceful shutdown — типичный пример

func main() {
    ctx, stop := signal.NotifyContext(context.Background(), syscall.SIGINT, syscall.SIGTERM)
    defer stop()

    srv := &http.Server{Addr: ":8080", Handler: handler}

    go func() {
        if err := srv.ListenAndServe(); err != nil && err != http.ErrServerClosed {
            log.Fatal(err)
        }
    }()

    <-ctx.Done() // ждём SIGTERM/SIGINT
    log.Println("shutting down...")

    shutdownCtx, cancel := context.WithTimeout(context.Background(), 10*time.Second)
    defer cancel()

    if err := srv.Shutdown(shutdownCtx); err != nil {
        log.Fatal("shutdown error:", err)
    }
    log.Println("stopped")
}

Цепочка отмены в HTTP-сервере

// Каждый HTTP-запрос получает свой контекст, привязанный к соединению
// При обрыве соединения контекст отменяется автоматически

func handler(w http.ResponseWriter, r *http.Request) {
    ctx := r.Context()

    // Передаём контекст вниз по цепочке:
    result, err := service.GetData(ctx, id)
    // service передаёт ctx в repository, repository — в database driver
    // Если клиент закрыл соединение — все уровни получат сигнал отмены
}

Правила использования context.Value

• Используйте для request-scoped данных (request ID, user ID, trace ID)
• НЕ используйте для передачи обязательных параметров функции — это ухудшает читаемость
• Ключ должен быть неэкспортируемым типом (чтобы избежать коллизий):

// ПРАВИЛЬНО:
type contextKey string
const userIDKey contextKey = "userID"

// НЕПРАВИЛЬНО:
const userIDKey = "userID" // string — любой пакет может использовать тот же ключ

Антипаттерны

type Server struct {
    ctx context.Context  // контекст должен передаваться как аргумент
}

// ПРАВИЛЬНО:
func (s *Server) Handle(ctx context.Context, req Request) {
    // ctx передаётся как первый аргумент
}

// ПЛОХО: передача nil контекста
http.NewRequest("GET", url, nil) // context будет nil

// ПРАВИЛЬНО:
http.NewRequestWithContext(context.Background(), "GET", url, nil)

Вопрос 22. Что лучше хранить в контексте, а что лучше передавать явно как аргументы функции?

Таймкод: 00:34:23

Ответ собеседника: Правильный. В контексте не стоит хранить всё подряд. Лучше передавать явно или собирать в структуру. В контексте уместны cross-cutting concerns (request ID, токены), но не бизнес-логика.

Правильный ответ:

Это уточняющий вопрос к предыдущему. Приведу краткую структурированную сводку с конкретными рекомендациями.

Хранить в context.Value — cross-cutting concerns

Это данные, которые пронизывают все уровни приложения и не относятся к бизнес-логике:

// ✅ Уместно в контексте:
- Request ID / Trace ID (для сквозной трассировки)
- User ID / Auth token (из middleware авторизации)
- Locale / Language
- Таймстарт запроса (для логирования длительности)
- Фича-флаги (feature flags)

Передавать явно как аргументы — бизнес-параметры

// ✅ Явные аргументы:
func (s *Service) CreateOrder(ctx context.Context, userID int, items []Item) (*Order, error)
func (r *Repo) GetUser(ctx context.Context, userID int) (*User, error)

// ❌ Не через контекст:
func (s *Service) CreateOrder(ctx context.Context) (*Order, error) {
    userID := ctx.Value(userIDKey).(int) // антипаттерн!
    items := ctx.Value(itemsKey).([]Item) // антипаттерн!
}

Почему явные аргументы лучше для бизнес-параметров

Критерий	context.Value	Явные аргументы
Типобезопасность	Нет (type assertion)	Да (проверка компилятором)
Документирование	Невидимо в сигнатуре	Явно видно
Тестирование	Нужно мокать context	Передать напрямую
Рефакторинг	Легко пропустить	Компилятор подскажет
Читаемость	Скрытая зависимость	Явная зависимость

Много аргументов — структура

Если у функции слишком много параметров (более 4–5), соберите их в структуру:

type CreateOrderParams struct {
    UserID   int
    Items    []Item
    Currency string
    Coupon   string
}

func (s *Service) CreateOrder(ctx context.Context, params CreateOrderParams) (*Order, error) {
    // ...
}

Антипаттерн: «context as a bag of everything»

// ❌ Плохо — context как мусорка:
ctx := context.WithValue(ctx, "logger", logger)
ctx = context.WithValue(ctx, "db", dbPool)
ctx = context.WithValue(ctx, "cache", cache)
ctx = context.WithValue(ctx, "config", cfg)
ctx = context.WithValue(ctx, "metrics", metrics)

Это делает код непрозрачным: невозпонять, какие зависит от контекста, без его полного анализа.

Правило

> Если параметр нужен для выполнения бизнес-логики — передавайте явно. Если параметр нужен для инфраструктурных задач (логирование, трассировка, авторизация) и проходит через множество слоёв — допустимо в контексте.

Вопрос 23. Зачем создавать дочерние контексты, а не использовать один родительский? Как работает каскадная отмена при отмене родительского контекста?

Таймкод: 00:35:56

Ответ собеседника: Правильный. Дочерние контексты нужны для управления временем жизни отдельных операций. Отмена родителя каскадно отменяет всех потомков. Отмена потомка не затрагивает родителя. Удобно для параллельных запросов к сервисам.

Правильный ответ:

Это уточняющий вопрос к предыдущим. Приведу краткую сводку с дополнительными примерами.

Зачем нужны дочерние контексты

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

1. Разные таймауты для разных операций

func handleRequest(ctx context.Context) {
    // Общий таймаут запроса — 10 секунд
    ctx, cancel := context.WithTimeout(ctx, 10*time.Second)
    defer cancel()

    // Запрос к БД — свой таймаут 2 секунды
    dbCtx, dbCancel := context.WithTimeout(ctx, 2*time.Second)
    defer dbCancel()
    user, err := db.GetUser(dbCtx, userID)

    // Запрос к внешнему API — свой таймаут 5 секунд
    apiCtx, apiCancel := context.WithTimeout(ctx, 5*time.Second)
    defer apiCancel()
    data, err := apiClient.Fetch(apiCtx, params)
}

2. Независимая отмена параллельных операций

func fetchFromMultipleSources(ctx context.Context) {
    ctx1, cancel1 := context.WithCancel(ctx)
    ctx2, cancel2 := context.WithCancel(ctx)

    // Если первый источник ответил — отменяем второй
    go func() {
        result := fetchSource1(ctx1)
        if result.IsComplete() {
            cancel2() // отменяем только source2
        }
    }()

    go func() {
        fetchSource2(ctx2)
    }()
}

3. Каскадная отмена

context.Background()
    └── requestCtx (отменяется при обрыве соединения)
        ├── dbCtx (отменяется через 2с ИЛИ при отмене requestCtx)
        └── apiCtx (отменяется через 5с ИЛИ при отмене requestCtx)

При отмене requestCtx:

• dbCtx.Done() закрывается
• apiCtx.Done() закрывается
• Все горутины, слушающие эти контексты, получают сигнал отмены

При отмене dbCtx (по таймауту):

• requestCtx НЕ отменяется
• apiCtx НЕ отменяется
• Продолжают работать

Пример: HTTP-сервис с каскадной отменой

func handler(w http.ResponseWriter, r *http.Request) {
    // Контекст запроса — отменяется при обрыве соединения
    ctx := r.Context()

    // Параллельные запросы к сервисам с индивидуальными таймаутами
    userCh := getUser(ctx, userID)
    ordersCh := getOrders(ctx, userID)

    // Ждём оба результата
    user := <-userCh
    orders := <-ordersCh

    respondJSON(w, user, orders)
}

func getUser(ctx context.Context, id int) <-chan *User {
    ch := make(chan *User, 1)
    go func() {
        // Свой таймаут для этого конкретного вызова
        callCtx, cancel := context.WithTimeout(ctx, 1*time.Second)
        defer cancel()
        user, _ := userRepo.Get(callCtx, id)
        ch <- user
    }()
    return ch
}

Если клиент закрыл соединение — r.Context().Done() закрывается → закрываются все дочерние callCtx.Done() → все параллельные запросы отменяются.

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

Вопрос 24. Что делает default в конструкции select? Для чего он используется?

Таймкод: 00:38:00

Ответ собеседника: Правильный. Default выполняется, если ни один из каналов не готов. Он предотвращает блокировку — если ни один case не может выполниться, выполняется default и программа продолжает работу.

Правильный ответ:

default в select делает его неблокирующим. Если ни один каналов не готов — выполняется default вместо блокировки.

Сравнение

// Без default — блокирующий select:
select {
case v := <-ch:
    fmt.Println("got:", v)
}
// Блокируется, пока ch не будет готов

// С default — неблокирующий select:
select {
case v := <-ch:
    fmt.Println("got:", v)
default:
    fmt.Println("channel not ready")
}
// Если ch не готов — сразу выполняется default

Типичные применения

1. Неблокирующее чтение из канала

func tryReceive(ch <-chan int) (int, bool) {
    select {
    case v := <-ch:
        return v, true
    default:
        return 0, false
    }
}

2. Неблокирующая отправка в канал

func trySend(ch chan<- int, val int) bool {
    select {
    case ch <- val:
        return true
    default:
        return false // канал полон
    }
}

3. Проверка завершения без блокировки

func isDone(ctx context.Context) bool {
    select {
    case <-ctx.Done():
        return true
    default:
        return false
    }
}

4. Non-blocking graceful shutdown

func worker(workCh <-chan Task, shutdownCh <-chan struct{}) {
    for {
        select {
        case task := <-workCh:
            process(task)
        case <-shutdownCh:
            return
        default:
            // Нет задач и нет сигнала завершения
            // Можно сделать что-то полезное или поспать
            runtime.Gosched()
        }
    }
}

5. Слияние каналов с приоритетом

func priorityMerge(highPrio, lowPrio <-chan int) {
    for {
        select {
        case v := <-highPrio:
            process(v) // высокий приоритет — всегда проверяется первым
        default:
            select {
            case v := <-highPrio:
                process(v)
            case v := <-lowPrio:
                process(v) // низкий приоритет — только если highPrio пуст
            }
        }
    }
}

Важный нюанс

default выполняется мгновенно, без ожидания. Это значит, что в цикле без time.Sleep или runtime.Gosched() он создаёт busy-waiting — горутина крутится на полной скорости, потребляя CPU:

// ПЛОХО — busy waiting, 100% CPU:
for {
    select {
    case v := <-ch:
        process(v)
    default:
        // ничего — сразу следующая итерация
    }
}

// ЛУЧШЕ — добавить паузу:
for {
    select {
    case v := <-ch:
        process(v)
    default:
        time.Sleep(10 * time.Millisecond) // или runtime.Gosched()
    }
}

В большинстве случаев лучше использовать блокирующий select (без default) — он не потребляет CPU, пока нет работы.

Вопрос 25. Как называется паттерн, при котором горутина периодически отправляет сигнал о том, что она жива, и что делать, если она перестаёт отвечать?

Таймкод: 00:38:21

Ответ собеседника: Правильный. Это паттерн heartbeat (сердцебиение). Горутина периодически отправляет сообщение в канал. Если сообщение не пришло в течение таймаута — горутину нужно пересоздать или завершить через контекст.

Правильный ответ:

Heartbeat (сердцебиение) — паттерн мониторинга живости горутин и долгоживущих процессов.

Базовая реализация

func worker(ctx context.Context, heartbeatInterval time.Duration) <-chan struct{} {
    beat := make(chan struct{}, 1)

    go func() {
        defer close(beat)
        ticker := time.NewTicker(heartbeatInterval)
        defer ticker.Stop()

        for {
            select {
            case <-ctx.Done():
                return
            case <-ticker.C:
                select {
                case beat <- struct{}{}: // отправляем heartbeat
                default: // если читатель не успел прочитать — пропускаем
                }
            }
        }
    }()

    return beat
}

Мониторинг с таймаутом

func monitor(ctx context.Context, beat <-chan struct{}, timeout time.Duration) {
    for {
        select {
        case <-ctx.Done():
            return
        case _, ok := <-beat:
            if !ok {
                log.Println("heartbeat channel closed — worker died")
                return
            }
            log.Println("worker is alive")
        case <-time.After(timeout):
            log.Println("heartbeat timeout — worker is stuck!")
            // Действия: перезапуск, алерт, отмена контекста
            return
        }
    }
}

Продвинутая версия: heartbeat с полезной нагрузкой

type WorkerStatus struct {
    WorkerID  int
    Timestamp time.Time
    TasksDone int
    MemoryMB  float64
}

func advancedWorker(ctx context.Context, id int) <-chan WorkerStatus {
    ch := make(chan WorkerStatus, 1)

    go func() {
        defer close(ch)
        ticker := time.NewTicker(5 * time.Second)
        defer ticker.Stop()
        tasksDone := 0

        for {
            select {
            case <-ctx.Done():
                return
            case <-ticker.C:
                tasksDone++
                status := WorkerStatus{
                    WorkerID:  id,
                    Timestamp: time.Now(),
                    TasksDone: tasksDone,
                    MemoryMB:  getMemoryUsage(),
                }
                select {
                case ch <- status:
                default:
                }
            }
        }
    }()

    return ch
}

Heartbeat в распределённых системах

В микросервисной архитектуре heartbeat используется для health checking:

// Сервис отправляет heartbeat в service discovery
func registerWithHeartbeat(serviceName, addr string) {
    ticker := time.NewTicker(10 * time.Second)
    defer ticker.Stop()

    for range ticker.C {
        err := discoveryClient.Register(serviceName, addr, 30*time.Second)
        if err != nil {
            log.Printf("heartbeat failed: %v", err)
        }
    }
}

// Если heartbeat не пришёл в течение TTL (30с) — service discovery
// удаляет инстанс из реестра

Что делать при пропаже heartbeat

Стратегия	Описание
Перезапуск	Отменить контекст, создать новую горутину
Алерт	Отправить уведомление в мониторинг
Circuit breaker	Прекратить отправку запросов к упавшему воркеру
Graceful degradation	Переключиться на резервный обработчик

Важно: буфер канала heartbeat должен быть 1 (или использовать non-blocking send), чтобы медленный читатель не блокировал отправителя.

Вопрос 26. Как работают интерфейсы в Go? Чем они отличаются от абстрактных классов в C++? Что такое утиная типизация?

Таймкод: 00:40:06

Ответ собеседника: Правильный. Интерфейсы похожи на абстрактные классы C++, но работают иначе. В C++ — таблица виртуальных функций. В Go — утиная типизация: если тип реализует все методы интерфейса, он ему удовлетворяет автоматически. Пустой интерфейс — два машинных слова: указатель на тип и указатель на данные.

Правильный ответ:

Интерфейс в Go — набор сигнатур методов. Любой тип, реализующий все методы этого набора, автоматически удовлетворяет интерфейсу — без явного объявления.

Утиная типизация (Duck Typing)

> «Если это ходит как утка и крякает как утка — значит, это утка.»

type Speaker interface {
    Speak() string
}

type Dog struct{}
func (d Dog) Speak() string { return "Woof!" }

type Cat struct{}
func (c Cat) Speak() string { return "Meow!" }

// Dog и Cat НЕ объявляют, что реализуют Speaker
// Но компилятор видит, что у них есть Speak() string → они реализуют Speaker

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

makeSound(Dog{}) // "Woof!"
makeSound(Cat{}) // "Meow!"

Внутреннее устройство интерфейса

Интерфейс — это структура из двух указателей (interface table / itable):

type iface struct {
    tab  *itab          // указатель на таблицу методов + информация о типе
    data unsafe.Pointer // указатель на данные (значение)
}

itab содержит:

• Метаданные интерфейса (какие методы он требует)
• Метаданные конкретного типа
• Таблицу функций (vtable) — указатели на реальные реализации методов

type itab struct {
    inter *interfacetype  // тип интерфейса
    _type *_type          // конкретный тип
    hash  uint32          // хеш типа (для быстрого сравнения в map)
    _     [4]byte
    fun   [1]uintptr      // таблица указателей на методы (переменная длина)
}

Пустой интерфейс interface{} (или any с Go 1.18)

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

Пустой интерфейс не требует методов, поэтому любой тип ему удовлетворяет. Используется для хранения значений произвольного типа:

func printAny(v any) {
    fmt.Printf("type=%T, value=%v\n", v, v)
}

printAny(42)       // type=int, value=42
printAny("hello")  // type=string, value=hello

Отличия от абстрактных классов C++

Характеристика	Go интерфейсы	C++ абстрактные классы
Явное объявление	Нет (implicit)	Да (class Dog : public Animal)
Множественная реализация	Да, автоматически	Да, но с проблемой ромба
Встраивание (embedding)	Да (composition)	Да (inheritance)
Диспетчеризация	Через itable (runtime)	Через vtable (compile-time)
Значение vs ссылка	Интерфейс хранит копию или указатель	Обычно через указатель/ссылку
Generics	Через type parameters	Через templates

Type assertion и type switch

var v interface{} = "hello"

// Type assertion:
s := v.(string)          // s = "hello"
n, ok := v.(int)         // n = 0, ok = false (безопасная форма)

// Type switch:
switch val := v.(type) {
case string:
    fmt.Println("string:", val)
case int:
    fmt.Println("int:", val)
default:
    fmt.Printf("unknown: %T\n", val)
}

Embedding интерфейсов

type Reader interface {
    Read(p []byte) (n int, err error)
}

type Writer interface {
    Write(p []byte) (n int, err error)
}

type ReadWriter interface {
    Reader  // встраиваем Reader
    Writer  // встраиваем Writer
}

// ReadWriter требует Read() И Write()

Type constraints с дженериками (Go 1.18+)

// Ограничение через интерфейс:
func Min[T constraints.Ordered](a, b T) T {
    if a < b {
        return a
    }
    return b
}

// Собственный constraint:
type Stringer interface {
    String() string
}

func PrintAll[T Stringer](items []T) {
    for _, item := range items {
        fmt.Println(item.String())
    }
}

Ключевые преимущества подхода Go

1. Ортогональность: типы и интерфейсы определяются в разных пакетах. Можно сделать существующий тип совместимым с интерфейсом, не меняя его код.
2. Композиция вместо наследования: нет иерархий, нет проблемы ромба.
3. Маленькие интерфейсы: идиома Go — интерфейсы с 1–3 методами (io.Reader, io.Writer, error).

Вопрос 27. Можно ли любой тип данных преобразовать к пустому интерфейсу (interface{}) в Go?

Таймкод: 00:41:48

Ответ собеседника: Правильный. Да, к пустому интерфейсу можно преобразовать любой тип — структуры, int, слайсы. Пустой интерфейс не предъявляет требований, любой тип ему соответствует.

Правильный ответ:

Да, абсолютно любой тип может быть присвоен переменной типа interface{} (или any).

var v any

v = 42             // int
v = "hello"        // string
v = 3.14           // float64
v = []int{1, 2, 3} // slice
v = map[string]int{"a": 1} // map
v = struct{ Name string }{Name: "Go"} // struct
v = func() {}      // function
v = make(chan int) // channel
v = nil            // nil

Что происходит при присваивании

При присваивании значения интерфейсной переменной создаётся eface:

type eface struct {
    _type *runtime._type  // указатель на метаданные типа
    data  unsafe.Pointer  // указатель на копию данных
}

Для значимых типов (int, struct) данные копируются. Для ссылочных типов (map, slice, channel) копируется указатель на разделяемые данные.

Извлечение значения обратно — type assertion

v := any(42)

// Безопасная форма:
if n, ok := v.(int); ok {
    fmt.Println("int:", n) // int: 42
}

// Небезопасная форма (panic при несовпадении):
n := v.(int) // panic, если v не int

Пустой интерфейс в стандартной библиотеке

// fmt.Println принимает ...any
func Println(a ...any) (n int, err error)

// json.Marshal принимает any
func Marshal(v any) ([]byte, error)

// context.WithValue хранит any
func WithValue(parent Context, key, val any) Context

Ограничения

Хотя любой тип можно положить в interface{}, обратно нужно явное приведение:

var v any = 42
// n := v + 1  // ошибка компиляции: v имеет тип any, а не int
n := v.(int) + 1 // OK

Это делает interface{} менее типобезопасным — ошибки обнаруживаются в runtime, а не на этапе компиляции. С появлением дженериков (Go 1.18+) необходимость в interface{} значительно снизилась.

Вопрос 28. Зачем нужен пустой интерфейс (interface{}) в Go, если есть дженерики? Приведите пример использования.

Таймкод: 00:42:54

Ответ собеседника: Правильный. Пустой интерфейс нужен, когда тип неизвестен заранее. Пример — канал с сообщениями разных типов (execute, cancel) с type switch на стороне получателя. Также map со значениями разных типов. Дженерики не всегда заменяют пустой интерфейс.

Правильный ответ:

Дженерики и any решают разные задачи. Дженерики — когда тип параметризован, но известен на этапе компиляции. any — когда тип действительно произвольный и определяется только в runtime.

Когда дженерики не заменяют any

1. Гетерогенные коллекции — хранение разных типов в одной структуре

// Дженерик не поможет — все элементы должны быть одного типа
// Здесь нужен any:
type Event struct {
    Type string
    Data any // может быть OrderEvent, UserEvent, PaymentEvent...
}

func handleEvent(e Event) {
    switch data := e.Data.(type) {
    case OrderEvent:
        processOrder(data)
    case UserEvent:
        processUser(data)
    case PaymentEvent:
        processPayment(data)
    default:
        log.Printf("unknown event type: %T", data)
    }
}

2. Каналы с разными типами сообщений

type Message struct {
    Action string
    Payload any
}

func dispatcher(ch <-chan Message) {
    for msg := range ch {
        switch msg.Action {
        case "create_order":
            order := msg.Payload.(OrderRequest)
            createOrder(order)
        case "cancel":
            cancelID := msg.Payload.(int)
            cancel(cancelID)
        }
    }
}

3. Рефлексия и сериализация

// encoding/json работает с произвольными типами через any
func processJSON(input []byte) error {
    var data any
    if err := json.Unmarshal(input, &data); err != nil {
        return err
    }
    // data может быть map, slice, float64, string, bool, nil
    // в зависимости от JSON-структуры
    return nil
}

4. Ключи контекста с разными типами значений

ctx := context.WithValue(ctx, "userID", 42)       // int
ctx = context.WithValue(ctx, "traceID", "abc-123") // string
ctx = context.WithValue(ctx, "startTime", time.Now()) // time.Time

5. Функции-утилиты для работы с произвольными данными

// Логирование произвольных аргументов
func logFields(fields map[string]any) {
    for k, v := range fields {
        fmt.Printf("%s: %v (%T)\n", k, v, v)
    }
}

logFields(map[string]any{
    "user_id":   42,
    "name":      "Alice",
    "is_active": true,
    "tags":      []string{"admin", "vip"},
})

Когда дженерики лучше any

// ✅ Дженерик — тип известен при вызове:
func Min[T constraints.Ordered](a, b T) T {
    if a < b { return a }
    return b
}

// ✅ any — тип неизвестен, нужна обработка в runtime:
func prettyPrint(v any) string {
    b, _ := json.MarshalIndent(v, "", "  ")
    return string(b)
}

Сравнение

Сценарий	Дженерики	any
Тип известен при вызове	✅	❌ (нужен type assertion)
Разные типы в одной коллекции	❌	✅
Типобезопасность на этапе компиляции	✅	❌
Работа с рефлексией/JSON	❌	✅
Производительность (без boxing)	✅	❌ (аллокация при приведении)

Вывод: дженерики сократили использование any, но не устранили его полностью. any незаменим там, где типы действительно гетерогенны и обрабатываются через type switch или рефлексию.

Вопрос 29. Что произойдёт при сравнении ошибок через == в Go? Почему сравнение кастомной ошибки через указатель может не работать?

Таймкод: 00:44:33

Ответ собеседника: Неполный. Кандидат не вспомнил точную причину. При сравнении ошибок через == сравниваются конкретные типы и значения. Если ошибка через указатель — каждый раз создаётся новый указатель. Правильный подход — errors.Is() и errors.As().

Правильный ответ:

Сравнение ошибок через == работает некорректно во многих случаях, особенно с кастомными ошибками. Это одна из самых частых ловушек в Go.

Проблема с == и указателями

Если кастомная ошибка реализована через указатель (*MyError), каждый вызов создаёт новый указатель, и == сравнивает адреса памяти, а не содержимое:

type MyError struct {
    Code int
}

func (e *MyError) Error() string {
    return fmt.Sprintf("error code: %d", e)
}

func doSomething() error {
    return &MyError{Code: 42} // новый указатель каждый раз
}

func main() {
    err := doSomething()
    target := &MyError{Code: 42}

    fmt.Println(err == target) // false! разные адреса памяти
}

Даже если ошибки имеют одинаковое содержимое (Code: 42), == вернёт false, потому что это разные указатели.

Проблема с обёрнутыми ошибками

Начиная с Go 1.13, ошибки можно оборачивать через %w и fmt.Errorf. Обёрнутая ошибка — это новый тип, и == не найдёт исходную ошибку:

var ErrNotFound = errors.New("not found")

func findItem(id int) error {
    return fmt.Errorf("item %d: %w", id, ErrNotFound)
}

func main() {
    err := findItem(42)
    fmt.Println(err == ErrNotFound) // false — err обёрнут
}

Правильный способ: errors.Is и errors.As

errors.Is — ищет ошибку по всей цепочке обёрток:

var ErrNotFound = errors.New("not found")

func findItem(id int) error {
    return fmt.Errorf("item %d: %w", id, ErrNotFound)
}

func main() {
    err := findItem(42)
    fmt.Println(errors.Is(err, ErrNotFound)) // true!
}

errors.As — проверяет, есть ли в цепочке ошибка определённого типа:

type MyError struct {
    Code int
    Msg  string
}

func (e *MyError) Error() string {
    return fmt.Sprintf("[%d] %s", e.Code, e.Msg)
}

func doSomething() error {
    return fmt.Errorf("wrapped: %w", &MyError{Code: 42, Msg: "not found"})
}

func main() {
    err := doSomething()

    var myErr *MyError
    if errors.As(err, &myErr) {
        fmt.Printf("code: %d, msg: %s\n", myErr.Code, myErr.Msg)
        // code: 42, msg: not found
    }
}

Реализация Is для кастомных ошибок

Если нужно, чтобы errors.Is работал по значению (не по указателю), реализуйте метод Is:

type MyError struct {
    Code int
}

func (e *MyError) Error() string {
    return fmt.Sprintf("error code: %d", e.Code)
}

// errors.Is будет вызывать этот метод:
func (e *MyError) Is(target error) bool {
    t, ok := target.(*MyError)
    if !ok {
        return false
    }
    return e.Code == t.Code // сравнение по значению, не по указателю
}

func main() {
    err1 := &MyError{Code: 42}
    err2 := &MyError{Code: 42}
    fmt.Println(errors.Is(err1, err2)) // true — сравниваются Code
}

Когда == работает корректно

== работает для ошибок, созданных через errors.New с глобальной переменной:

var ErrNotFound = errors.New("not found") // всегда один и тот же адрес

func find() error {
    return ErrNotFound // возвращаем тот же адрес
}

func main() {
    err := find()
    fmt.Println(err == ErrNotFound) // true — один и тот же указатель
}

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

Сводка

Ситуация	==	errors.Is
Глобальная переменная errors.New	✅	✅
Кастомная ошибка по указателю	❌	✅ (если реализован Is)
Обёрнутая ошибка (%w)	❌	✅
Разные экземпляры одного типа	❌	✅ (если реализован Is)

Правило: всегда используйте errors.Is и errors.As для сравнения ошибок. == — только для sentinel errors (глобальных переменных).

Вопрос 30. Почему сравнение ошибки с nil через == может не сработать, если возвращается указатель на кастомную ошибку?

Таймкод: 00:45:04

Ответ собеседника: Правильный. Интерфейс error содержит тип и значение. При возврате ненулевого указателя на ошибку интерфейс содержит тип *CustomError и значение указателя. При сравнении с nil интерфейс не равен nil, потому что тип указан. Нужно использовать errors.Is() или errors.As().

Правильный ответ:

Это классическая ловушка Go, связанная с внутренним устройством интерфейсов.

Внутреннее устройство интерфейса

Интерфейс — это структура из двух полей:

type iface struct {
    tab  *itab          // информация о типе
    data unsafe.Pointer // указатель на данные
}

Интерфейс равен nil только когда оба поля — nil (тип и значение).

Проблема

type CustomError struct {
    Code int
}

func (e *CustomError) Error() string {
    return fmt.Sprintf("error %d", e.Code)
}

func doWork() error {
    var err *CustomError = nil // nil-указатель на CustomError
    // ... какая-то логика, которая не меняет err ...
    return err // возвращаем nil-указатель КАК error
}

func main() {
    err := doWork()
    fmt.Println(err == nil)    // false! 😱
    fmt.Println(err != nil)    // true
}

Почему так происходит:

1. var err *CustomError = nil — nil-указатель на тип *CustomError.
2. При возврате return err компилятор неявно создаёт интерфейс error:
   • tab → указатель на itab для типа *CustomError (не nil!)
   • data → nil (сам указатель nil)
3. Интерфейс имеет ненулевой тип и нулевое значение → он не равен nil.

err (interface error):
┌──────────────┬──────────────┐
│  tab: *itab  │  data: nil   │
│  (не nil!)   │              │
└──────────────┴──────────────┘
→ err != nil → true

Как избежать

Вариант 1: Возвращать явный nil

func doWork() error {
    var err *CustomError = nil
    if somethingWrong {
        err = &CustomError{Code: 42}
    }
    if err != nil {
        return err
    }
    return nil // явный nil, не через промежуточную переменную
}

Вариант 2: Возвращать error напрямую

func doWork() error {
    if somethingWrong {
        return &CustomError{Code: 42}
    }
    return nil // интерфейс с tab=nil, data=nil → настоящий nil
}

Вариант 3: Использовать errors.Is

err := doWork()
if errors.Is(err, (*CustomError)(nil)) {
    // обработка
}
// Но это не идиоматично — лучше исправить возврат ошибки

Вариант 4: Проверка через reflect (для отладки)

import "reflect"

func isNilError(err error) bool {
    if err == nil {
        return true
    }
    v := reflect.ValueOf(err)
    return v.Kind() == reflect.Ptr && v.IsNil()
}

Антипаттерн в коде

// ❌ ПЛОХО:
func process() error {
    var result *Result
    var err *CustomError = nil

    result, err = fetchData()
    if err != nil { // всегда false, даже если fetchData вернула ошибку!
        return err
    }
    // ...
}

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

Вопрос 31. Как в Go реализуется оборачивание ошибок (error wrapping) и как проверить, что обёрнутая ошибка является конкретным типом?

Таймкод: 00:46:57

Ответ собеседника: Правильный. Оборачивание через fmt.Errorf с %w. Для проверки — errors.Is() для значения и errors.As() для типа. Глобальные ошибки для разных слоёв. Для стека вызовов — pkg/errors с %+v.

Правильный ответ:

Это уточняющий вопрос к предыдущим. Приведу краткую структурированную сводку с дополнительными деталями.

Оборачивание ошибок

// Базовый способ (Go 1.13+):
func queryUser(id int) (*User, error) {
    user, err := db.Query(ctx, "SELECT ...", id)
    if err != nil {
        return nil, fmt.Errorf("query user %d: %w", id, err)
    }
    return user, nil
}

// Можно оборачивать несколько раз:
func handler(w http.ResponseWriter, r *http.Request) {
    user, err := queryUser(userID)
    if err != nil {
        // Цепочка: handler → queryUser → db driver
        log.Printf("handler error: %v", err)
    }
}

Извлечение ошибок из цепочки

// errors.Is — ищет по значению (для sentinel errors):
var ErrNotFound = errors.New("not found")

if errors.Is(err, ErrNotFound) {
    // найдено в любом уровне обёртки
}

// errors.As — ищет по типу (для кастомных ошибок):
type ValidationError struct {
    Field string
    Msg   string
}

var valErr *ValidationError
if errors.As(err, &valErr) {
    fmt.Printf("validation failed on %s: %s\n", valErr.Field, valErr.Msg)
}

Разница между errors.Is и errors.As

// errors.Is — сравнивает с конкретным значением:
errors.Is(err, ErrNotFound)        // true, если в цепочке есть ErrNotFound
errors.Is(err, os.ErrPermission)   // true, если в цепочке есть os.ErrPermission

// errors.As — проверяет на тип и извлекает значение:
var pathErr *os.PathError
if errors.As(err, &pathErr) {
    fmt.Println("path:", pathErr.Path)
    fmt.Println("op:", pathErr.Op)
}

Стек вызовов

Стандартный fmt.Errorf с %w не сохраняет стек вызовов. Для этого используют сторонние библиотеки:

import "github.com/pkg/errors"

func process() error {
    if err := doWork(); err != nil {
        return errors.Wrap(err, "process failed")
    }
    return nil
}

// Вывод со стеком:
// process failed
// main.process
//     /app/main.go:15
// main.doWork
//     /app/main.go:10
// main.rootCause
//     /app/main.go:5

fmt.Printf("%+v\n", err) // %+v выводит полный стек

В Go 1.21+ появился runtime/debug.Stack() и улучшенные возможности, но pkg/errors по-прежнему популярен.

Идиоматичная обработка ошибок

// Определение sentinel errors:
var (
    ErrNotFound   = errors.New("not found")
    ErrValidation = errors.New("validation failed")
    ErrTimeout    = errors.New("timeout")
)

// Кастомные типы ошибок:
type AppError struct {
    Code    int
    Message string
    Err     error
}

func (e *AppError) Error() string {
    return fmt.Sprintf("[%d] %s: %v", e.Code, e.Message, e.Err)
}

func (e *AppError) Unwrap() error {
    return e.Err // позволяет errors.Is/As пройти по цепочке
}

// Использование:
func handler() error {
    if err := validate(); err != nil {
        return &AppError{
            Code:    400,
            Message: "bad request",
            Err:     err,
        }
    }
    return nil
}

// Проверка:
err := handler()
var appErr *AppError
if errors.As(err, &appErr) {
    http.Error(w, appErr.Message, appErr.Code)
}

Метод Unwrap

Для работы errors.Is и errors.As по цепочке, кастомная ошибка должна реализовать Unwrap() error:

type MyError struct {
    Msg string
    Err error
}

func (e *MyError) Error() string {
    return e.Msg
}

func (e *MyError) Unwrap() error {
    return e.Err // возвращаем обёрнутую ошибку
}

Без Unwrap цепочка разрывается, и errors.Is/errors.As не смогут найти ошибки глубже первого уровня.

Вопрос 32. Как работает планировщик горутин в Go? Что такое M, P, G модель и как изменился планировщик после Go 1.13?

Таймкод: 00:49:25

Ответ собеседника: Правильный. Модель M (OS-поток), P (логический процессор), G (goroutine). Локальная очередь до 256 горутин. Work stealing — крадёт половину работы у другого P. До Go 1.13 — кооперативный, после — вытесняющий (preemptive).

Правильный ответ:

M:P:G модель — основа планировщика Go (M:N scheduling), где M горутин распределяются по N OS-потокам через P логических процессоров.

Три сущности

G (Goroutine) — лёгкая зелёная нить. Собственный стек (начинается с ~2 КБ, растёт/сжимается динамически). Содержит контекст выполнения: программный счётчик, указатель стека, регистры.

P (Processor) — логический процессор. Количество P по умолчанию равно runtime.NumCPU(). Каждый P имеет:

• Локальную очередь горутин (LRQ, до 256 элементов)
• Контекст для выполнения горутин
• Привязку к M для выполнения кода

M (Machine) — реальный OS-поток. Создаётся по мере необходимости (блокирующие вызовы, нехватка свободных M). Выполняет горутины от имени P.

┌─────────────────────────────────────────────┐
│                  Runtime                     │
│                                              │
│  Global Run Queue (GRQ)                      │
│  ┌───┬───┬───┬───┬───┐                      │
│  │ G │ G │ G │ G │ G │                      │
│  └───┴───┴───┴───┴───┘                      │
│                                              │
│  P0          P1          P2          P3      │
│  ┌────┐     ┌────┐     ┌────┐     ┌────┐    │
│  │LRQ │     │LRQ │     │LRQ │     │LRQ │    │
│  │G G │     │G G │     │G   │     │G G │    │
│  │G G │     │G   │     │    │     │G   │    │
│  └──┬─┘     └──┬─┘     └──┬─┘     └──┬─┘    │
│     │          │          │          │       │
│  ┌──▼─┐     ┌──▼─┐     ┌──▼─┐     ┌──▼─┐    │
│  │ M0 │     │ M1 │     │ M2 │     │ M3 │    │
│  └────┘     └────┘     └────┘     └────┘    │
│     │          │          │          │       │
│  ┌──▼──────────▼──────────▼──────────▼──┐    │
│  │           OS Kernel                   │    │
│  │     CPU0    CPU1    CPU2    CPU3     │    │
│  └──────────────────────────────────────┘    │
└─────────────────────────────────────────────┘

Алгоритм планирования (work stealing)

Каждый P выполняет горутины из своей локальной очереди. Когда очередь пуста:

1. Проверяет глобальную очередь (GRQ) — с вероятностью ~1/61 на каждую итерацию.
2. Крадёт у другого P — случайно выбирает жертву и забирает половину его локальной очереди.
3. Блокируется — если ничего не найдено, M паркуется.

// Упрощённая логика schedule():
func schedule() {
    // Каждые 61 итерацию — проверить глобальную очередь
    if gp == nil {
        if _g_.m.p.ptr().schedtick%61 == 0 {
            gp = globrunqget(_g_.m.p.ptr(), 1)
        }
    }

    // Локальная очередь
    if gp == nil {
        gp = runqget(_g_.m.p.ptr())
    }

    // Work stealing
    if gp == nil {
        gp = findrunnable() // ищет в GRQ и крадёт у других P
    }

    execute(gp)
}

Кооперативный vs вытесняющий планировщик

До Go 1.13 — кооперативный:

Горутина отдавала управление добровольно в точках синхронизации:

• Вызов функций (не всегда — только при stack split)
• Канальные операции
• Системные вызовы
• runtime.Gosched()

Проблема: горутина в tight loop без вызовов функций могла монополизировать P:

// До Go 1.13 — могло заблокировать другие горутины на этом P:
func busyLoop() {
    for {
        // никаких вызовов функций, никаких аллокаций
        x++
    }
}

С Go 1.13+ — вытесняющий (asynchronous preemption):

Планировщик использует сигнал SIGURG для принудительного вытеснения горутин:

1. Системный монитор (sysmon) отслеживает горутины, выполняющиеся дольше 10 мс.
2. Посылает SIGURG в поток M.
3. Обработчик сигнала приостанавливает текущую горутину и передаёт управление планировщику.

// С Go 1.13+ — эта горутина будет вытеснена через ~10ms:
func busyLoop() {
    for {
        x++ // будет прерван сигналом SIGURG
    }
}

Go 1.22+ — дальнейшие улучшения:

• Улучшена обработка блокирующих системных вызовов
• Оптимизирован work stealing
• Уменьшены накладные расходы на переключение контекста

Практические следствия

// Управление количеством P:
runtime.GOMAXPROCS(4) // ограничить до 4 логических процессоров

// Уступка управления (явная):
runtime.Gosched()

// Привязка горутины к текущему OS-потоку (не рекомендуется без необходимости):
runtime.LockOSThread()
defer runtime.UnlockOSThread()

Ключевые числа

Параметр	Значение
Размер стека горутины (начальный)	2 КБ
Максимальный размер стека	1 ГБ
Размер локальной очереди P	256 горутин
Порог вытеснения (Go 1.13+)	~10 мс
Вероятность проверки GRQ	1/61 на итерацию

Вопрос 33. В чём преимущество горутин перед потоками ОС и процессами с точки зрения переключения контекста?

Таймкод: 00:53:39

Ответ собеседника: Правильный. Горутина весит ~4 КБ. Переключение происходит внутри рантайма без обращения к ядру ОС. Не требуется менять регистры, очищать кэш. OS-потоки переключаются через системный вызов — значительно дороже.

Правильный ответ:

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

Сравнение стоимости переключения

Тип	Стоимость	Что происходит
Горутина	~100–200 нс	Сохранить 3 регистра (SP, PC, BP), загрузить новые
OS-поток	~1–10 мкс	Системный вызов, переключение в kernel mode, TLB flush
Процесс	~10–100 мкс	Как поток + смена таблицы страниц памяти

Почему горутины дешевле

1. User-space scheduling

Переключение горутин происходит в user space — без перехода в kernel mode. Не нужен системный вызов:

Горутина → Горутина:
  runtime.schedule()
  → сохранить SP, PC, BP
  → загрузить SP, PC, BP новой горутины
  → jump

OS-поток → OS-поток:
  schedule() in kernel
  → переход в kernel mode (syscall)
  → сохранить все регистры, FPU state, SSE state
  → обновить TLB (translation lookaside buffer)
  → переключить таблицу страниц (для процессов)
  → загрузить регистры нового потока
  → возврат в user mode

2. Минимальное состояние

Горутина сохраняет только 3 регистра:

• SP (Stack Pointer) — указатель стека
• PC (Program Counter) — следующая инструкция
• BP (Base Pointer) — база стекового фрейма

OS-поток сохраняет: все 16+ регистров общего назначения, FPU/SSE/AVX состояние, регистры отладки, TLS (Thread Local Storage).

3. Кэш-эффективность

При переключении горутин на одном и том же M (OS-потоке) данные остаются в кэше процессора. При переключении OS-потоков кэш может быть «холодным», что приводит к cache miss и дополнительным задержкам.

4. Размер стека

OS-поток:  1–8 МБ (фиксированный, выделяется заранее)
Горутина:  2–8 КБ (начальный, растёт по мере необходимости)

Меньший стек → больше горутин помещается в кэш процессора → меньше cache miss.

Практические следствия

// Можно запустить миллион горутин:
func main() {
    for i := 0; i < 1_000_000; i++ {
        go func() {
            time.Sleep(time.Hour)
        }()
    }
    time.Sleep(time.Second)
    fmt.Println(runtime.NumGoroutine()) // ~1000000
}

Миллион OS-потоков потребовал бы ~8 ТБ RAM (при 1 МБ на поток) и был бы крайне медленным из-за постоянного переключения контекста ядром.

Когда OS-потоки всё же нужны

Горутины работают на OS-потоках (M). Если горутина выполняет блокирующий системный вызов (файловый I/O, сетевой вызов без неблокирующего интерфейса), она блокирует связанный M. В этом случае runtime создаёт новый M, чтобы другие горутины от того же P могли продолжить работу.

// Блокирующий системный вызов — M блокируется:
data, err := os.ReadFile("largefile.bin")
// Во время чтения M припаркован, P привязывается к другому M

Итого: горутины дешевле OS-потоков на 1–2 порядка по стоимости переключения контекста и на 3–4 порядка по потреблению памяти. Это позволяет Go эффективно работать с сотнями тысяч и миллионами конкурентных задач.

Вопрос 34. Как работает сборщик мусора (GC) в Go? Что происходит, если горутина делает syscall (например, sleep)?

Таймкод: 00:54:12

Ответ собеседника: Правильный. GC работает по принципу mark-and-sweep: объект жив, если на него есть ссылка. При syscall горутина отдаёт управление, планировщик может прервать её. Рантайм может создавать дополнительные машины.

Правильный ответ:

Сборщик мусора Go — concurrent, tri-color, mark-and-sweep GC с низкой задержкой (low-latency).

Mark-and-Sweep: два этапа

1. Mark (пометка)

Начиная с корневых ссылок (глобальные переменные, стеки горутин, регистры), GC обходит граф объектов и пометет все достижимые объекты как «живые»:

Roots (stack, globals)
    ├── objA → objB → objC  (живые — помечены)
    └── objD → objE          (живые — помечены)
    
    objF → objG              (мусор — недостижимы из roots)

2. Sweep (уборка)

Все непомеченные объекты освобождаются. Памень возвращается в allocator.

Три цвета объектов

Цвет	Значение
Белый	Не посещён — потенциально мусор
Серый	Посещён, но его потомки ещё не проверены
Чёрный	Посещён и все его потомки проверены — точно живой

В начале все объекты белые. В конце белые объекты освобождаются, чёрные остаются.

Concurrent GC

GC выполняется параллельно с пользовательским кодом (concurrent mark), с минимальными остановками мира (STW — Stop The World):

Время ──────────────────────────────────────────────►

STW    Concurrent Mark    STW     Sweep
│      │                  │       │
│◄~1ms►│◄──── основная ───►│◄~1ms►│◄── фон ──►
│      │    работа GC      │       │
│      │                  │       │
User   GC + User          GC +    User + GC
code   code параллельно   User    (sweep)
       (write barrier)    code

Write Barrier (барьер записи)

Пока GC работает параллельно, пользовательский код может менять ссылки на объекты. Write barrier отслеживает эти изменения, чтобы GC не потерял живые объекты:

// Когда пользовательский код делает:
objA.field = objB

// Write barrier проверяет:
// Если objA чёрный и objB белый → пометить objB серым
// Это гарантирует, что objB не будет удалён по ошибке

Что при при syscall (sleep и т.д.)

Когда горутина вызывает time.Sleep, time.After или другой blocking syscall:

1. Горутина переходит в состояние Gwaiting.
2. M (OS-поток) паркуется или переходит к другой горутине.
3. P остаётся привязанным к другому M или берёт горутину из очереди.

При блокирующем syscall (файловый I/O, time.Sleep через timer):

• Если M блокируется в kernel call, runtime может создать новый M, чтобы P не простаивал.
• При возврате из syscall горутина помещается в глобальную очередь и ждёт своего P.

// time.Sleep — горутина паркуется на таймере:
func Sleep(d Duration) {
    // runtime помещает G в timer heap
    // M переключается на другую G
    // По истечении таймера G возвращается в run queue
}

Параметры GC

// Управление целевым процентом GC (по умолчанию 100):
// Если живые данные = 100 МБ, GC запустится, когда мусор достигнет 100 МБ
// (итого 200 МБ аллокаций между циклами GC)
debug.SetGCPercent(100)

// Ручной запуск GC:
runtime.GC()

// Статистика GC:
var stats runtime.MemStats
runtime.ReadMemStats(&stats)
fmt.Printf("GC cycles: %d, PauseTotal: %v\n", stats.NumGC, stats.PauseTotalNs)

Эволюция GC в Go

Версия	Улучшение
Go 1.0	Базовый mark-and-sweep с STW
Go 1.3	Concurrent sweep
Go 1.5	Concurrent mark, STW < 10ms
Go 1.8	STW < 100мкс (hybrid barrier)
Go 1.12	Non-cooperative preemption + GC
Go 1.19	Soft memory limit (GOMEMLIMIT)

GOMEMLIMIT (Go 1.19+)

// Ограничение памяти для приложения:
debug.SetMemoryLimit(512 << 20) // 512 МБ
// GC будет чаще запускаться, чтобы не превысить лимит

Итого: GC Go — concurrent tri-color mark-and-sweep с минимальными STW-паузами (обычно < 100мкс). При syscall горутина паркуется, M может быть заменён, а GC продолжает работу параллельно.

Вопрос 35. Что происходит при возврате указателя на локальную переменную из функции в Go и C++? Как Go решает эту проблему?

Таймкод: 00:56:21

Ответ собеседника: Правильный. В C++ — UB (неопределённое поведение), стек освобождается. В Go — escape analysis: если переменная возвращается по указателю, она выделяется на куче. GC автоматически очистит её.

Правильный ответ:

Проблема в C++

int* createInt() {
    int x = 42;      // x на стеке
    return &x;        // возвращаем указатель на стековую переменную
}                     // x уничтожается — указатель становится висячим (dangling pointer)

int main() {
    int* p = createInt();
    std::cout << *p;  // UB — разыменование висячего указателя
}

В C++ это undefined behavior — программа может упасть, вывести мусор или «работать правильно» случайно.

Решение в Go: Escape Analysis

Компилятор Go выполняет escape analysis — анализирует, выходит ли переменная за пределы текущего стекового фрейма:

func createInt() *int {
    x := 42       // компилятор: x "убегает" через return → выделить на куче
    return &x      // безопасно — x на куче
}

func main() {
    p := createInt()
    fmt.Println(*p) // 42 — корректно
}

Если переменная «убегает» (escapes), компилятор размещает её на куче. Если нет — на стеке (быстрее, нет накладных расходов на аллокацию).

Как увидеть escape analysis

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

Вывод:

./main.go:2:6: moved to heap: x
./main.go:2:6: escaped to heap: x

Примеры escape

// 1. Возврат указателя:
func f1() *int {
    x := 1
    return &x // x escapes to heap
}

// 2. Запись в глобальную переменную:
var global *int
func f2() {
    x := 1
    global = &x // x escapes to heap
}

// 3. Передача в интерфейс:
func f3() {
    x := 1
    fmt.Println(x) // x escapes to heap (fmt.Println принимает ...any)
}

// 4. Замыкание (closure):
func f4() func() int {
    x := 1
    return func() int { // x escapes to heap (замыляние захватывает x)
        return x
    }
}

// 5. Слишком большой объект:
func f5() {
    x := make([]int, 1000000) // x escapes to heap (слишком большой для стек)
    _ = x
}

Когда переменная остаётся на стеке

func sum() int {
    x := 0
    for i := 0; i < 100; i++ {
        x += i
    }
    return x // x не убегает — возвращается значение, не указатель
}

Сравнение подходов

Язык	Механизм	Кто управляет памятью
C++	Ручное (malloc/free, new/delete)	Программист
Go	Escape analysis + GC	Компилятор + runtime GC
Rust	Ownership + borrowing	Компилятор (compile-time)
Java	Всё на куче (кроме primitives)	GC

Важно: аллокация на куче дороже аллокации на стеке. Стек — это просто инкремент указателя стека (1 инструкция). Куча — это вызов allocator'а, возможный вызов GC. Поэтому escape analysis старается размещать объекты на стеке, когда это безопасно.

Вопрос 36. Как работает сборщик мусора в Go? Как называется алгоритм и можно ли его настроить?

Таймкод: 00:57:08

Ответ собеседника: Правильный. Алгоритм — mark-and-sweep с трицветной маркировкой (белый, серый, чёрный). Живые объекты помечаются, остальные удаляются. Настройка через GOGC. Полноценного управления памятью нет.

Правильный ответ:

Это уточняющий вопрос к предыдущему. Приведу краткую сводку с акцентом на настройку.

Алгоритм: Concurrent Tri-Color Mark-and-Sweep

Подробно разобран в вопросе 34. Кратко:

• Mark: обход графа объектов от корней, пометка живых.
• Sweep: освобождение непомеченных объектов.
• Tri-color: белый (не посещён), серый (посещён, потомки не проверены), чёрный (полностью обработан).
• Concurrent: выполняется параллельно с пользовательским кодом.

Настройка GC

1. GOGC — целевой процент роста кучи

# Переменная окружения:
GOGC=100  # по умолчанию — GC запускается при двукратном росте живых данных
GOGC=50   # агрессивнее — при росте на 50%
GOGC=200  # мягче — при росте на 200%
GOGC=off  # отключить GC

// Программно:
debug.SetGCPercent(100)

2. GOMEMLIMIT — лимит памяти (Go 1.19+)

// Ограничить память приложения 512 МБ:
debug.SetMemoryLimit(512 << 20)

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

3. GOMAXPROCS

runtime.GOMAXPROCS(4)

Влияет на количество P, а значит на параллелизм GC.

4. Статистика GC

var stats runtime.MemStats
runtime.ReadMemStats(&stats)

fmt.Printf("NumGC: %d\n", stats.NumGC)           // количество циклов GC
fmt.Printf("PauseTotalNs: %v\n", stats.PauseTotalNs) // суммарное время STW
fmt.Printf("HeapAlloc: %d\n", stats.HeapAlloc)    // текущая куча
fmt.Printf("HeapSys: %d\n", stats.HeapSys)        // куча, запрошенная у ОС
fmt.Printf("GCCPUFraction: %f\n", stats.GCCPUFraction) // доля CPU на GC

5. Профилирование GC

# Лог GC в stderr:
GODEBUG=gctrace=1 ./myapp

# Вывод:
# gc 1 @0.015s 0%: 0.015+0.36+0.047 ms clock, 0.12+0.54/0.23/0.11+0.38 ms cpu, 4->4->0 MB MB, 5 MB goal, 4 P
# gc 2 @0.031s 0%: 0.031+0.41+0.052 ms clock, ...

Чего НЕ можно настроить

• Размер стека горутины (определяется автоматически)
• Время паузы GC (определяется автоматически)
• Размер поколений (Go не использует generational GC)

Типичные проблемы и решения

Проблема	Причина	Решение
Высокий % CPU на GC	Слишком много аллокаций	Уменьшить аллокации, использовать sync.Pool
Высокое потребление памяти	Объекты живут дольше, чем нужно	Освобождать ссылки, использовать weak refs
Частые циклы GC	GOGC слишком низкий	Увеличить GOGC
OOM в контейнере	Нет лимита памяти	Установить GOMEMLIMIT

Вопрос 37. Что такое livelock и starvation в конкурентном программировании? Как Go решает проблему starvation после версии 1.13?

Таймкод: 00:58:37

Ответ собеседника: Правильный. Livelock — горутины бегают по кругу, не выполняя полезной работы. Starvation — горутина не получает ресурс. До Go 1.13 — кооперативный планировщик, starvation возможно. После 1.13 — вытесняющий (preemptive), прерывает горутину и передаёт управление.

Правильный ответ:

Livelock — ситуация, когда горутины (или потоки) активно работают, но не продвигаются к цели, потому что постоянно реагируют друг на друга.

Starvation — ситуация, когда горутина не может получить доступ к нужному ресурсу (CPU, мьютекс, канал), потому что другие горутины постоянно его занимают.

Примеры

Livelock:

// Две горутины пытаются получить два мьютекса, но каждая отпускает свой,
// если не может получить чужой, и пробует снова — бесконечно:
func worker1() {
    for {
        mu1.Lock()
        if mu2.TryLock() {
            // работа
            mu2.Unlock()
            mu1.Unlock()
            return
        }
        mu1.Unlock() // отпускаем и пробуем снова
    }
}

func worker2() {
    for {
        mu2.Lock()
        if mu1.TryLock() {
            // работа
            mu1.Unlock()
            mu2.Unlock()
            return
        }
        mu2.Unlock() // отпускаем и пробуем снова
    }
}

Обе горутины активно работают (не заблокированы), но не продвигаются.

Starvation:

// Горутина с высоким приоритетом постоянно захватывает мьютекс,
// а горутина с низким приоритетом никогда не получает его:
func greedyWorker() {
    for {
        mu.Lock()
        // быстрая работа
        mu.Unlock()
        // сразу снова захватывает
    }
}

func starvingWorker() {
    for {
        mu.Lock() // почти никогда не получает мьютекс
        // работа
        mu.Unlock()
    }
}

Как Go решает starvation

До Go 1.13 — кооперативный планировщик:

Горутина отдавала управление только в определённых точках (вызовы функции, канальные операции, системные вызовы). Tight loop без вызовов мог монополизировать P.

С Go 1.13+ — вытесняющий планировщик:

Используется сигнал SIGURG для принудительного вытеснения:

1. Системный монитор (sysmon) — отдельный M, который проверяет все P каждые ~10 мкс.
2. Если P выполняет одну горутину дольше 10 мс — sysmon посылает SIGURG в поток M.
3. Обработчик сигнала прерывает текущую горутину и вызывает schedule().

// sysmon в runtime:
func sysmon() {
    for {
        // Проверить, не работает ли P слишком долго
        for i := 0; i < len(allp); i++ {
            p := allp[i]
            if int64(p.schedtick) - int64(retake(now)) > 10*1000*1000 { // 10ms
                preemptone(p) // послать SIGURG
            }
        }
        usleep(delay)
    }
}

Starvation мьютексов:

sync.Mutex в Go начиная с версии 1.9 использует двухфазный алгоритм:

1. Normal mode — честная очередь (FIFO) для ждущих горутин. Новые горутины не могут «влезть вперёд».
2. Starvation mode — если горутина ждала мьютекс дольше 1 мс, мьютекс переходит в starvation mode, где следующая горутина в очереди получает мьютекс напрямую (без конкуренции).

// Упрощённая логика sync.Mutex:
const starvationThresholdNs = 1e6 // 1 мс

func (m *Mutex) Lock() {
    // Если мьютекс свободен и нет ждущих — захватить сразу (fast path)
    if atomic.CompareAndSwapInt32(&m.state, 0, mutexLocked) {
        return
    }
    // Slow path — очередь с учётом starvation
    m.lockSlow()
}

Итого: livelock — активная бесполезная работа, starvation — невозможность получить ресурс. Go решает оба через вытесняющий планировщик (SIGURG, с 1.13) и starvation mode в sync.Mutex (с 1.9).

Вопрос 38. Для чего нужен defer в Go? Как он работает и в каком порядке выполняются отложенные функции?

Таймкод: 01:00:00

Ответ собеседника: Правильный. Defer — отложенное выполнение при выходе из функции. Гарантирует выполнение действий (закрытие ресурсов) независимо от способа завершения. Аргументы копируются на момент вызова. Выполняется в порядке LIFO.

Правильный ответ:

defer откладывает выполнение функции до момента возврата из текущей функции. Используется для освобождения ресурсов, разблокировки мьютексов, закрытия файлов и т.д.

Порядок выполнения: LIFO

func example() {
    defer fmt.Println("1st defer")
    defer fmt.Println("2nd defer")
    defer fmt.Println("3rd defer")
    fmt.Println("body")
}
// Вывод:
// body
// 3rd defer
// 2nd defer
// 1st defer

Каждый defer помещается в стек (linked list в runtime). При возврате из функции стек разворачивается в обратном порядке.

Аргументы вычисляются сразу

func example() {
    x := 1
    defer fmt.Println(x) // x вычислен сейчас: 1
    x = 2
    fmt.Println(x)       // 2
}
// Вывод:
// 2
// 1

Аргументы defer вычисляются в момент вызова defer, а не в момент выполнения.

Типичные применения

// 1. Закрытие файла:
func readFile(path string) (string, error) {
    f, err := os.Open(path)
    if err != nil {
        return "", err
    }
    defer f.Close() // гарантированно закроется

    data, err := io.ReadAll(f)
    if err != nil {
        return "", err
    }
    return string(data), nil
}

// 2. Разблокировка мьютекса:
func process() {
    mu.Lock()
    defer mu.Unlock() // разблокируется при любом выходе

    // сложная логика с множеством return
    if condition1 {
        return // mu.Unlock() вызовется автоматически
    }
    if condition2 {
        return // mu.Unlock() вызовется автоматически
    }
}

// 3. Восстановление после panic:
func safeCall() {
    defer func() {
        if r := recover(); r != nil {
            log.Println("recovered:", r)
        }
    }()
    panic("something went wrong") // будет перехвачено
}

// 4. Замер времени:
func timedOperation() {
    start := time.Now()
    defer func() {
        fmt.Printf("took %v\n", time.Since(start))
    }()
    // работа...
}

Defer и именованные возвращаемые значения

Defer может изменять именованные возвращаемые значения:

func example() (result int) {
    defer func() {
        result++ // изменяет возвращаемое значение
    }()
    return 41 // result = 41, затем defer увеличивает до 42
}
// Возвращает 42

Производительность

До Go 1.13 defer был дорогой операцией (аллокация в heap). С Go 1.13+ опмимизация: defer в большинстве случаев размещается на стеке, что делает его значительно дешевле:

// Go 1.12: defer ~30ns (heap allocation)
// Go 1.13+: defer ~3ns (stack allocation, в 10 раз быстрее)

Ограничения

// Нельзя использовать defer в цикле без осторожности:
func processFiles(files []string) {
    for _, f := range files {
        fp, _ := os.Open(f)
        defer fp.Close() // ❌ все файлы закроются только в конце функции!
        // ...
    }
}

// Правильно — обернуть в функцию:
func processFiles(files []string) {
    for _, f := range files {
        func() {
            fp, _ := os.Open(f)
            defer fp.Close() // ✅ закроется на каждой итерации
            // ...
        }()
    }
}

Вопрос 39. Как передать в defer актуальное (изменённое) значение переменной? Можно ли это сделать без указателя?

Таймкод: 01:03:12

Ответ собеседника: Правильный. По умолчанию defer копирует значения. Для актуального значения — указатель или замыкание (анонимная функция без аргументов). Также можно использовать именованное возвращаемое значение.

Правильный ответ:

Аргументы defer вычисляются в момент вызова, а не в момент выполнения. Чтобы получить актуальное значение, есть несколько способов.

Проблема

func example() {
    x := 1
    defer fmt.Println(x) // x=1 зафиксировано
    x = 2
}
// Вывод: 1, а не 2

Способ 1: Замыкание (closure)

func example() {
    x := 1
    defer func() {
        fmt.Println(x) // x читается в момент выполнения defer
    }()
    x = 2
}
// Вывод: 2

Замыкание захватывает переменную по ссылке, поэтому видит актуальное значение.

Способ 2: Указатель

func example() {
    x := 1
    defer func(val *int) {
        fmt.Println(*val)
    }(&x)
    x = 2
}
// Вывод: 2

Способ 3: Именованное возвращаемое значение

func example() (x int) {
    x = 1
    defer func() {
        fmt.Println(x) // читает именованное возвращаемое значение
    }()
    x = 2
    return x
}
// Вывод: 2

Способ 4: defer с вызовом функции, возвращающей значение

func example() {
    x := 1
    defer func() {
        fmt.Println(getX()) // вызов функции в момент выполнения
    }()
    x = 2
}

func getX() int { return x } // глобальная или замыкание

Сравнение способов

Способ	Нужен указатель?	Читает актуальное значение?	Сложность
Замыкание func(){ fmt.Println(x) }	Нет	Да	Просто
Указатель func(val *int)	Да	Да	Средне
Named return	Нет	Да	Просто

Рекомендация: замыкание — самый идиоматичный и простой способ в Go. Не требует указателей и явно показывает намерение.

Вопрос 40. Можно ли ловить паники в defer и как это сделать? Насколько часто нужно использовать recover?

Таймкод: 01:05:54

Ответ собеседника: Правильный. Да, через recover() в defer. recover() перехватывает панику и возвращает её значение. Но recover — дорогая операция, злоупотреблять не стоит. Лучше возвращать ошибки явно. Recover — только для критически важных случаев.

Правильный ответ:

recover() — единственный способ перехватить panic. Работает только внутри defer.

Базовый пример

func main() {
    defer func() {
        if r := recover(); r != nil {
            fmt.Println("recovered:", r)
        }
    }()
    panic("something went wrong")
    fmt.Println("this will not be printed")
}
// Вывод: recovered: something went wrong

Важные правила

1. recover работает только в defer — в обычном коде возвращает nil.
2. recover перехватывает панику только в текущей горутине — паника в другой горутине не будет перехвачена.
3. после recover выполнение продолжается с точки после defer — а не с места, где была паника.

func example() {
    defer func() {
        if r := recover(); r != nil {
            fmt.Println("recovered:", r)
        }
    }()
    fmt.Println("before panic")
    panic("oops")
    fmt.Println("after panic") // не выполнится
}
// Вывод:
// before panic
// recovered: oops
// функция завершается после defer

Паника в горутине

Если горутина запаниковала и не перехватила панику — падает вся программа:

func main() {
    go func() {
        panic("goroutine panic") // убьёт всю программу!
    }()
    time.Sleep(time.Second)
}

Правильно — перехватывать в каждой горутине:

func worker() {
    defer func() {
        if r := recover(); r != nil {
            log.Printf("worker recovered: %v\n%s", r, debug.Stack())
        }
    }()
    // работа...
}

Типичные применения recover

1. HTTP middleware — перехват паник в обработчиках:

func recoveryMiddleware(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        defer func() {
            if r := recover(); r != nil {
                log.Printf("panic: %v\n%s", r, debug.Stack())
                http.Error(w, "Internal Server Error", 500)
            }
        }()
        next.ServeHTTP(w, r)
    })
}

2. Worker pool — перезапуск воркера после паники:

func worker(id int, tasks <-chan Task) {
    defer func() {
        if r := recover(); r != nil {
            log.Printf("worker %d panicked: %v", id, r)
            go worker(id, tasks) // перезапуск
        }
    }()
    for task := range tasks {
        process(task)
    }
}

3. Гарантированное освобождение ресурсов:

func processFile(path string) (err error) {
    f, err := os.Open(path)
    if err != nil {
        return err
    }
    defer func() {
        if r := recover(); r != nil {
            f.Close() // гарантируем закрытие
            err = fmt.Errorf("panic: %v", r)
        }
    }()
    // обработка файла...
}

Когда использовать recover

Сценарий	Использовать recover?
HTTP-сервер (middleware)	✅ Да
Worker pool	✅ Да
Библиотека (экспортируемая функция)	✅ Да
Бизнес-логика	❌ Нет — используйте error
Валидация входных данных	❌ Нет — используйте error

Антипаттерн: recover вместо error

// ❌ ПЛОХО — использовать panic/recover для обычных ошибок:
func divide(a, b float64) float64 {
    if b == 0 {
        panic("division by zero")
    }
    return a / b
}

// ✅ ПРАВИЛЬНО — возвращать error:
func divide(a, b float64) (float64, error) {
    if b == 0 {
        return 0, errors.New("division by zero")
    }
    return a / b, nil
}

Ключевой принцип: panic/recover — для неожиданных ситуаций (нарушение инвариантов, nil pointer dereference). Для ожидаемых ошибок (некорректный ввод, сетевой сбой) используйте явный error.

Вопрос 41. Как проводить тестирование в Go? Как создавать моки для интерфейсов и какие библиотеки используются?

Таймкод: 01:06:46

Ответ собеседника: Правильный. Встроенный пакет testing. Моки — вручную через реализацию интерфейса или библиотеки (gomock, testify/mock). Интеграционные тесты с Docker для БД, Kafka и других зависимостей.

Правильный ответ:

Базовое тестирование с пакетом testing

// calculator.go
func Add(a, b int) int {
    return a + b
}

// calculator_test.go
func TestAdd(t *testing.T) {
    result := Add(2, 3)
    if result != 5 {
        t.Errorf("Add(2, 3) = %d; want 5", result)
    }
}

Запуск: go test ./...

Табличные тесты (table-driven tests)

Идиоматичный подход в Go:

func TestAdd(t *testing.T) {
    tests := []struct {
        name     string
        a, b     int
        expected int
    }{
        {"positive", 2, 3, 5},
        {"negative", -1, -1, -2},
        {"zero", 0, 0, 0},
        {"mixed", -1, 1, 0},
    }

    for _, tt := range tests {
        t.Run(tt.name, func(t *testing.T) {
            got := Add(tt.a, tt.b)
            if got != tt.expected {
                t.Errorf("Add(%d, %d) = %d; want %d", tt.a, tt.b, got, tt.expected)
            }
        })
    }
}

Создание моков вручную

// Интерфейс:
type UserRepository interface {
    GetByID(ctx context.Context, id int) (*User, error)
    Save(ctx context.Context, user *User) error
}

// Мок вручную:
type MockUserRepo struct {
    users map[int]*User
    saveCalled bool
}

func NewMockUserRepo() *MockUserRepo {
    return &MockUserRepo{users: make(map[int]*User)}
}

func (m *MockUserRepo) GetByID(ctx context.Context, id int) (*User, error) {
    if user, ok := m.users[id]; ok {
        return user, nil
    }
    return nil, ErrNotFound
}

func (m *MockUserRepo) Save(ctx context.Context, user *User) error {
    m.users[user.ID] = user
    m.saveCalled = true
    return nil
}

// Тест с моком:
func TestUserService(t *testing.T) {
    mockRepo := NewMockUserRepo()
    mockRepo.users[1] = &User{ID: 1, Name: "Alice"}

    svc := NewUserService(mockRepo)
    user, err := svc.GetUser(context.Background(), 1)

    assert.NoError(t, err)
    assert.Equal(t, "Alice", user.Name)
}

Библиотеки для моков

1. testify/mock — самая популярная:

import "github.com/stretchr/testify/mock"

type MockUserRepo struct {
    mock.Mock
}

func (m *MockUserRepo) GetByID(ctx context.Context, id int) (*User, error) {
    args := m.Called(ctx, id)
    return args.Get(0).(*User), args.Error(1)
}

func (m *MockUserRepo) Save(ctx context.Context, user *User) error {
    args := m.Called(ctx, user)
    return args.Error(0)
}

// Тест:
func TestUserService(t *testing.T) {
    mockRepo := new(MockUserRepo)
    mockRepo.On("GetByID", mock.Anything, 1).Return(&User{ID: 1, Name: "Alice"}, nil)

    svc := NewUserService(mockRepo)
    user, err := svc.GetUser(context.Background(), 1)

    assert.NoError(t, err)
    assert.Equal(t, "Alice", user.Name)
    mockRepo.AssertExpectations(t) // проверяет, что все ожидаемые вызовы были сделаны
}

2. mockery — генерация моков из интерфейсов:

# Установка:
go install github.com/vektra/mockery/v2@latest

# Генерация мока:
mockery --name=UserRepository --dir=. --output=mocks

# Создаёт mocks/UserRepository.go с полной реализацией мока

3. gomock (Google Mock для Go):

//go:generate mockgen -source=user_repo.go -destination=mock_user_repo.go

ctrl := gomock.NewController(t)
defer ctrl.Finish()

mockRepo := NewMockUserRepository(ctrl)
mockRepo.EXPECT().GetByID(gomock.Any(), 1).Return(&User{ID: 1, Name: "Alice"}, nil)

Интеграционные тесты с Docker

func TestIntegrationUserRepo(t *testing.T) {
    if testing.Short() {
        t.Skip("skipping integration test")
    }

    ctx := context.Background()

    // Запуск PostgreSQL в Docker:
    container, err := postgres.RunContainer(ctx,
        testcontainers.WithImage("postgres:15"),
        postgres.WithDatabase("testdb"),
        postgres.WithUsername("test"),
        postgres.WithPassword("test"),
    )
    if err != nil {
        t.Fatal(err)
    }
    defer container.Terminate(ctx)

    connStr, err := container.ConnectionString(ctx)
    if err != nil {
        t.Fatal(err)
    }

    db, err := sql.Open("postgres", connStr)
    if err != nil {
        t.Fatal(err)
    }
    defer db.Close()

    repo := NewPostgresUserRepo(db)
    // Тесты с реальной БД...
}

Бенчмарки

func BenchmarkAdd(b *testing.B) {
    for i := 0; i < b.N; i++ {
        Add(2, 3)
    }
}

Запуск: go test -bench=. -benchmem

Тестовое покрытие

go test -cover ./...
go test -coverprofile=coverage.out ./...
go tool cover -html=coverage.out

Рекомендации

Тип теста	Когда использовать
Unit-тесты	Бизнес-логика, чистые функции
Моки	Изоляция от внешних зависимостей
Интеграционные	Взаимодействие с БД, очередями
Табличные	Множество входных/выходных комбинаций
Бенчмарки	Критичные по производительности участки

Вопрос 42. Какие способы межпроцессного взаимодействия (IPC) существуют в операционных системах?

Таймкод: 01:18:36

Ответ собеседника: Правильный. Pipe, Unix domain sockets, shared memory, signals, named pipes, message queues. Каналы Go построены по принципу CSP — горутины общаются через каналы, а не через разделяемую память.

Правильный ответ:

IPC (Inter-Process Communication) — механизмы обмена данными между процессами. Процессы изолированы друг от друга (у каждого своё адресное пространство), поэтому для обмена данными нужны специальные механизмы.

Основные механизмы IPC

1. Pipe (неименованный канал)

Однонаправленный канал между родственными процессами (родитель-потомок):

// В Go:
cmd := exec.Command("grep", "hello")
stdin, _ := cmd.StdinPipe()
stdout, _ := cmd.StdoutPipe()

cmd.Start()
stdin.Write([]byte("hello world\n"))
stdin.Close()

output, _ := io.ReadAll(stdout)
cmd.Wait()

2. Named Pipe (FIFO)

Как pipe, но существует как файл в файловой системе — может использоваться неродственными процессами:

mkfifo /tmp/my_pipe
echo "hello" > /tmp/my_pipe &  # писатель
cat /tmp/my_pipe                # читатель

3. Unix Domain Socket

Дуплексный канал связи через файловую систему (не сеть). Быстрее TCP-сокетов, так как не проходит через сетевой стек:

// Сервер:
listener, _ := net.Listen("unix", "/tmp/my.sock")
conn, _ := listener.Accept()
conn.Write([]byte("hello"))

// Клиент:
conn, _ := net.Dial("unix", "/tmp/my.sock")
data, _ := io.ReadAll(conn)

4. Shared Memory (разделяемая память)

Область памяти, отображаемая в адресное пространство нескольких процессов. Самый быстрый IPC (нет копирования данных), но требует синхронизации:

// Через syscall:
fd, _ := syscall.Mmap(-1, 0, 4096, syscall.PROT_READ|syscall.PROT_WRITE,
    syscall.MAP_SHARED|syscall.MAP_ANONYMOUS, -1, 0)
// fd — разделяемая память, доступная из нескольких процессов

5. Message Queues (очереди сообщений)

Структурированные очереди с приоритетами. Процессы отправляют и получают сообщения:

// POSIX message queue через CGO или сторонние библиотеки
// В Go обычно используются внешние брокеры: RabbitMQ, Kafka, NATS

6. Signals (сигналы)

Асинхронные уведомления от ядра или другого процесса. Ограниченный набор сигналов (SIGTERM, SIGKILL, SIGUSR1 и т.д.):

// Обработка сигналов в Go:
sigCh := make(chan os.Signal, 1)
signal.Notify(sigCh, syscall.SIGINT, syscall.SIGTERM)

go func() {
    sig := <-sigCh
    fmt.Println("received signal:", sig)
    cleanup()
    os.Exit(0)
}()

7. Memory-Mapped Files (mmap)

Файл, отображённый в память процесса. Чтение/запись в память = чтение/запись в файл:

import "golang.org/x/exp/mmap"

reader, _ := mmap.Open("/tmp/data.bin")
data := make([]byte, 1024)
reader.ReadAt(data, 0)

8. Sockets (сетевые сокеты)

TCP/UDP сокеты — работают как между процессами на одной машине, так и между машинами:

// TCP сервер:
listener, _ := net.Listen("tcp", ":8080")
conn, _ := listener.Accept()
conn.Write([]byte("hello"))

Сравнение

Механизм	Скорость	Дуплекс	Родственность	Синхронизация
Pipe	Средняя	Нет (однонаправленный)	Только родственные	Нет
Named Pipe	Средняя	Нет	Нет	Нет
Unix Socket	Высокая	Да	Нет	Нет
Shared Memory	Максимальная	Да	Нет	Нужна (мьютексы)
Message Queue	Средняя	Да	Нет	Встроенная
Signal	Максимальная	Нет	Нет	Нет
TCP Socket	Низкая	Да	Нет	Нет

CSP в Go

Каналы Go реализуют модель CSP (Communicating Sequential Processes):

> «Don't communicate by sharing memory; share memory by communicating.»

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

// ❌ Разделяемая память:
var counter int
var mu sync.Mutex
mu.Lock()
counter++
mu.Unlock()

// ✅ Каналы (CSP):
counterCh := make(chan int, 1)
counterCh <- 0
// Горутина-владелец управляет значением:
go func() {
    for delta := range deltaCh {
        counter := <-counterCh
        counterCh <- counter + delta
    }
}()

Вопрос 43. Какой тип данных лучше передавать по каналу в Go для сигнализации (когда не важно значение, а важно сам факт сигнала)?

Таймкод: 01:20:52

Ответ собеседника: Правильный. struct{} (пустая структура) — занимает 0 байт, передача максимально дешёвая. Не стоит передавать структуры — это дорого. chan struct{} идеально для сигнализации.

Правильный ответ:

struct{} — единственный тип в Go, который занимает 0 байт. Идеален для сигнализации.

Почему struct{}

fmt.Println(unsafe.Sizeof(struct{}{})) // 0
fmt.Println(unsafe.Sizeof(true))       // 1 (bool)
fmt.Println(unsafe.Sizeof(0))          // 8 (int на 64-bit)

Типичное использование

// Сигнал завершения:
done := make(chan struct{})

go func() {
    // работа...
    close(done) // сигнал: работа завершена
}()

<-done // ждём завершения

context.WithCancel использует это:

func WithCancel(parent Context) (ctx Context, cancel CancelFunc) {
    c := newCancelCtx(parent)
    propagateCancel(parent, &c)
    return &c, func() { c.cancel(true, Canceled) }
}

type cancelCtx struct {
    done atomic.Value // chan struct{}
    // ...
}

func (c *cancelCtx) Done() <-chan struct{} {
    // возвращает chan struct{} — закрывается при отмене
}

sync.Once тоже:

type Once struct {
    done atomic.Uint32
    m    Mutex
}

func (o *Once) Do(f func()) {
    if o.done.Load() == 0 {
        o.doSlow(f)
    }
}

Небуферизированный vs буферизированный для сигнализации

// Небуферизированный — отправитель ждёт получателя:
ch := make(chan struct{})
go func() {
    ch <- struct{}{} // блокируется, пока кто-то не прочитает
}()
<-ch

// Буферизированный — отправитель не ждёт:
ch := make(chan struct{}, 1)
ch <- struct{}{} // не блокируется
select {
case <-ch:
    fmt.Println("got signal")
default:
    fmt.Println("no signal")
}

sync.WaitGroup как альтернатива

Если нужно дождаться завершения N горутин, sync.WaitGroup предпочтительнее канала:

var wg sync.WaitGroup
for i := 0; i < 10; i++ {
    wg.Add(1)
    go func() {
        defer wg.Done()
        // работа...
    }()
}
wg.Wait() // ждём всех

Итого: chan struct{} — стандартный идиоматичный способ сигнализации в Go. Пустая структура не выделяет память, а закрытие канала — эффективный способ уведомить множество горутин одновременно (broadcast).

Вопрос 44. Чем отличается контейнеризация (Docker) от виртуализации?

Таймкод: 01:22:50

Ответ собеседника: Правильный. Контейнер использует ядро хостовой ОС, изолирован через namespaces и cgroups. Виртуальная машина — полноценная эмуляция со своим ядром через гипервизор. ВМ тяжелее, но полная изоляция. Docker Compose для оркестрации, Kubernetes для кластера.

Правильный ответ:

Ключевое отличие: контейнеры делят ядро хостовой ОС, виртуальные машины имеют собственное ядро.

Архитектура

Виртуализация:
┌──────────┐ ┌──────────┐ ┌──────────┐
│   App    │ │   App    │ │   App    │
│ Guest OS │ │ Guest OS │ │ Guest OS │
├──────────┤ ├──────────┤ ├──────────┤
│   VM     │ │   VM     │ │   VM     │
├──────────┴─┴──────────┴─┴──────────┤
│           Hypervisor                │
├─────────────────────────────────────┤
│           Host OS                   │
├─────────────────────────────────────┤
│           Hardware                  │
└─────────────────────────────────────┘

Контейнеризация:
┌──────────┐ ┌──────────┐ ┌──────────┐
│   App    │ │   App    │ │   App    │
│ Bin/Libs │ │ Bin/Libs │ │ Bin/Libs │
├──────────┤ ├──────────┤ ├──────────┤
│Container │ │Container │ │Container │
├──────────┴─┴──────────┴─┴──────────┤
│        Docker Engine               │
├─────────────────────────────────────┤
│        Host OS (shared kernel)      │
├─────────────────────────────────────┤
│        Hardware                     │
└─────────────────────────────────────┘

Механизмы изоляции в Linux

Docker использует два механизма ядра Linux:

1. Namespaces — изоляция ресурсов:

Namespace	Что изолирует
PID	Процессы (PID 1 в контейнере)
NET	Сеть, порты, интерфейсы
MNT	Файловая система
UTS	Имя хоста
IPC	Межпроцессное взаимодействие
USER	Пользователи и UID/GID

2. Cgroups — ограничение ресурсов:

# Ограничение CPU:
docker run --cpus=1.5 myapp

# Ограничение памяти:
docker run --memory=512m myapp

# Ограничение I/O:
docker read --device-read-bps=/dev/sda:10mb myapp

Сравнение

Характеристика	Контейнер	Виртуальная машина
Ядро	Общее с хостом	Собственное
Вес	Мегабайты	Гигабайты
Запуск	Секунды	Минуты
Изоляция	Процесс	Полная (аппаратная)
Производительность	Почти native	Накладные расходы на эмуляцию
Совместимость ОС	Только Linux-контейнеры на Linux	Любая ОС
Плотность	Сотни на хост	Десятки на хост

Когда что использовать

Сценарий	Выбор
Микросервисы	Контейнеры
CI/CD	Контейнеры
Разработка	Контейнеры
Разные ОС на одном хосте	ВМ
Полная изоляция (безопасность)	ВМ
Устаревшее ПО с особыми требованиями к ядру	ВМ

Docker Compose — оркестрация нескольких контейнеров:

# docker-compose.yml
version: '3'
services:
  app:
    build: .
    ports:
      - "8080:8080"
    depends_on:
      - db
      - redis
  db:
    image: postgres:15
    environment:
      POSTGRES_DB: myapp
    volumes:
      - db_data:/var/lib/postgresql/data
  redis:
    image: redis:7
volumes:
  db_data:

Kubernetes — оркестрация на уровне кластера:

# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp
        image: myapp:latest
        resources:
          requests:
            memory: "256Mi"
            cpu: "250m"
          limits:
            memory: "512Mi"
            cpu: "500m"

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

Вопрос 45. Чем отличаются TCP и UDP? Приведите примеры использования каждого протокола?

Таймкод: 01:24:20

Ответ собеседника: Правильный. TCP — с гарантией доставки и порядка пакетов (HTTP, передача паролей). UDP — без гарантии доставки и порядка (видеозвонки, стриминг). HTTP — протокол прикладного уровня (7-й уровень OSI).

Правильный ответ:

TCP (Transmission Control Protocol) и UDP (User Datagram Protocol) — два основных транспортных протокола (уровень 4 модели OSI).

TCP — надёжная доставка

TCP устанавливает соединение (three-way handshake), гарантирует доставку и порядок пакетов:

Client                    Server
  │    SYN (seq=x)    →    │
  │  ← SYN-ACK (seq=y,     │
  │      ack=x+1)          │
  │    ACK (ack=y+1)  →    │
  │                        │
  │    ═══ соединение ════ │
  │       установлено       │
  │                        │
  │    Data (seq=100)  →   │
  │  ← ACK (ack=101)       │
  │    Data (seq=101)  →   │
  │  ← ACK (ack=102)       │

Механизмы TCP:

• Three-way handshake — установка соединения
• Sequence numbers — порядок пакетов
• ACK — подтверждение получения
• Retransmission — повторная отправка потерянных пакетов
• Flow control — управление потоком (окно передачи)
• Congestion control — управление перегрузкой (slow start, AIMD)

UDP — быстрая доставка без гарантий

UDP не устанавливает соединение, просто отправляет датаграммы:

Client                    Server
  │    Datagram 1     →    │  (может потеряться)
  │    Datagram 2     →    │  (может прийти раньше 1-го)
  │    Datagram 3     →    │
  │                        │
  │  Никаких ACK, никаких  │
  │  повторных отправок    │

Сравнение

Характеристика	TCP	UDP
Соединение	Есть (handshake)	Нет (connectionless)
Гарантия доставки	Да (ACK + retransmit)	Нет
Порядок пакетов	Гарантирован	Не гарантирован
Скорость	Медленнее (overhead)	Быстрее (минимальный overhead)
Заголовок	20–60 байт	8 байт
Flow control	Да	Нет
Congestion control	Да	Нет

Примеры использования

Протокол	Применение	Почему
TCP	HTTP/HTTPS	Целостность веб-страниц критична
TCP	SSH	Потеря пакета = потеря команды
TCP	PostgreSQL, MySQL	Целостность данных
TCP	SMTP	Письмо не должно потеряться
UDP	DNS запросы	Быстрый запрос, можно повторить
UDP	Видеостриминг	Потеря кадра допустима, задержка — нет
UDP	VoIP (голос)	Задержка хуже потери пакета
UDP	Онлайн-игры	Важна скорость, не целостность
UDP	DHCP	Быстрое получение IP

Реализация в Go

// TCP сервер:
listener, _ := net.Listen("tcp", ":8080")
conn, _ := listener.Accept()
buf := make([]byte, 1024)
n, _ := conn.Read(buf)
conn.Write([]byte("response"))

// UDP сервер:
addr, _ := net.ResolveUDPAddr("udp", ":8080")
conn, _ := net.ListenUDP("udp", addr)
buf := make([]byte, 1024)
n, clientAddr, _ := conn.ReadFromUDP(buf)
conn.WriteToUDP([]byte("response"), clientAddr)

QUIC — гибрид

QUIC (используется в HTTP/3) работает поверх UDP, но реализует надёжность на уровне приложения. Это даёт скорость UDP + надёжность TCP, плюс встроенное шифрование (TLS 1.3).

Вопрос 46. Как определить, что соединение TCP разорвано, если удалённая сторона перестала отвечать?

Таймкод: 01:26:09

Ответ собеседника: Правильный. TCP не имеет встроенного механизма определения разрыва без обмена данными. Используются keep-alive пакеты (heartbeat). Если партнёр не отвечает — соединение разорвано. Также TCP keepalive на уровне сокета. Без этого — попытка записи с ошибкой или таймауты на чтение.

Правильный ответ:

Проблема «полуоткрытого соединения» (half-open connection)

TCP не обнаруживает разрыв соединения автоматически, если нет обмена данными. Если удалённая сторона упала (kernel panic, отключение питания, обрыв кабеля без RST) — локальная сторона не узнает об этом бесконечно.

Способы обнаружения

1. TCP Keepalive — на уровне ОС

Встроенный механизм TCP. ОС периодически отправляет probe-пакеты:

conn, _ := net.Dial("tcp", "example.com:80")

// Включение TCP keepalive:
tcpConn := conn.(*net.TCPConn)
tcpConn.SetKeepAlive(true)
tcpConn.SetKeepAlivePeriod(30 * time.Second)

Параметры ядра Linux (по умолчанию):

# Время простоя до начала probe:
net.ipv4.tcp_keepalive_time = 7200  # 2 часа

# Интервал между probe:
net.ipv4.tcp_keepalive_intvl = 75   # 75 секунд

# Количество probe до разрыва:
net.ipv4.tcp_keepalive_probes = 9   # 9 попыток

# Итого: 2ч + 9×75с ≈ 2ч 11мин до обнаружения разрыва

Это очень долго для большинства приложений.

2. Application-level heartbeat — на уровне приложения

Собственный протокол ping/pong на уровне приложения:

// Отправка heartbeat каждые 30 секунд:
func (c *Connection) startHeartbeat() {
    ticker := time.NewTicker(30 * time.Second)
    defer ticker.Stop()

    for range ticker.C {
        c.SetWriteDeadline(time.Now().Add(10 * time.Second))
        if _, err := c.Write([]byte("PING")); err != nil {
            c.Close()
            return
        }
    }
}

// Чтение с таймаутом:
func (c *Connection) readLoop() {
    buf := make([]byte, 1024)
    for {
        c.SetReadDeadline(time.Now().Add(60 * time.Second))
        n, err := c.Read(buf)
        if err != nil {
            if netErr, ok := err.(net.Error); ok && netErr.Timeout() {
                // Таймаут — соединение вероятно мертво
                c.Close()
                return
            }
        }
        // Обработка данных...
    }
}

3. SetReadDeadline / SetWriteDeadline

// Если за 30 секунд не пришли данные — ошибка таймаут:
conn.SetReadDeadline(time.Now().Add(30 * time.Second))
_, err := conn.Read(buf)
if err != nil {
    // Соединение вероятно разорвано
}

4. SO_KEEPALIVE через syscall (более тонкая настройка)

import "sysconn, _ := net.Dial("tcp", "example.com:80")
rawConn, _ := conn.(*net.TCPConn).SyscallConn()

rawConn.Control(func(fd uintptr) {
    syscall.SetsockoptInt(int(fd), syscall.SOL_SOCKET, syscall.SO_KEEPALIVE, 1)
    syscall.SetsockoptInt(int(fd), syscall.IPPROTO_TCP, syscall.TCP_KEEPIDLE, 30)
    syscall.SetsockoptInt(int(fd), syscall.IPPROTO_TCP, syscall.TCP_KEEPINTVL, 5)
    syscall.SetsockoptInt(int(fd), syscall.IPPROTO_TCP, syscall.TCP_KEEPCNT, 3)
})

Это позволяет настроить keepalive агрессивнее, чем системные defaults.

Сравнение подходов

Подход	Время обнаружения	Надёжность	Сложность
TCP keepalive (default)	~2 часа	Средняя	Низкая
TCP keepalive (tuned)	30–60 секунд	Высокая	Средняя
Application heartbeat	Настраиваемое	Высокая	Средняя
Read deadline	Настраиваемое	Средняя	Низкая

Рекомендация: для продакшена используйте комбинацию — TCP keepalive с агрессивными настройками + application-level heartbeat для быстрого обнаружения проблем.

Вопрос 47. Как происходит резолвинг IP-адреса при вводе URL в браузере?

Таймкод: 01:27:44

Ответ собеседника: Правильный. Парсится URL → кэш браузера → системный кэш ОС → маршрутизатор → DNS-сервер. Затем ARP для MAC-адреса. Для HTTPS — проверка HSTS, TLS-handshake, HTTP-запрос.

Правильный ответ:

Полный процесс от ввода URL до получения страницы

1. Парсинг URL

https://www.example.com:443/path?query=value#fragment
├─┬─ ├─────┬─────┤├─┬─┤├─┬─┤├────┬────┤├────┬────┤
scheme  host   port  path  query     fragment

Браузер определяет протокол (https), хост (www.example.com), порт (443), путь.

2. Проверка HSTS (HTTP Strict Transport Security)

Браузер проверяет список HSTS-сайтов. Если сайт есть в списке — запрос сразу идёт по HTTPS, даже если пользователь ввёл HTTP.

3. DNS Resolution (резолвинг домена)

Браузер → Кэш браузера → /etc/hosts → OS DNS cache → DNS resolver → Root DNS → TLD DNS → Authoritative DNS

Подробнее:

1. Кэш браузера (Chrome: chrome://net-internals/#dns)
2. Кэш ОС (systemd-resolved, nscd)
3. /etc/hosts (статический файл)
4. DNS resolver (обычно указан в /etc/resolv.conf)
5. Рекурсивный DNS-сервер (ISP или 8.8.8.8)

Рекурсивный поиск:
  Root DNS (.) → TLD DNS (.com) → Authoritative DNS (example.com)
  Возвращает: www.example.com → 93.184.216.34

4. ARP (Address Resolution Protocol)

Если IP-адрес в локальной сети — через ARP определяется MAC-адрес:

Who has 192.168.1.1? Tell 192.168.1.100 → Broadcast
192.168.1.1 is at AA:BB:CC:DD:EE:FF → Unicast

Если IP в внешней сети — ARP определяет MAC-адрес шлюза (роутера).

5. Установка TCP-соединения (three-way handshake)

Client → Server: SYN (seq=1000)
Server → Client: SYN-ACK (seq=5000, ack=1001)
Client → Server: ACK (ack=5001)

6. TLS Handshake (для HTTPS)

Client → Server: ClientHello (supported cipher suites, SNI)
Server → Client: ServerHello (chosen cipher, certificate)
Client → Server: Key Exchange (pre-master secret)
Both: Derive session keys
Client → Server: Finished
Server → Client: Finished

7. HTTP-запрос

GET /path?query=value HTTP/2
Host: www.example.com
User-Agent: Mozilla/5.0...
Accept: text/html

8. Ответ сервера

HTTP/2 200 OK
Content-Type: text/html
Cache-Control: max-age=3600

<html>...</html>

9. Рендеринг

HTML → DOM → CSSOM → Render Tree → Layout → Paint

Оптимизации

Оптимизация	Описание
DNS prefetching	<link rel="dns-prefetch" href="//cdn.example.com">
Preconnect	<link rel="preconnect" href="https://api.example.com">
HTTP/2 multiplexing	Множество запросов через одно TCP-соединение
TLS 1.3	1-RTT handshake (vs 2-RTT в TLS 1.2)
DNS over HTTPS (DoH)	Шифрованный DNS
QUIC/HTTP/3	0-RTT handshake, мультиплексинг без head-of-line blocking

Вопрос 48. Как происходит обработка HTTP-запроса на сервере (на примере тинькофф.ру)?

Таймкод: 01:29:19

Ответ собеседника: Правильный. Запрос приходит через ingress в Kubernetes. Определяется метод, проверяются разрешённые методы. Статика отдаётся напрямую, API маршрутизируется к обработчику. Корневой путь — статика. Неподдерживаемый метод — 405.

Правильный ответ:

Типичный pipeline обработки HTTP-запроса в высоконагруженном сервисе

Клиент
  │
  ▼
CDN (CloudFlare / CloudFront)
  │  Кэш статики, DDoS protection
  ▼
Load Balancer (L7)
  │  SSL termination, rate limiting
  ▼
Ingress Controller (Kubernetes)
  │  Маршрутизация по хостам/путям
  ▼
Service Mesh (Istio/Linkerd) [опционально]
  │  mTLS, retries, circuit breaking
  ▼
Application Pod
  │
  ├─ Middleware chain:
  │    ├── Request ID generation
  │    ├── Authentication (JWT/OAuth)
  │    ├── Authorization (RBAC)
  │    ├── Rate limiting
  │    ├── Logging
  │    ├── Metrics (Prometheus)
  │    ├── Tracing (OpenTelemetry)
  │    └── Panic recovery
  │
  ├─ Router:
  │    ├── GET / → static/index.html
  │    ├── GET /api/v1/users → UserHandler.List
  │    ├── POST /api/v1/users → UserHandler.Create
  │    └── 404 Not Found
  │
  ├─ Handler:
  │    ├── Validate request
  │    ├── Call service layer
  │    └── Format response
  │
  ├─ Service:
  │    ├── Business logic
  │    ├── Call repositories
  │    └── Publish events
  │
  └─ Repository:
       ├── Database queries
       └── Cache lookups

Реализация на Go

// Middleware:
func authMiddleware(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        token := r.Header.Get("Authorization")
        claims, err := validateToken(token)
        if err != nil {
            http.Error(w, "Unauthorized", 401)
            return
        }
        ctx := context.WithValue(r.Context(), "userID", claims.UserID)
        next.ServeHTTP(w, r.WithContext(ctx))
    })
}

func metricsMiddleware(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        start := time.Now()
        ww := &responseWriter{ResponseWriter: w}
        next.ServeHTTP(ww, r)
        duration := time.Since(start)
        requestDuration.WithLabelValues(r.Method, r.URL.Path).Observe(duration.Seconds())
        requestCounter.WithLabelValues(r.Method, r.URL.Path).Inc()
    })
}

// Router:
func setupRouter() http.Handler {
    mux := http.NewServeMux()

    mux.HandleFunc("/", handleStatic)
    mux.HandleFunc("/api/v1/users", handleUsers)

    // Chain middleware:
    handler := recoveryMiddleware(
        loggingMiddleware(
            metricsMiddleware(
                authMiddleware(mux),
            ),
        ),
    )
    return handler
}

Обработка конкретного запроса

func handleUsers(w http.ResponseWriter, r *http.Request) {
    switch r.Method {
    case http.MethodGet:
        listUsers(w, r)
    case http.MethodPost:
        createUser(w, r)
    default:
        http.Error(w, "Method Not Allowed", 405)
    }
}

func createUser(w http.ResponseWriter, r *http.Request) {
    var req CreateUserRequest
    if err := json.NewDecoder(r.Body).Decode(&req); err != nil {
        http.Error(w, "Bad Request", 400)
        return
    }

    user, err := userService.Create(r.Context(), req)
    if err != nil {
        handleError(w, err)
        return
    }

    w.Header().Set("Content-Type", "application/json")
    w.WriteHeader(201)
    json.NewEncoder(w).Encode(user)
}

Ключевые этапы обработки

Этап	Что происходит
1. Приём	TCP → TLS → HTTP парсер
2. Маршрутизация	Определение handler по method + path
3. Middleware	Auth, rate limit, logging
4. Валидация	Проверка входных данных
5. Бизнес-логика	Service layer
6. Данные	Repository → DB / Cache
7. Ответ	Сериализация, статус-код, заголовки

Статика

Для статических файлов (HTML, CSS, JS, изображения) обычно используется CDN или nginx, минуя приложение:

// Отдача статики:
fs := http.FileServer(http.Dir("./static"))
mux.Handle("/", fs)

// Или через nginx в Kubernetes Ingress:
// nginx.ingress.kubernetes.io/rewrite-target: /

Вопрос 49. Сервис рекомендаций испытывает высокую нагрузку. Как диагностировать проблему и что делать, если узким местом оказалась база данных?

Таймкод: 01:30:09

Ответ собеседника: Правильный. Собрать метрики и логи. Длительность запросов, slow log. Решения: оптимизация запросов, индексы, партицирование, репликация для чтения, rate limiter, несколько инстансов БД, кэширование.

Правильный ответ:

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

Этап 1: Диагностика

1. Метрики (Prometheus + Grafana):

# Длительность запросов (p99):
histogram_quantile(0.99, rate(db_query_duration_seconds_bucket[5m]))

# Количество ошибок:
rate(db_errors_total[5m])

# Количество соединений:
db_connections_active / db_connections_max

# QPS (queries per second):
rate(db_queries_total[5m])

2. Slow query log:

-- PostgreSQL:
-- Включить логирование медленных запросов:
ALTER SYSTEM SET log_min_duration_statement = 100; -- мс
SELECT pg_reload_conf();

-- Анализ медленных запросов:
SELECT query, calls, mean_time, total_time
FROM pg_stat_statements
ORDER BY mean_time DESC
LIMIT 20;

3. EXPLAIN ANALYZE:

EXPLAIN (ANALYZE, BUFFERS, FORMAT TEXT)
SELECT * FROM recommendations
WHERE user_id = 12345
ORDER BY score DESC
LIMIT 10;

Искать: Seq Scan (полное сканирование), отсутствие использования индексов, большое количество rows.

4. Мониторинг блокировок:

-- Активные блокировки:
SELECT blocked_locks.pid AS blocked_pid,
       blocking_locks.pid AS blocking_pid,
       blocked_activity.query AS blocked_query,
       blocking_activity.query AS blocking_query
FROM pg_catalog.pg_locks blocked_locks
JOIN pg_catalog.pg_locks blocking_locks
  ON blocking_locks.locktype = blocked_locks.locktype
  AND blocking_locks.database IS NOT DISTINCT FROM blocked_locks.database
  AND blocking_locks.relation IS NOT DISTINCT FROM blocked_locks.relation
  AND blocking_locks.page IS NOT DISTINCT FROM blocked_locks.page
  AND blocking_locks.tuple IS NOT DISTINCT FROM blocked_locks.tuple
  AND blocking_locks.virtualxid IS NOT DISTINCT FROM blocked_locks.virtualxid
  AND blocking_locks.transactionid IS NOT DISTINCT FROM blocked_locks.transactionid
  AND blocking_locks.classid IS NOT DISTINCT FROM blocked_locks.classid
  AND blocking_locks.objid IS NOT DISTINCT FROM blocked_locks.objid
  AND blocking_locks.objsubid IS NOT DISTINCT FROM blocked_locks.objsubid
  AND blocking_locks.pid != blocked_locks.pid;

Этап 2: Оптимизация запросов

-- Добавить индекс:
CREATE INDEX CONCURRENTLY idx_recommendations_user_score
ON recommendations (user_id, score DESC);

-- Составной индекс для частых запросов:
CREATE INDEX CONCURRENTLY idx_recommendations_user_category
ON recommendations (user_id, category, score DESC)
WHERE active = true; -- partial index

Этап 3: Партицирование

-- Партицирование по времени (для исторических данных):
CREATE TABLE recommendations (
    id BIGSERIAL,
    user_id INT,
    score FLOAT,
    created_at TIMESTAMP
) PARTITION BY RANGE (created_at);

CREATE TABLE recommendations_2024_q1
    PARTITION OF recommendations
    FOR VALUES FROM ('2024-01-01') TO ('2024-04-01');

CREATE TABLE recommendations_2024_q2
    PARTITION OF recommendations
    FOR VALUES FROM ('2024-04-01') TO ('2024-07-01');

Этап 4: Репликация

┌──────────┐     WAL streaming     ┌──────────────┐
│  Primary │ ──────────────────→   │   Replica 1  │ ← SELECT
│  (write) │                       └──────────────┘
│          │     WAL streaming     ┌──────────────┐
│          │ ──────────────────→   │   Replica 2  │ ← SELECT
└──────────┘                       └──────────────┘

// В приложении — разделение на read/write:
type DB struct {
    Primary *gorm.DB // для записи
    Replica *gorm.DB // для чтения
}

func (db *DB) GetUser(ctx context.Context, id int) (*User, error) {
    var user User
    err := db.Replica.WithContext(ctx).First(&user, id).Error
    return &user, err
}

func (db *DB) CreateUser(ctx context.Context, user *User) error {
    return db.Primary.WithContext(ctx).Create(user).Error
}

Этап 5: Кэширование

func (s *Service) GetRecommendations(ctx context.Context, userID int) ([]Recommendation, error) {
    cacheKey := fmt.Sprintf("recs:%d", userID)

    // Сначала проверяем кэш:
    if cached, err := s.cache.Get(ctx, cacheKey); err == nil {
        var recs []Recommendation
        if err := json.Unmarshal(cached, &recs); err == nil {
            return recs, nil
        }
    }

    // Кэш пуст — идём в БД:
    recs, err := s.repo.GetRecommendations(ctx, userID)
    if err != nil {
        return nil, err
    }

    // Сохраняем в кэш:
    data, _ := json.Marshal(recs)
    s.cache.Set(ctx, cacheKey, data, 5*time.Minute)

    return recs, nil
}

Этап 6: Rate limiting

import "golang.org/x/time/rate"

func rateLimitMiddleware(next http.Handler, limiter *rate.Limiter) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        if !limiter.Allow() {
            http.Error(w, "Too Many Requests", 429)
            return
        }
        next.ServeHTTP(w, r)
    })
}

// Или per-user rate limiting:
func perUserRateLimit(userID string) *rate.Limiter {
    // 100 requests per second per user
    return rate.NewLimiter(100, 200)
}

Этап 7: Connection pooling

db, _ := sql.Open("postgres", dsn)
db.SetMaxOpenConns(25)        // максимум открытых соединений
db.SetMaxIdleConns(10)        // максимум idle соединений
db.SetConnMaxLifetime(5 * time.Minute) // время жизни соединения

Приоритет действий

Приоритет	Действие	Эффект	Сложность
1	Добавить индексы	Высокий	Низкая
2	Кэширование	Высокий	Средняя
3	Оптимизация запросов	Высокий	Средняя
4	Read replicas	Высокий	Высокая
5	Партицирование	Средний	Высокая
6	Rate limiting	Средний	Низкая
7	Вертикальное масштабирование	Средний	Низкая

Вопрос 50. Какие типы репликации существуют в PostgreSQL? Чем отличается мастер-слейв от мультимастера? Что такое failover?

Таймкод: 01:32:48

Ответ собеседника: Правильный. Мастер-слейв: один мастер принимает запись, слейвы копируют. Failover — переключение на слейв при падении мастера. Мультимастер: несколько мастеров принимают запись. Плюс — распределение нагрузки на запись. Минус — split-brain, сложность синхронизации.

Правильный ответ:

Типы репликации в PostgreSQL

1. Streaming Replication (потоковая репликация)

Основной механизм. Primary отправляет WAL (Write-Ahead Log) записи на реплики:

Primary                    Replica
  │    WAL records    →     │
  │    (streaming)          │
  │                    →    │  replay WAL
  │                         │

Мастер-слейв (Primary-Replica, асинхронная):

┌──────────┐    WAL stream    ┌──────────┐
│ Primary  │ ──────────────→  │ Replica  │  (read-only)
│ (write)  │                  │ (read)   │
└──────────┘                  └──────────┘
       │
       │ WAL stream    ┌──────────┐
       └─────────────→ │ Replica  │  (read-only)
                       │ (read)   │
                       └──────────┘

• Один primary принимает запись
• Несколько реплик для чтения
• Асинхронная: primary не ждёт подтверждения от реплики
• Риск: потеря данных при падении primary (реплика может отставать)

Синхронная репликация:

-- На primary:
ALTER SYSTEM SET synchronous_standby_names = 'replica1';
ALTER SYSTEM SET synchronous_commit = 'on';
-- primary ждёт подтверждения от replica1 перед commit

2. Logical Replication (логическая репликация, PostgreSQL 10+)

Репликация на уровне отдельных таблиц, а не всего кластера:

┌──────────┐    logical changes    ┌──────────┐
│ Primary  │ ──────────────────→   │ Replica  │
│          │   (table-level)       │ (different tables
└──────────┘                       │  possible) │
                                   └──────────┘

• Можно реплицировать отдельные таблицы
• Реплика может иметь другую схему
• Подходит для интеграции между разными системами

3. Мультимастер (Multi-Master)

Несколько узлов принимают запись:

┌──────────┐  ←──────────────→  ┌──────────┐
│ Node A   │   conflict         │ Node B   │
│ (write)  │   resolution       │ (write)  │
└──────────┘                    └──────────┘
       │                              │
       └──────────┐    ┌──────────────┘
                  ▼    ▼
              ┌──────────┐
              │ Node C   │
              │ (read)   │
              └──────────┘

В PostgreSQL нет встроенного мультимастера. Используются расширения:

• BDR (Bi-Directional Replication) — от EDB
• pglogical — логическая репликация между двумя узлами

Сравнение мастер-слейв и мультимастер

Характеристика	Мастер-слейв	Мультимастер
Точки записи	1	Нсколько
Нагрузка на запись	Централизованная	Распределённая
Конфликты записи	Нет	Возможны (split-brain)
Сложность	Низкая	Высокая
Согласованность	Strong (sync) / Eventual (async)	Eventual
Встроенная поддержка в PG	Да	Нет (расширения)

Failover

Failover — автоматическое переключение на резервный сервер при падении основного.

До failover:              После failover:
┌──────────┐              ┌──────────┐
│ Primary  │ ✗ crashed    │ Replica  │ ← promoted
│ (write)  │              │ (write)  │
└──────────┘              └──────────┘
       │
┌──────────┐              ┌──────────┐
│ Replica  │              │ Replica  │
│ (read)   │              │ (read)   │
└──────────┘              └──────────┘

Инструменты для failover:

• Patroni — автоматический failover для PostgreSQL на базе etcd/ZooKeeper
• pg_auto_failover — автоматический failover от Crunchy Data
• repmgr — управление репликацией и failover

Patroni пример конфигурации:

# patroni.yml
scope: my-cluster
name: node1

restapi:
  listen: 0.0.0.0:8008
  connect_address: 192.168.1.1:8008

etcd:
  hosts: 192.168.1.1:2379,192.168.1.2:2379,192.168.1.3:2379

postgresql:
  listen: 0.0.0.0:5432
  data_dir: /var/lib/postgresql/15/main
  pgpass: /tmp/pgpass
  authentication:
    replication:
      username: replicator
      password: secret
    superuser:
      username: postgres
      password: secret
  parameters:
    wal_level: replica
    max_wal_senders: 5
    hot_standby: on

Split-brain — ситуация, когда два узла считают себя primary:

┌──────────┐              ┌──────────┐
│ Node A   │ ← network →  │ Node B   │
│ thinks:  │   partition   │ thinks:  │
│ "I'm primary"│          │ "I'm primary"│
└──────────┘              └──────────┘
     ↓ writes                  ↓ writes
  данные расходятся → конфликты

Предотвращение: fencing (STONITH — Shoot The Other Node In The Head), quorum (большинство узлов должно согласиться), Witness-узел.

Вопрос 51. Чем отличается синхронная и асинхронная репликация?

Таймкод: 01:34:14

Ответ собеседника: Правильный. Синхронная — мастер ждёт подтверждения от реплик. Плюс: целостность. Минус: медленнее. Асинхронная — мастер не ждёт. Плюс: быстрее. Минус: возможна потеря данных. Полусинхронная — ждёт подтверждения хотя бы от одной реплики.

Правильный ответ:

Это уточняющий вопрос к предыдущему. Приведу краткую сводку с дополнениями.

Синхронная репликация

Client → Primary: COMMIT
Primary → Replica: WAL write
Replica → Primary: ACK (data written)
Primary → Client: COMMIT OK

• Primary ждёт подтверждения от реплики перед возвратом OK клиенту
• Гарантия: данные точно на реплике при успешном commit
• Цена: latency увеличивается (RTT до реплики)
• Риск: если реплика недоступна — запись блокируется

-- Настройка в PostgreSQL:
ALTER SYSTEM SET synchronous_standby_names = 'replica1';
ALTER SYSTEM SET synchronous_commit = 'on';

Асинхронная репликация

Client → Primary: COMMIT
Primary → Client: COMMIT OK (immediately)
Primary → Replica: WAL write (in background)

• Primary возвращает OK сразу, не дожидаясь реплики
• Гарантия: нет — реплика может отставать
• Цена: минимальный latency
• Риск: потеря последних транзакций при падении primary

Полусинхронная репликация

Компромисс: primary ждёт подтверждения хотя бы от одной реплики:

-- Ждём подтверждения от любой одной реплики:
ALTER SYSTEM SET synchronous_standby_names = 'ANY 1 (replica1, replica2)';
ALTER SYSTEM SET synchronous_commit = 'on';

Сравнение

Характеристика	Синхронная	Полусинхронная	Асинхронная
Гарантия целостности	Полная	Частичная	Нет
Latency записи	Высокий	Средний	Низкий
Доступность	Низкая (реплика down = запись стоит)	Средняя	Высокая
Потеря данных при failover	Нет	Минимальная	Возможна

Настройка synchronous_commit в PostgreSQL:

-- off: асинхронная
-- on: синхронная (ждём WAL flush на реплике)
-- remote_write: ждём WAL write (без flush на диск)
-- remote_apply: ждём применения WAL на реплике (самая строгая)
ALTER SYSTEM SET synchronous_commit = 'remote_apply';

Практический совет: для критичных данных (платежи, заказы) — синхронная. Для аналитики, логов — асинхронная. Для большинства случаев — полусинхронная с ANY 1.

Вопрос 52. Как масштабировать приложение при высокой нагрузке? Кэширование, балансировка, client-side vs server-side балансировка.

Таймкод: 01:35:21

Ответ собеседника: Правильный. Кэширование (Redis, in-memory), несколько инстансов, server-side балансировка (гибкость, но доп. хоп) vs client-side (быстрее, но сложнее обновлять список серверов), rate limiter.

Правильный ответ:

Стратегии масштабирования при высокой нагрузке

1. Кэширование

Иерархия кэшей:

Client → CDN → In-Memory Cache → Redis → Database
         ↑           ↑              ↑
    статикка    горячие данные   тёплые данные
    (самый     (per-process)    (shared cache,
    быстрый)                    network hop)

In-Memory Cache (per-process):

import "github.com/patrickmn/go-cache"

var localCache = cache.New(5*time.Minute, 10*time.Minute)

func (s *Service) GetUser(ctx context.Context, id int) (*User, error) {
    cacheKey := fmt.Sprintf("user:%d", id)

    // Проверяем локальный кэш:
    if data, found := localCache.Get(cacheKey); found {
        return data.(*User), nil
    }

    // Проверяем Redis:
    if data, err := s.redis.Get(ctx, cacheKey).Result(); err == nil {
        var user User
        if err := json.Unmarshal([]byte(data), &user); err == nil {
            localCache.Set(cacheKey, &user, cache.DefaultExpiration)
            return &user, nil
        }
    }

    // Идём в БД:
    user, err := s.repo.GetUser(ctx, id)
    if err != nil {
        return nil, err
    }

    // Сохраняем в Redis и локальный кэш:
    data, _ := json.Marshal(user)
    s.redis.Set(ctx, cacheKey, data, 10*time.Minute)
    localCache.Set(cacheKey, user, 5*time.Minute)

    return user, nil
}

Redis (shared cache):

// Cache-Aside pattern:
func (s *Service) GetRecommendations(ctx context.Context, userID int) ([]Rec, error) {
    key := fmt.Sprintf("recs:%d", userID)

    // 1. Проверяем кэш:
    if data, err := s.redis.Get(ctx, key).Result(); err == nil {
        var recs []Rec
        if err := json.Unmarshal([]byte(data), &recs); err == nil {
            return recs, nil
        }
    }

    // 2. Кэш пуст — идём в БД:
    recs, err := s.repo.GetRecs(ctx, userID)
    if err != nil {
        return nil, err
    }

    // 3. Сохраняем в кэш:
    data, _ := json.Marshal(recs)
    s.redis.Set(ctx, key, data, 5*time.Minute)

    return recs, nil
}

// Write-Through pattern (запись через кэш):
func (s *Service) UpdateUser(ctx context.Context, user *User) error {
    // 1. Пишем в БД:
    if err := s.repo.Update(ctx, user); err != nil {
        return err
    }

    // 2. Инвалидируем кэш:
    key := fmt.Sprintf("user:%d", user.ID)
    s.redis.Del(ctx, key)

    return nil
}

Проблемы кэширования:

Проблема	Описание	Решение
Cache stampede	Много запросов при истечении кэша	Singleflight, mutex
Cold start	Пустой кэш после рестарта	Pre-warming
Consistency	Кэш устарел	TTL, invalidation

// Защита от cache stampede с singleflight:
import "golang.org/x/sync/singleflight"

var sf singleflight.Group

func (s *Service) GetUserSingleflight(ctx context.Context, id int) (*User, error) {
    key := fmt.Sprintf("user:%d", id)

    result, err, _ := sf.Do(key, func() (interface{}, error) {
        return s.getUserFromDB(ctx, id)
    })
    if err != nil {
        return nil, err
    }
    return result.(*User), nil
}

2. Балансировка нагрузки

Server-Side Balancing (L4/L7):

                    ┌─────────────┐
Client ──────────→  │  Nginx/HAProxy │ ──→ Instance 1
                    │  (balancer)  │ ──→ Instance 2
                    └─────────────┘ ──→ Instance 3

# Nginx upstream:
upstream backend {
    least_conn;  # алгоритм: наименьшее число соединений

    server 10.0.0.1:8080 weight=3;
    server 10.0.0.2:8080 weight=2;
    server 10.0.0.3:8080 backup;  # резервный

    keepalive 32;  # постоянные соединения
}

server {
    location / {
        proxy_pass http://backend;
        proxy_next_upstream error timeout http_502 http_503;
    }
}

Алгоритмы балансировки:

Алгоритм	Описание	Когда использовать
Round Robin	По очереди	Одинаковые серверы
Least Connections	Меньше всего соединений	Разная длительность запросов
IP Hash	Хэш от IP клиента	Сессионная привязка
Weighted	С весами	Разные мощности серверов

Client-Side Balancing:

// gRPC с client-side balancing:
import "google.golang.org/grpc"
import "google.golang.org/grpc/balancer/roundrobin"

conn, err := grpc.Dial(
    "dns:///my-service.example.com",
    grpc.WithDefaultServiceConfig(`{
        "loadBalancingConfig": [{"round_robin":{}}]
    }`),
    grpc.WithTransportCredentials(insecure.NewCredentials()),
)

// Или кастомный балансировщик:
type clientBalancer struct {
    instances []string
    mu        sync.Mutex
    idx       int
}

func (b *clientBalancer) Next() string {
    b.mu.Lock()
    defer b.mu.Unlock()
    inst := b.instances[b.idx%len(b.instances)]
    b.idx++
    return inst
}

func (b *clientBalancer) UpdateInstances(instances []string) {
    b.mu.Lock()
    defer b.mu.Unlock()
    b.instances = instances
    b.idx = 0
}

Сравнение Server-Side vs Client-Side

Характеристика	Server-Side	Client-Side
Доп. сетевой хоп	Да	Нет
Гибкость изменения списка	Высокая	Низкая (нужен service discovery)
Сложность	Простая	Сложнее
Latency	Выше	Ниже
Single point of failure	Да (balancer)	Нет
Примеры	Nginx, HAProxy, AWS ALB	gRPC, Netflix Ribbon

Service Discovery для client-side:

// Использование Consul для service discovery:
import "github.com/hashicorp/consul/api"

func discoverServices(consulAddr, serviceName string) ([]string, error) {
    config := api.DefaultConfig()
    config.Address = consulAddr
    client, err := api.NewClient(config)
    if err != nil {
        return nil, err
    }

    services, _, err := client.Health().Service(serviceName, "", true, nil)
    if err != nil {
        return nil, err
    }

    var instances []string
    for _, svc := range services {
        addr := fmt.Sprintf("%s:%d", svc.Service.Address, svc.Service.Port)
        instances = append(instances, addr)
    }
    return instances, nil
}

3. Rate Limiting

// Token bucket rate limiter:
import "golang.org/x/time/rate"

func rateLimitMiddleware(limiter *rate.Limiter) func(http.Handler) http.Handler {
    return func(next http.Handler) http.Handler {
        return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
            if !limiter.Allow() {
                http.Error(w, "Too Many Requests", http.StatusTooManyRequests)
                return
            }
            next.ServeHTTP(w, r)
        })
    }
}

// Per-user rate limiter:
type UserRateLimiter struct {
    limiters map[string]*rate.Limiter
    mu       sync.RWMutex
    rate     rate.Limit
    burst    int
}

func (rl *UserRateLimiter) Allow(userID string) bool {
    rl.mu.RLock()
    limiter, exists := rl.limiters[userID]
    rl.mu.RUnlock()

    if !exists {
        rl.mu.Lock()
        limiter = rate.NewLimiter(rl.rate, rl.burst)
        rl.limiters[userID] = limiter
        rl.mu.Unlock()
    }

    return limiter.Allow()
}

4. Горизонтальное масштабирование

                    ┌─────────────┐
                    │   Nginx     │
                    └──────┬──────┘
                           │
            ┌──────────────┼──────────────┐
            ▼              ▼              ▼
     ┌────────────┐ ┌────────────┐ ┌────────────┐
     │ Instance 1 │ │ Instance 2 │ │ Instance 3 │
     └─────┬──────┘ └─────┬──────┘ └─────┬──────┘
           │              │              │
           └──────────────┼──────────────┘
                          ▼
                   ┌─────────────┐
                   │    Redis    │
                   │   Cluster   │
                   └──────┬──────┘
                          ▼
                   ┌─────────────┐
                   │  PostgreSQL │
                   │  Primary +  │
                   │  Replicas   │
                   └─────────────┘

Порядок действий при росте нагрузки:

1. Кэширование — быстрый эффект, низкая сложность
2. Connection pooling — оптимизация соединений с БД
3. Read replicas — распределение чтения
4. Горизонтальное масштабирование — добавление инстансов
5. Rate limiting — защита от перегрузки
6. Шардирование БД — крайняя мера

Вопрос 53. Можно ли использовать канал с булевым значением в качестве мьютекса в Go?

Таймкод: 01:46:43

Ответ собеседника: Правильный. Да, можно использовать канал с булевым значением или chan struct{} как мьютекс. Но это не идиоматический подход. Лучше использовать sync.Mutex для простых случаев.

Правильный ответ:

Реализация мьютекса на канале

Да, технически это возможно. Вот как это выглядит:

// Мьютекс на буферизированном канале ёмкости 1:
type ChannelMutex struct {
    ch chan struct{}
}

func NewChannelMutex() *ChannelMutex {
    return &ChannelMutex{
        ch: make(chan struct{}, 1),
    }
}

func (m *ChannelMutex) Lock() {
    m.ch <- struct{}{}  // Блокируется, если канал полон
}

func (m *ChannelMutex) Unlock() {
    <-m.ch  // Освобождает слот
}

// Использование:
var mu NewChannelMutex()
mu.Lock()
// критическая секция
mu.Unlock()

С таймаутом через select:

func (m *ChannelMutex) TryLock(timeout time.Duration) bool {
    select {
    case m.ch <- struct{}{}:
        return true
    case <-time.After(timeout):
        return false  // Не удалось захватить за timeout
    }
}

Почему это работает

Булканизированный канал ёмкости 1 может находиться в двух состояниях:

• Пустой — мьютекс свободен, операция записи проходит мгновенно
• Полный — мьютекс захвачен, операция записи блокируется

Это аналогично бинарному семафору.

Сравнение с sync.Mutex

Характеристика	Channel Mutex	sync.Mutex
Базовая функциональность	Да	Да
TryLock с таймаутом	Да (через select)	Нет (Go 1.18+ есть TryLock)
Справедливость (FIFO)	Да (каналы FIFO)	Нет (горутина может захватить раньше)
Производительность	Медленнее (аллокации, scheduling)	Быстрее (runtime оптимизации)
Читаемость	Сложнее	Проще
Deadlock detection	Нет	Нет

Бенчмарк:

func BenchmarkChannelMutex(b *testing.B) {
    m := NewChannelMutex()
    b.RunParallel(func(pb *testing.PB) {
        for pb.Next() {
            m.Lock()
            // пустая критическая секция
            m.Unlock()
        }
    })
}

func BenchmarkSyncMutex(b *testing.B) {
    var m sync.Mutex
    b.RunParallel(func(pb *testing.PB) {
        for pb.Next() {
            m.Lock()
            m.Unlock()
        }
    })
}

Результат: sync.Mutex обычно в 2-5 раз быстрее.

Когда канальный мьютекс имеет смысл

Единственный практический случай — когда нужен TryLock с таймаутом (до Go 1.18):

func (m *ChannelMutex) LockWithContext(ctx context.Context) error {
    select {
    case m.ch <- struct{}{}:
        return nil
    case <-ctx.Done():
        return ctx.Err()
    }
}

Рекомендация: Используйте sync.Mutex или sync.RWMutex для мьютексов. Каналы в Go предназначены для коммуникации между горутинами, а не для реализации примитивов синхронизации. Это нарушает идиому Go: "Don't communicate by sharing memory; share by communicating."