Открытое интервью на Middle Go-разработчика

17 мая 2024 г. · 86 мин. чтения

Сегодня мы разберём реальное собеседование по Go, в ходе которого интервьюер и кандидат вместе погружаются в тонкости языка — от примитивов синхронизации и работы планировщика до реализации Worker Pool с нуля. Это не просто проверка знаний, а живой технический диалог, в котором кандидат демонстрирует как глубокое понимание рантайма Go, так и практические навыки написания чистого, идиоматичного кода.

Вопрос 1. Кандидат рассказывает о себе и профессиональном опыте работы.

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

Ответ собеседника: Правильный. Кандидат работал стажёром в компании Albion (около 10 месяцев), затем перешёл в Platon на позицию junior, где вырос до middle. Сейчас работает в Platon около 1.5 лет, сменил несколько команд: начинал в автоматизации, сейчас работает в команде origination.

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

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

Структура ответа

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

Пример структурированного ответа

> «Я backend-разработчик с опытом около 2.5 лет. Начинал стажёром в компании Albion, где работал с Java и Spring. Затем перешёл в Platon на позицию junior Go-разработчика. За 1.5 года вырос до middle. > > В Platon сменил две команды. В команде автоматизации разрабатывал внутренние инструменты для CI/CD пайплайнов, что сократило время деплоя на 30%. Сейчас работаю в команде origination — занимаюсь сервисами, которые обрабатывают заявки на оформление продуктов. Основной стек — Go, PostgreSQL, Kafka, gRPC. > > Выбрал Go за его модель конкурентности через горутины и каналы, а также за строгую типизацию и предсказуемое поведение рантайма, что упрощает поддержку сервисов в production.»

На что обращает внимание интервьюер

Конкретика: цифры, метрики, названия технологий и протоколов (gRPC, Kafka, PostgreSQL) показывают глубину погружения.
Понимание бизнес-контекста: упоминание origination и обработки заявок демонстрирует, что вы понимаете, зачем существует ваш сервис.
Траектория роста: переход от стажёра к middle за 2.5 года — хороший темп развития.
Мобильность между командами: смена команд внутри компании показывает адаптивность и способность быстро погружаться в новые домены.

Вопрос 2. Что будет выведено в программе с указателями и функцией в Go?

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

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

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

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

Передача указателя по значению

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

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

Пример кода

package main

import "fmt"

func modifyValue(ptr *int) {
    // Меняем данные по адресу — это видно снаружи
    *ptr = 100
}

func reassignPointer(ptr *int) {
    // Перемещаем локальную копию указателя
    x := 200
    ptr = &x
    fmt.Println("Inside reassignPointer:", *ptr) // 200
}

func main() {
    a := 42
    p := &a

    fmt.Println("Before modifyValue:", *p) // 42
    modifyValue(p)
    fmt.Println("After modifyValue:", *p)  // 100 — значение изменилось

    fmt.Println("Before reassignPointer:", *p) // 100
    reassignPointer(p)
    fmt.Println("After reassignPointer:", *p)  // 100 — значение НЕ изменилось
}

Вывод программы

Before modifyValue: 42
After modifyValue: 100
Before reassignPointer: 100
Inside reassignPointer: 200
After reassignPointer: 100
**

**Когда нужно менять сам указатель**

Если необходимо изменить указатель снаружи функции (например, при реализации связанных списков или деревьев), нужно передавать указатель на указатель:

```go
type Node struct \{
    Value int
    Next  *Node
\}

func insertAtHead(head **Node, value int) \{
    newNode := &amp;Node\{Value: value, Next: *head\}
    *head = newNode
\}

func main() \{
    var head *Node

    insertAtHead(&amp;head, 3)
    insertAtHead(&amp;head, 2)
    insertAtHead(&amp;head, 1)

    // Список: 1 -&gt; 2 -&gt; 3
    for curr := head; curr != nil; curr = curr.Next \{
        fmt.Println(curr.Value)
    \}
\}

Ключевые выводы

Go не имеет передачи по ссылке в стиле C++ — всегда копирование.
Работа с данными через указатель (*ptr = value) изменяет оригинал.
Переопределение указателя (ptr = &newValue) влияет только на локальную копию.
Для изменения самого указателя снаружи используйте **T (указатель на указатель) или возвращайте новый указатель из функции.

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

Вопрос 3. Как исправить код, чтобы вывелась 5?

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

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

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

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

Проблема

package main

import "fmt"

func change(ptr *int) {
    ptr = ptr  // ничего не делает, или ptr перемещается на другой адрес
}

func main() {
    x := 0
    p := &x
    change(p)
    fmt.Println(*p) // выводит 0, а не 5
}

Вариант 1: Изменить значение по адресу (разыменование)

Самый простой и идиоматичный способ — разыменовать указатель и записать новое значение:

package main

import "fmt"

func change(ptr *int) {
    *ptr = 5 // записываем 5 по адресу, на который указывает ptr
}

func main() {
    x := 0
    p := &x
    change(p)
    fmt.Println(*p) // выводит 5
}

Вариант 2: Вернуть новый указатель

Если по логике задачи нужно создать новую переменную, возвращаем указатель на неё:

package main

import "fmt"

func change() *int {
    x := 5
    return &x
}

func main() {
    p := change()
    fmt.Println(*p) // выводит 5
}

Вариант 3: Указатель на указатель

Используется редко, но иногда необходимо:

package main

import "fmt"

func change(ptr **int) {
    x := 5
    *ptr = &x
}

func main() {
    x := 0
    p := &x
    change(&p)
    fmt.Println(*p) // выводит 5
}

Когда какой вариант использовать

Разменование (*ptr = value) — стандартный подход для изменения существующего значения. Используется в 90% случаев.
Возврат нового указателя — когда нужно создать новый объект (например, при инициализации структур).
Указатель на указатель (**T) — редко, в основном при работе с низкоуровневыми структурами данных или C-совместимым кодом.

Идиоматичный паттерн в Go

В Go чаще всего используют возвращаемые значения вместо указателей на указатели:

// Плохо — не по-Go-шному
func initService(cfg **Config) { ... }

// Хорошо — возвращаем результат
func newService(cfg Config) *Service { ... }

Ключевой вывод

Чтобы изменить значение через указатель, нужно разыменовать его при присваивании: *ptr = 5. Просто ptr = value не скомпилируется (несовместимые типы), а ptr = &value изменит только локальную копию указателя внутри функции.

Вопрос 4. Что такое слайс в Go и как он устроен внутренне?

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

Ответ собеседника: Правильный. Кандидат объяснил, что слайс — это структура из трёх полей: указатель на нижележащий массив, длина (len) и ёмкость (cap). На 64-битной системе это 24 байта (8+8+8).

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

Слайс (slice) в Go — это динамическая обёртка над массивом, которая позволяет работать с последовательностями элементов переменной длины.

Внутренняя структура

Слайс представлен заголовком reflect.SliceHeader:

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

На 64-битной системе каждый поле занимает 8 байт, итого 24 байта — это фиксированный размер заголовка слайса независимо от количества элементов.

Как работает нижележащий массив

// Создаём слайс
s := make([]int, 3, 5)

// Внутри памяти:
// [0][0][0][?][?]
//  ^           ^
//  Data        Data + Cap
//  |<- Len ->|
//
// Len = 3, Cap = 5

Операции со слайсами

Создание и инициализация:

// Литерал
a := []int{1, 2, 3} // Len=3, Cap=3

// make с указанием ёмкости
b := make([]int, 3, 5) // Len=3, Cap=5

// Из массива
arr := [5]int{1, 2, 3, 4, 5}
c := arr[1:4] // Len=3, Cap=4

Добавление элементов (append):

s := make([]int, 0, 3)

s = append(s, 1) // Len=1, Cap=3
s = append(s, 2) // Len=2, Cap=3
s = append(s, 3) // Len=3, Cap=3
s = append(s, 4) // Len=4, Cap=6 (удвоение!)

Реаллокация при append

Когда Len превышает Cap, происходит реаллокация:

Выделяется новый нижележащий массив большего размера.
Элементы копируются в новый массив.
Новый элемент добавляется.
Возвращается новый заголовок слайса.

Стратегия роста (зависит от компилятора, примерная):

Для маленьких слайсов (cap < 1024): удвоение ёмкости.
Для больших слайсов: увеличение на ~25%.

Срез слайса (slicing)

Срез создаёт новый заголовок, но тот же нижележащий массив:

original := []int{1, 2, 3, 4, 5}
sub := original[1:3] // [2, 3], Len=2, Cap=4

sub[0] = 99
fmt.Println(original) // [1, 99, 3, 4, 5] — изменился!

Проверка на nil

var s1 []int          // nil слайс: Data=nil, Len=0, Cap=0
s2 := []int{}         // пустой слайс: Data≠nil, Len=0, Cap=0
s3 := make([]int, 0)  // пустой слайс: Data≠nil, Len=0, Cap=0

fmt.Println(s1 == nil) // true
fmt.Println(s2 == nil) // false
fmt.Println(s3 == nil) // false

Копирование элементов

src := []int{1, 2, 3}
dst := make([]int, len(src))

n := copy(dst, src) // возвращает количество скопированных элементов
fmt.Println(n, dst) // 3 [1 2 3]

Практические рекомендации

Предварительно аллоцируйте ёмкость, если знаете примерный размер: make([]int, 0, expectedSize).
Не держите ссылки на подслайсы больших слайсов — это предотвращает сборку мусора нижележащего массива.
Передавайте слайсы в функции — заголовок копируется (24 байта), но данные разделяются.
Используйте copy для независимого дублирования слайса.

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

Вопрос 5. Как работает append и почему используется коэффициент роста слайса?

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

Ответ собеседника: Правильный. При append выделяется новый участок памяти. Для маленьких слайсов размер удваивается, начиная с ~1024 элементов — увеличение на 25%. Это сделано для экономии памяти, так как поиск большого непрерывного блока — дорогая операция.

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

Функция append — встроенная функция Go для добавления элементов к слайсу. Её поведение напрямую зависит от текущей ёмкости слайса.

Алгоритм работы append

// Упрощённая логика append
func append(slice []Type, elems ...Type) []Type {
    if len(slice) + len(elems) <= cap(slice) {
        // Ёмкости достаточно — расширяем len, элементы на месте
        return slice[:len(slice)+len(elems)]
    }
    
    // Ёмкости недостаточно — нужна реаллокация
    newCap := calculateNewCap(slice.cap, len(elems))
    newSlice := make([]Type, len(slice)+len(elems), newCap)
    copy(newSlice, slice)
    // копируем новые элементы
    return newSlice
}

Стратегия роста ёмкости

Точная стратегия зависит от версии Go и размера элемента, но общая логика:

Текущая ёмкость	Новая ёмкость
< 256	×2
256–1024	×1.75–2
> 1024	×1.25

func demonstrateGrowth() {
    s := make([]int, 0)
    prevCap := 0
    
    for i := 0; i < 2000; i++ {
        s = append(s, i)
        if cap(s) != prevCap {
            fmt.Printf("Len: %4d, Cap: %4d, Growth: %.2f\n", 
                len(s), cap(s), float64(cap(s))/float64(prevCap))
            prevCap = cap(s)
        }
    }
}

Пример вывода:

Len:    1, Cap:    1, Growth: +Inf
Len:    2, Cap:    2, Growth: 2.00
Len:    3, Cap:    4, Growth: 2.00
Len:    5, Cap:    8, Growth: 2.00
Len:    9, Cap:   16, Growth: 2.00
...
Len: 1025, Cap: 1280, Growth: 1.25

Почему именно такой коэффициент

Амортизированная сложность O(1):

Если каждый раз увеличивать ёмкость на константу (например, +10), то при добавлении N элементов суммарная стоимость копирований будет O(N²). Удвоение гарантирует, что суммарная стоимость всех копирований — O(N), а значит амортизированная стоимость одного добавления — O(1).

Математическое обоснование:

При удвоении ёмкости, когда слайс достигает размера N, общее количество скопированных элементов:

1 + 2 + 4 + 8 + ... + N/2 + N = 2N - 1 = O(N)

Почему для больших слайсов коэффициент уменьшается:

Фрагментация памяти: большие непрерывные блоки сложнее найти.
Экономия памяти: удвоение 1GB слайса означает выделение 2GB, что избыточно.
Кэш-эффективность: слишком большие аллокации могут не поместиться в кэш.

Подводные камни append

Потеря ссылки на новый слайс:

func badAppend(s []int) {
    s = append(s, 42) // изменяет локальную копию заголовка!
}

func goodAppend(s *[]int) {
    *s = append(*s, 42) // изменяет оригинальный слайс
}

// Или возвращайте новый слайс:
func bestAppend(s []int) []int {
    return append(s, 42)
}

Разделяемое состояние после среза:

original := make([]int, 3, 5)
original[0], original[1], original[2] = 1, 2, 3

sub := original[:2]
sub = append(sub, 99) // cap(sub) = 4, реаллокации НЕ будет

fmt.Println(original) // [1 2 99] — третий элемент перезаписан!

Практические рекомендации

// 1. Предварительно аллоцируйте, если знаете размер
result := make([]int, 0, expectedSize)

// 2. Возвращайте слайс из функций
func process(items []int) []int {
    return append(items, newItem)
}

// 3. Для независимой копии используйте copy
independentCopy := make([]int, len(original))
copy(independentCopy, original)

// 4. Для вставки в середину
func insert(s []int, i int, v int) []int {
    s = append(s, 0)          // расширяем
    copy(s[i+1:], s[i:])      // сдвигаем вправо
    s[i] = v                   // вставляем
    return s
}

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

Вопрос 6. Как работает добавление элементов (append) в слайс и почему используется коэффициент роста?

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

Ответ собеседника: Правильный. Кандидат объяснил, что при append выделяется новый участок памяти. Для маленьких слайсов размер удваивается, начиная с ~1024 элементов увеличение происходит на 25%. Это сделано для экономии памяти, так как поиск большого непрерывного блока памяти — дорогая операция.

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

Этот вопрос дублирует предыдущий (Вопрос 5), поэтому приведу краткое резюме с дополнительными нюансами.

Краткий ответ:

Функция append проверяет, достаточно ли ёмкости нижележащего массива. Если да — просто увеличивает Len. Если нет — выделяет новый массив с увеличенной ёмкостью, копирует элементы и добавляет новые.

Стратегия роста:

Малые слайсы (< 256 элементов): удвоение ёмкости — обеспечивает амортизированную O(1) стоимость.
Большие слайсы (> 1024 элементов): увеличение на ~25% — баланс между частотой реаллокаций и расходом памяти.

Дополнительные нюансы:

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

// Пример: разный рост для разных типов
small := make([]byte, 1024)    // мелкие элементы
large := make([][1024]byte, 1024) // крупные элементы

// После append коэффициенты роста будут разными

Также стоит помнить, что append не гарантирует in-place модификацию — всегда используйте возвращаемое значение:

s = append(s, item) // правильно
append(s, item)     // неправильно — результат теряется

Подробное объяснение с примерами кода и математическим обоснованием амортизированной сложности см. в ответе на Вопрос 5.

Вопрос 7. Какие абстракции памяти используются в Go для избежания фрагментации?

Таймкод: 00:15:53

Ответ собеседника: Неполный. Кандидат знает про арены, но не использовал их в продакшн-коде. Не смог назвать конкретные структуры данных, используемые для управления памятью.

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

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

Уровни управления памятью в Go

А. mspan — единица управления страницами

mspan — это структура, представляющая один или несколько последовательных страниц памяти (по 8 КБ каждая). Каждый mspan отвечает за объекты определённого размера (size class).

// Упрощённая структура (из runtime)
type mspan struct {
    next     *mspan     // следующий span в списке
    prev     *mspan     // предыдущий span в списке
    startAddr uintptr   // начальный адрес
    npages    uintptr   // количество страниц
    spanclass uint8     // класс размера (0–67)
    
    // Битовая карта для отслеживания свободных слотов
    allocBits  *gcBits
    gcmarkBits *gcBits
}

Б. Size classes — классы размеров

Go разделяет все возможные размеры объектов на ~68 классов (от 8 байт до 32 КБ). Каждый класс имеет фиксированный размер слота и максимальное количество объектов на странице.

Size Class	Размер слота	Объектов на странице (8 КБ)
1	8 B	1024
2	16 B	512
3	24 B	341
...	...	...
67	32 KB	1

Это предотвращает внешнюю фрагментацию: объекты одного размера всегда выделяются в слоты одинакового размера.

В. mcache — локальный кэш для каждого P

Каждый логический процессор (P) имеет свой mcache — локальный кэш mspan-ов для каждого size class. Это позволяет делать мелкие аллокации без блокировок:

type mcache struct {
    // Массив span-ов для каждого size class
    alloc [numSpanClasses]*mspan
}

// numSpanClasses = 68 * 2 (с учётом noscan/scan)

Г. mcentral — центральный пул span-ов

Когда mcache не имеет свободного mspan нужного класса, он обращается к mcentral:

type mcentral struct {
    spanclass spanClass
    partial   [2]spanSet // частично занятые span-ы
    full      [2]spanSet // полностью занятые span-ы
}

mcentral общий для всех P, поэтому доступ к нему защищён мьютексом.

Д. mheap — глобальная куча

mheap управляет всей виртуальной памятью процесса:

type mheap struct {
    arenas [1 << arenaL1Bits]*[1 << arenaL1Bits]*heapArena
    central [numSpanClasses]mcentral
    // ...
}

Е. Arena — арены памяти

Арена — большой непрерывный блок памяти (64 МБ на 64-битных системах), из которого выделяются mspan-ы:

type heapArena struct {
    bitmap       [heapArenaBitmapBytes]uint8
    spans        [pagesPerArena]*mspan
    pageInUse    [pagesPerArena / 8]uint8
    pageMarks    [pagesPerArena / 8]uint8
}

Ж. Предотвращение фрагментации

Внутренняя фрагментация (потери внутри слотов):

Минимизируется за счёт большого количества size classes (~68).
Для объектов > 32 КБ используются выделения на уровне mheap с округлением до страниц.

Внешняя фрагментация (потери между слотами):

mspan всегда содержит последовательные страницы — нет дыр внутри span.
Освобождённые объекты помечаются в битовой карте, слоты повторно используются.
GC компактизирует память в span-ах через битовые карты пометок.

З. sync.Pool — пулы объектов

Для высокочастотных аллокаций приложение может использовать sync.Pool:

var bufferPool = sync.Pool{
    New: func() interface{} {
        return make([]byte, 4096)
    },
}

func process() {
    buf := bufferPool.Get().([]byte)
    defer bufferPool.Put(buf)
    
    // используем buf
}

И. Arena API (экспериментальный, Go 1.20+)

import "arena"

func process() {
    a := arena.NewArena()
    defer a.Free() // освободить ВСЮ память арены разом
    
    s := arena.MakeSlice[int](a, 0, 100)
    s = arena.Append(a, s, 1, 2, 3)
    
    // Все объекты в арене освобождаются вместе — нулевая фрагментация
}

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

Схема иерархии

mheap (глобальная куча)
  └── arenas (64 МБ блоки)
        └── mspan (1–N страниц по 8 КБ)
              └── слоты фиксированного размера (size class)

mcache (на каждого P, без блокировок)
  └── cached mspan для каждого size class

mcentral (общий, с мьютексом)
  └── partial/full span-ы для каждого size class

Ключевые выводы

Size classes устраняют внешнюю фрагментацию для мелких объектов.
mcache обеспечивает lock-free аллокации для горутин.
mspan гарантирует непрерывность памяти внутри span.
sync.Pool и arena — инструменты приложения для контроля над жизненным циклом объектов.
Go runtime спроектирован так, чтобы аллокация мелких объектов была максимально быстрой и не создавала фрагментации.

Вопрос 8. Как устроена мапа в Go и какие методы разрешения коллизий существуют?

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

Ответ собеседника: Правильный. Мапа обеспечивает чтение и запись за O(1) в среднем. Метод цепочек и метод открытой адресации. При большом количестве коллизий сложность деградирует.

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

Мапа (map) в Go — это хеш-таблица, реализованная в runtime. Она использует метод цепочек (chaining) для разрешения коллизий.

Внутренняя структура

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

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

type bmap struct {
    tophash [bucketCnt]uint8 // старшие биты хеша для каждого ключа
    // После заголовка идут:
    // keys[bucketCnt]keytype
    // values[bucketCnt]valuetype
    // overflow uintptr (указатель на следующий бакет)
}

Бакет (bucket)

Содержит до 8 пар ключ-значение.
bucketCnt = 8 — константа, выбранная для кэш-эффективности.
Каждый бакет имеет указатель overflow на следующий бакет в цепочке.

Процесс поиска значения

// Упрощённая логика поиска
func mapaccess(t *maptype, h *hmap, key unsafe.Pointer) unsafe.Pointer {
    hash := t.hasher(key, h.hash0)
    
    // Определяем бакет: hash & (2^B - 1)
    bucket := hash & ((1 << h.B) - 1)
    b := (*bmap)(add(h.buckets, bucket*uintptr(t.bucketsize)))
    
    // Старшие 8 бит хеша для быстрого сравнения
    top := tophash(hash)
    
    for ; b != nil; b = b.overflow() {
        for i := 0; i < bucketCnt; i++ {
            if b.tophash[i] == top && t.keys.equal(key, b.keys[i]) {
                return b.values[i] // нашли!
            }
        }
    }
    return nil // не нашли
}

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

А. Метод цепочек (Go использует этот)

Каждый бакет содержит указатель overflow на следующий бакет. При коллизии элемент помещается в overflow-бакет.

Bucket 0: [k1,v1] [k2,v2] [k3,v3] [---] [---] [---] [---] [---] -> overflow
Bucket 1: [---] [---] [---] [---] [---] [---] [---] [---]
...

overflow: [k4,v4] [---] [---] [---] [---] [---] [---] [---]

Б. Метод открытой адресации (не используется в Go)

При коллизии ищется следующая свободная ячейка по формуле:

// Линейное пробирование
index = (hash + i) % tableSize

// Квадратичное пробирование
index = (hash + c1*i + c2*i*i) % tableSize

// Двойное хеширование
index = (hash1 + i * hash2) % tableSize

Рост мапы

Когда load factor превышает 6.5 (среднее количество элементов на бакет), мапа растёт:

// Условие роста
overLoadFactor(count, h.B) // count > bucketCnt * 13/2 (= 6.5 * 8)

При росте:

Создаётся новый массив бакетов в 2 раза больше.
Элементы постепенно эвакуируются из старых бакетов в новые (ленивый перенос).
Это обеспечивает амортизированную O(1) стоимость вставки.

func mapassign(t *maptype, h *hmap, key unsafe.Pointer) unsafe.Pointer {
    // Если мапа растёт, эвакуируем один бакет
    if h.growing() {
        h.growWork()
    }
    // ...
}

Сравнение методов

Характеристика	Цепочки (Go)	Открытая адресация
Память	Дополнительные указатели	Меньше накладных расходов
Кэш-эффективность	Хуже (разбросано в памяти)	Лучше (непрерывно)
Удаление	Просто	Сложно (нужны tombstones)
Load factor	Может быть > 1	Должен быть < 1
Деградация	При длинных цепочках	При кластеризации

Оптимизации в Go

Tophash для быстрого сравнения:

// Сначала сравниваем 1 байт (tophash), потом полный ключ
if b.tophash[i] != top {
    continue // быстрый skip
}
if !equal(key, b.keys[i]) {
    continue // коллизия хеша, но ключи разные
}

Эвакуация при записи:

// При каждой mapassign эвакуируется 1-2 старых бакета
// Это распределяет стоимость роста на множество операций

Практические рекомендации

// 1. Предварительно аллоцируйте ёмкость
m := make(map[string]int, expectedSize)

// 2. Не используйте map в горячих циклах без предвыделения
// Частые реаллокации дороги

// 3. Ключ должен быть hashable (не slice, map, function)
type Point struct{ X, Y int } // OK — все поля hashable

// 4. Порядок итерации НЕ определён
for k, v := range m {
    // порядок будет случайным
}

// 5. Конкурентный доступ — data race!
// Используйте sync.Map или sync.RWMutex

Сложность операций

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

Худший случай наступает при большом количестве коллизий (все ключи попадают в один бакет), но хорошая хеш-функция делает это крайне маловероятным.

Вопрос 9. Какие методы открытой адресации существуют помимо линейного пробинга?

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

Ответ собеседника: Неполный. Кандидат не смог сразу назвать другие методы, но после подсказки вспомнил про двойное хеширование.

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

Метод открытой адресации — это семейство алгоритмов разрешения коллизий, где все элементы хранятся непосредственно в массиве хеш-таблицы. При коллизии ищется следующая свободная ячейка по определённой формуле.

Основные методы открытой адресации

А. Линейное пробирование (Linear Probing)

Самый простой метод — последовательный просмотр следующих ячеек:

func linearProbing(hash, i, tableSize int) int {
    return (hash + i) % tableSize
}

// Поиск позиции: hash, hash+1, hash+2, hash+3, ...

Проблема: первичная кластеризация — длинные последовательности занятых ячеек, что замедляет поиск.

Б. Квадратичное пробирование (Quadratic Probing)

Шаг увеличивается квадратично:

func quadraticProbing(hash, i, tableSize int) int {
    return (hash + c1*i + c2*i*i) % tableSize
}

// Типичные значения: c1 = 0, c2 = 1
// Поиск: hash, hash+1, hash+4, hash+9, hash+16, ...

Преимущество: уменьшает первичную кластеризацию.

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

В. Двойное хеширование (Double Hashing)

Используются две независимые хеш-функции:

func doubleHashing(hash1, hash2, i, tableSize int) int {
    return (hash1 + i*hash2) % tableSize
}

// hash1 = key % tableSize          — начальная позиция
// hash2 = 1 + (key % (tableSize-1)) — шаг (гарантированно ≠ 0)
// Поиск: hash1, hash1+hash2, hash1+2*hash2, ...

Преимущество: минимальная кластеризация, последовательность проб зависит от ключа.

Г. Кукушкиное хеширование (Cuckoo Hashing)

Используются две хеш-таблицы с двумя хеш-функциями. Каждый ключ может находиться ровно в одном из двух мест:

type CuckooHashTable struct {
    table1 []Entry
    table2 []Entry
    size   int
}

func (h *CuckooHashTable) insert(key, value int) bool {
    pos1 := h.hash1(key) % h.size
    pos2 := h.hash2(key) % h.size
    
    // Пробуем первую таблицу
    if h.table1[pos1].isEmpty() {
        h.table1[pos1] = Entry{key, value}
        return true
    }
    
    // Пробуем вторую таблицу
    if h.table2[pos2].isEmpty() {
        h.table2[pos2] = Entry{key, value}
        return true
    }
    
    // Вытесняем существующий элемент и перемещаем его
    return h.evictAndReinsert(key, value, 0, maxIterations)
}

Преимущество: поиск за гарантированный O(1) — проверяются ровно 2 позиции.

Д. Робин-худ хеширование (Robin Hood Hashing)

Элементы «обирают» богатых — вытесняют элементы, которые находятся ближе к своей «домашней» позиции:

func robinHashInsert(table []Entry, key, value, homePos int) {
    pos := homePos
    distance := 0 // расстояние от домашней позиции
    
    for !table[pos].isEmpty() {
        existingDist := probeDistance(table[pos].home, pos, tableSize)
        
        if distance > existingDist {
            // Мы «беднее» — вытесняем существующий элемент
            table[pos], key, value, distance, homePos = 
                Entry{key, value, homePos}, table[pos].key, 
                table[pos].value, existingDist, table[pos].home
        }
        
        pos = (pos + 1) % tableSize
        distance++
    }
    
    table[pos] = Entry{key, value, homePos}
}

Преимущество: минимизирует дисперсию длины проб — worst-case поиск значительно улучшается.

Сравнительная таблица

Метод	Кластеризация	Поиск (средний)	Поиск (худший)	Кэш-эффективность
Линейное	Высокая	O(1)	O(n)	Отличная
Квадратичное	Средняя	O(1)	O(n)	Хорошая
Двойное хеширование	Низкая	O(1)	O(n)	Средняя
Кукушкиное	Нет	O(1)	O(1)	Средняя
Робин-худ	Низкая	O(1)	O(log n)	Хорошая

Реализация на Go (линейное пробирование)

type Entry struct {
    Key   string
    Value int
    Used  bool
}

type HashTable struct {
    entries []Entry
    size    int
    count   int
}

func NewHashTable(size int) *HashTable {
    return &HashTable{
        entries: make([]Entry, size),
        size:    size,
    }
}

func (ht *HashTable) hash(key string) int {
    h := 0
    for _, c := range key {
        h = 31*h + int(c)
    }
    return h & 0x7FFFFFFF // положительное число
}

func (ht *HashTable) Insert(key string, value int) {
    if ht.count >= ht.size/2 {
        ht.resize()
    }
    
    idx := ht.hash(key) % ht.size
    
    for ht.entries[idx].Used {
        if ht.entries[idx].Key == key {
            ht.entries[idx].Value = value // обновление
            return
        }
        idx = (idx + 1) % ht.size // линейное пробирование
    }
    
    ht.entries[idx] = Entry{Key: key, Value: value, Used: true}
    ht.count++
}

func (ht *HashTable) Get(key string) (int, bool) {
    idx := ht.hash(key) % ht.size
    
    for ht.entries[idx].Used {
        if ht.entries[idx].Key == key {
            return ht.entries[idx].Value, true
        }
        idx = (idx + 1) % ht.size
    }
    
    return 0, false
}

func (ht *HashTable) resize() {
    oldEntries := ht.entries
    ht.entries = make([]Entry, ht.size*2)
    ht.size *= 2
    ht.count = 0
    
    for _, e := range oldEntries {
        if e.Used {
            ht.Insert(e.Key, e.Value)
        }
    }
}

Когда какой метод использовать

Линейное пробирование — простота, отличная кэш-локальность, подходит для большинства случаев.
Квадратичное — когда важно уменьшить кластеризацию, но нужна простота.
Двойное хеширование — для критичных к производительности хеш-таблиц с равномерным распределением.
Кукушкиное — когда нужен гарантированный O(1) поиск (сетевые роутеры, DPI).
Робин-худ — для систем реального времени, где важен предсказуемый worst-case.

Go использует метод цепочек, а не открытую адресацию, потому что он проще в реализации, лучше переносит высокий load factor и не требует сложной логики удаления.

Вопрос 10. Как происходит эвакуация бакетов в мапе Go и при каких операциях?

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

Ответ собеседника: Правильный. При загрузке ~6.5 начинается эвакуация — один бакет делится на два. Происходит при вставке и удалении элементов, а не параллельно через шедулер.

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

Эвакуация (eviction/рост) мапы в Go — это ленивый процесс переноса элементов из старых бакетов в новые при увеличении ёмкости хеш-таблицы.

Условие начала роста

// runtime/map.go
func overLoadFactor(count int, B uint8) bool {
    // count > bucketCnt * 13/2
    // 8 * 6.5 = 52 элемента на 8 бакетов
    return count > bucketCnt && uintptr(count) > loadFactorNum*(bucketShift(B)/loadFactorDen)
}

Load factor = 6.5 — среднее количество элементов на один бакет.

Процесс роста

Шаг 1: Выделение новых бакетов

func hashGrow(t *maptype, h *hmap) {
    // Новое количество бакетов = 2^B * 2
    newB := h.B + 1
    
    // Выделяем новый массив бакетов
    newbuckets := newarray(t.bucket, 1<<newB)
    
    // Старые бакеты сохраняем в oldbuckets
    h.oldbuckets = h.buckets
    h.buckets = newbuckets
    h.B = newB
    h.nevacuate = 0 // прогресс эвакуации
}

Шаг 2: Ленивая эвакуация

Эвакуация происходит постепенно, по одному-два бакета за операцию:

func (h *hmap) growWork() {
    // Эвакуируем один бакет
    h.growWorkOne()
    
    // Если ещё есть старые бакеты — эвакуируем ещё один
    if h.growing() {
        h.growWorkOne()
    }
}

func (h *hmap) growWorkOne() {
    // Берём бакет по индексу nevacuate
    bucket := h.nevacuate
    oldb := (*bmap)(add(h.oldbuckets, bucket*uintptr(t.bucketsize)))
    
    // Переносим элементы в новые бакеты
    evacuate(oldb, h, bucket)
    
    h.nevacuate++
}

Шаг 3: Разделение бакета

При росте один старый бакет разделяется на два новых — в зависимости от бита хеша:

Старый бакет (B=2, 4 бакета):
  Bucket 0: [k1, k3, k7, k8, ...]

Новые бакеты (B=3, 8 бакетов):
  Bucket 0: [k1, k7, ...]    — хеш & (1<<2) == 0
  Bucket 4: [k3, k8, ...]    — хеш & (1<<2) != 0

func evacuate(b *bmap, h *hmap, bucket uintptr) {
    newbit := h.noldbuckets() // 2^B (старое количество)
    
    // Два новых бакета
    x := (*bmap)(add(h.buckets, bucket*uintptr(t.bucketsize)))
    y := (*bmap)(add(h.buckets, (bucket+newbit)*uintptr(t.bucketsize)))
    
    for ; b != nil; b = b.overflow() {
        for i := 0; i < bucketCnt; i++ {
            if b.tophash[i] == empty {
                continue
            }
            
            k := add(unsafe.Pointer(b), dataOffset+i*uintptr(t.keysize))
            
            // Определяем, в какой бакет идёт элемент
            var dst *bmap
            if hash(k)&newbit == 0 {
                dst = x
            } else {
                dst = y
            }
            // Копируем элемент в новый бакет
        }
    }
}

Операции, запускающие эвакуацию

// Вставка
func mapassign(t *maptype, h *hmap, key unsafe.Pointer) unsafe.Pointer {
    if h.growing() {
        h.growWork() // эвакуация при записи
    }
    // ...
}

// Удаление
func mapdelete(t *maptype, h *hmap, key unsafe.Pointer) {
    if h.growing() {
        h.growWork() // эвакуация при удалении
    }
    // ...
}

// Итерация
func mapiternext(it *hiter) {
    if h.growing() {
        h.growWork() // эвакуация при итерации
    }
    // ...
}

Поиск во время эвакуации

func mapaccess(t *maptype, h *hmap, key unsafe.Pointer) unsafe.Pointer {
    hash := t.hasher(key, h.hash0)
    bucket := hash & ((1 << h.B) - 1)
    
    // Если мапа растёт, проверяем сначала старый бакет
    if h.growing() {
        oldbucket := bucket &^ (1 << (h.B - 1)) // маска для старого B
        b := (*bmap)(add(h.oldbuckets, oldbucket*uintptr(t.bucketsize)))
        if !evacuated(b) {
            // Бакет ещё не эвакуирован — ищем в старом
            // ...
        }
    }
    
    // Ищем в новом бакете
    b := (*bmap)(add(h.buckets, bucket*uintptr(t.bucketsize)))
    // ...
}

Почему ленивая эвакуация

Подход	Проблема
Мгновенная эвакуация	Пауза O(n) при каждом росте
Ленивая эвакуация	Стоимость распределена на множество операций

Ленивый подход обеспечивает амортизированную O(1) стоимость вставки без заметных пауз.

Пример эвакуации

func main() {
    m := make(map[int]int)
    
    // Заполняем до порога роста
    for i := 0; i < 100; i++ {
        m[i] = i
    }
    
    // В этот момент:
    // - h.B увеличился
    // - h.oldbuckets указывает на старые бакеты
    // - h.buckets указывает на новые (в 2 раза больше)
    // - h.nevacuate = 0 (эвакуация ещё не началась)
    
    // Каждая последующая операция эвакуирует 1-2 бакета
    m[101] = 101 // growWork: эвакуация бакетов 0-1
    m[102] = 102 // growWork: эвакуация бакетов 2-3
    delete(m, 1) // growWork: эвакуация бакетов 4-5
    
    // Когда nevacuate == noldbuckets, старые бакеты освобождаются
}

Ключевые выводы

Рост мапы — ленивый процесс, а не фоновая горутина.
Эвакуация происходит при вставке, удалении и итерации.
Один старый бакет делится на два новых в зависимости от бита хеша.
Поиск во время роста проверяет оба бакета (старый и новый).
Полная эвакуация завершается после ~N/2 операций (где N — количество старых бакетов).

Вопрос 11. Для чего нужен контекст в Go и что обычно в него кладут?

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

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

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

context.Context — это стандартный механизм в Go для управления жизненным циклом операций, передачи сигналов отмены и привязки значений к запросу.

Основные возможности контекста

А. Отмена операций (Cancellation)

func worker(ctx context.Context) {
    for {
        select {
        case <-ctx.Done():
            fmt.Println("Cancelled:", ctx.Err())
            return
        default:
            // полезная работа
            time.Sleep(100 * time.Millisecond)
        }
    }
}

func main() {
    ctx, cancel := context.WithCancel(context.Background())
    
    go worker(ctx)
    
    time.Sleep(300 * time.Millisecond)
    cancel() // отменяем все операции, привязанные к ctx
}

Б. Тайм-ауты и дедлайны

// Тайм-аут — относительное время
ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
defer cancel()

// Дедлайн — абсолютное время
ctx, cancel := context.WithDeadline(context.Background(), time.Now().Add(5*time.Second))
defer cancel()

// Использование
result, err := longOperation(ctx)
if err != nil {
    if errors.Is(err, context.DeadlineExceeded) {
        log.Println("Operation timed out")
    }
}

В. Передача значений (Values)

// Определяем тип ключа для типобезопасности
type contextKey string

const (
    requestIDKey contextKey = "requestID"
    userIDKey    contextKey = "userID"
    authTokenKey contextKey = "authToken"
)

// Кладём значения
ctx := context.WithValue(context.Background(), requestIDKey, "abc-123")
ctx = context.WithValue(ctx, userIDKey, 42)

// Извлекаем значения
requestID := ctx.Value(requestIDKey).(string)
userID := ctx.Value(userIDKey).(int)

Что кладут в контекст

Рекомендуемые данные:

Категория	Примеры	Зачем
Трассировка	requestID, traceID, spanID	Корреляция логов между сервисами
Аутентификация	userID, authToken, claims	Идентификация пользователя
Метрики	startTime, serviceName	Измерение времени выполнения
Флаги	dryRun, debugMode	Управление поведением

Что НЕ стоит класть в контекст:

Продуктовые сущности (заказы, пользователи, документы)
Параметры бизнес-логики
Большие структуры данных
Зависимости (логгеры, клиенты БД)

// Плохо — продуктовые данные в контексте
ctx := context.WithValue(ctx, "order", order)
processOrder(ctx)

// Хорошо — явные параметры
processOrder(ctx, order)

Паттерн использования в веб-сервисе

// Middleware для извлечения requestID
func RequestIDMiddleware(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        requestID := r.Header.Get("X-Request-ID")
        if requestID == "" {
            requestID = uuid.New().String()
        }
        
        ctx := context.WithValue(r.Context(), requestIDKey, requestID)
        next.ServeHTTP(w, r.WithContext(ctx))
    })
}

// Хендлер
func handleOrder(w http.ResponseWriter, r *http.Request) {
    ctx := r.Context()
    requestID := ctx.Value(requestIDKey).(string)
    
    // Передаём ctx вниз по стеку
    order, err := orderService.GetOrder(ctx, orderID)
    if err != nil {
        http.Error(w, err.Error(), http.StatusInternalServerError)
        return
    }
    
    json.NewEncoder(w).Encode(order)
}

// Сервисный слой
func (s *OrderService) GetOrder(ctx context.Context, id int) (*Order, error) {
    // Тайм-аут на уровне сервиса
    ctx, cancel := context.WithTimeout(ctx, 2*time.Second)
    defer cancel()
    
    // Передаём ctx в репозиторий
    return s.repo.GetByID(ctx, id)
}

// Репозиторий
func (r *OrderRepo) GetByID(ctx context.Context, id int) (*Order, error) {
    ctx, span := tracer.Start(ctx, "OrderRepo.GetByID")
    defer span.End()
    
    var order Order
    err := r.db.GetContext(ctx, &order, "SELECT * FROM orders WHERE id = $1", id)
    return &order, err
}

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

// Корневой контекст
baseCtx := context.Background()

// Добавляем общие данные
ctx := context.WithValue(baseCtx, serviceNameKey, "order-service")

// Для каждого запроса — свой контекст с тайм-аутом
reqCtx, cancel := context.WithTimeout(ctx, 10*time.Second)
defer cancel()

// Для конкретной подоперации — ещё более строгий тайм-аут
subCtx, subCancel := context.WithTimeout(reqCtx, 2*time.Second)
defer subCancel()

Распространение отмены через горутины

func processConcurrently(ctx context.Context, items []Item) error {
    ctx, cancel := context.WithCancel(ctx)
    defer cancel()
    
    errCh := make(chan error, len(items))
    
    for _, item := range items {
        go func(it Item) {
            result, err := processItem(ctx, it)
            if err != nil {
                cancel() // отменяем все остальные горутины
                errCh <- err
                return
            }
            errCh <- nil
        }(item)
    }
    
    for range items {
        if err := <-errCh; err != nil {
            return err
        }
    }
    return nil
}

Ключевые выводы

Контекст передаётся первым параметром функции (конвенция Go).
Используйте context.Background() для корневого контекста, context.TODO() когда не уверены.
Всегда вызывайте cancel() через defer — это освобождает ресурсы.
Значения в контексте — только для cross-cutting concerns (трассировка, аутентификация), не для бизнес-логики.
Контекст иммутабелен — каждая операция создаёт новый контекст, а не модифицирует существующий.

Вопрос 12. Что такое структурированное логирование и какие пакеты используются в Go?

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

Ответ собеседника: Правильный. Структурированное логирование — логи в формате JSON, которые можно маршалить/анмаршалить. Пакет zap для структурированного логирования и стандартный логер из Go 20/21.

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

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

Неструктурированное vs Структурированное

// Неструктурированное — просто текст
log.Printf("User %d ordered %s for $%.2f", userID, product, price)

// Структурированное — пары ключ-значение
logger.Info("order created",
    zap.Int("user_id", userID),
    zap.String("product", product),
    zap.Float64("price", price),
)

Вывод структурированного лога (JSON):

{
    "level": "info",
    "ts": 1699900000,
    "msg": "order created",
    "user_id": 42,
    "product": "laptop",
    "price": 999.99,
    "request_id": "abc-123"
}

Популярные пакеты для логирования в Go

А. slog — стандартная библиотека (Go 1.21+)

package main

import (
    "log/slog"
    "os"
    "time"
)

func main() {
    // Текстовый формат
    textLogger := slog.New(slog.NewTextHandler(os.Stdout, &slog.HandlerOptions{
        Level: slog.LevelDebug,
    }))
    
    // JSON формат
    jsonLogger := slog.New(slog.NewJSONHandler(os.Stdout, &slog.HandlerOptions{
        Level: slog.LevelInfo,
        ReplaceAttr: func(groups []string, a slog.Attr) slog.Attr {
            if a.Key == slog.TimeKey {
                return slog.String("timestamp", a.Value.Time().Format(time.RFC3339))
            }
            return a
        },
    }))
    
    // Логирование с атрибутами
    jsonLogger.Info("order created",
        slog.Int("user_id", 42),
        slog.String("product", "laptop"),
        slog.Float64("price", 999.99),
        slog.Group("request",
            slog.String("id", "abc-123"),
            slog.Duration("duration", 150*time.Millisecond),
        ),
    )
    
    // Логгер с предустановленными атрибутами
    requestLogger := jsonLogger.With(
        slog.String("service", "order-service"),
        slog.String("version", "1.2.3"),
    )
    requestLogger.Info("processing started")
}

Б. zap — высокопроизводительный логгер (Uber)

package main

import (
    "go.uber.org/zap"
    "go.uber.org/zap/zapcore"
)

func main() {
    // Быстрая конфигурация
    logger, _ := zap.NewProduction()
    defer logger.Sync()
    
    // Кастомная конфигурация
    config := zap.Config{
        Level:       zap.NewAtomicLevelAt(zap.InfoLevel),
        Development: false,
        Encoding:    "json",
        EncoderConfig: zapcore.EncoderConfig{
            TimeKey:        "timestamp",
            LevelKey:       "level",
            MessageKey:     "msg",
            EncodeLevel:    zapcore.LowercaseLevelEncoder,
            EncodeTime:     zapcore.ISO8601TimeEncoder,
            EncodeDuration: zapcore.MillisDurationEncoder,
        },
        OutputPaths:      []string{"stdout", "/var/log/app.log"},
        ErrorOutputPaths: []string{"stderr"},
    }
    
    logger, _ = config.Build()
    
    // SugaredLogger — удобный API (медленнее)
    sugar := logger.Sugar()
    sugar.Infow("order created",
        "user_id", 42,
        "product", "laptop",
        "price", 999.99,
    )
    
    // Logger — типизированный API (быстрее)
    logger.Info("order created",
        zap.Int("user_id", 42),
        zap.String("product", "laptop"),
        zap.Float64("price", 999.99),
    )
    
    // С контекстом
    logger.Info("request completed",
        zap.String("request_id", "abc-123"),
        zap.Duration("duration", 150*time.Millisecond),
        zap.Int("status_code", 200),
    )
}

В. zerolog — zero-allocation логгер

package main

import (
    "github.com/rs/zerolog"
    "github.com/rs/zerolog/log"
    "os"
)

func main() {
    // Глобальный логгер
    log.Logger = zerolog.New(os.Stdout).
        With().
        Timestamp().
        Str("service", "order-service").
        Logger()
    
    // Или с красивым выводом для разработки
    log.Logger = zerolog.New(zerolog.ConsoleWriter{Out: os.Stdout}).
        With().
        Timestamp().
        Logger()
    
    log.Info().
        Int("user_id", 42).
        Str("product", "laptop").
        Float64("price", 999.99).
        Msg("order created")
    
    // Цепочка вызовов
    log.Debug().
        Str("request_id", "abc-123").
        Msg("processing request")
    
    // С ошибкой
    if err != nil {
        log.Error().
            Err(err).
            Str("operation", "create_order").
            Msg("failed to create order")
    }
}

Сравнение пакетов

Характеристика	slog (stdlib)	zap	zerolog
Зависимости	0	1	1
Allocation	Среднее	Низкое	Минимальное
Производительность	Хорошая	Отличная	Отличная
Удобство	Хорошее	Среднее	Отличное
Группировка	Да	Да	Ограниченно
Context support	Да (slog.Attr)	Да (zap.Field)	Ограниченно

Интеграция с контекстом

// slog с контекстом
type contextKey string
const loggerKey contextKey = "logger"

func WithLogger(ctx context.Context, logger *slog.Logger) context.Context {
    return context.WithValue(ctx, loggerKey, logger)
}

func LoggerFrom(ctx context.Context) *slog.Logger {
    if logger, ok := ctx.Value(loggerKey).(*slog.Logger); ok {
        return logger
    }
    return slog.Default()
}

// Использование
func handleRequest(w http.ResponseWriter, r *http.Request) {
    requestID := r.Header.Get("X-Request-ID")
    
    logger := slog.Default().With(
        slog.String("request_id", requestID),
    )
    
    ctx := WithLogger(r.Context(), logger)
    processOrder(ctx, orderID)
}

func processOrder(ctx context.Context, orderID int) {
    logger := LoggerFrom(ctx)
    logger.Info("processing order", slog.Int("order_id", orderID))
}

Best practices

Используйте типизированные поля (zap.Int, slog.String) вместо строк — это быстрее и безопаснее.
Добавляйте request_id в каждый лог для трассировки.
Логируйте на границах сервисов (входящие/исходящие запросы).
Используйте уровни правильно: Debug для отладки, Info для важных событий, Error для ошибок.
Не логируйте чувствительные данные (пароли, токены, персональные данные).

// Плохо
logger.Info("user login", "password", password)

// Хорошо
logger.Info("user login", "user_id", userID, "success", true)

Структурированное логирование — основа наблюдаемости (observability) в микросервисной архитектуре, позволяя эффективно фильтровать, агрегировать и анализировать логи через системы вроде ELK, Loki, Datadog.

Вопрос 13. Для чего нужны интерфейсы в Go?

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

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

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

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

Основные применения интерфейсов

А. Развязывание слоёв приложения

// Интерфейс репозитория — абстракция над хранением
type OrderRepository interface {
    GetByID(ctx context.Context, id int) (*Order, error)
    Create(ctx context.Context, order *Order) error
    Update(ctx context.Context, order *Order) error
}

// Бизнес-логика зависит от интерфейса, а не от реализации
type OrderService struct {
    repo   OrderRepository
    logger *slog.Logger
}

func (s *OrderService) GetOrder(ctx context.Context, id int) (*Order, error) {
    return s.repo.GetByID(ctx, id)
}

// Реализация для PostgreSQL
type PostgresOrderRepo struct {
    db *sqlx.DB
}

func (r *PostgresOrderRepo) GetByID(ctx context.Context, id int) (*Order, error) {
    var order Order
    err := r.db.GetContext(ctx, &order, "SELECT * FROM orders WHERE id = $1", id)
    return &order, err
}

// Реализация для тестов
type MockOrderRepo struct {
    orders map[int]*Order
}

func (r *MockOrderRepo) GetByID(ctx context.Context, id int) (*Order, error) {
    if order, ok := r.orders[id]; ok {
        return order, nil
    }
    return nil, ErrNotFound
}

Б. Тестирование с моками

func TestOrderService_GetOrder(t *testing.T) {
    mockRepo := &MockOrderRepo{
        orders: map[int]*Order{
            1: {ID: 1, Status: "created"},
        },
    }
    
    service := &OrderService{repo: mockRepo}
    
    order, err := service.GetOrder(context.Background(), 1)
    require.NoError(t, err)
    assert.Equal(t, "created", order.Status)
}

В. Принцип инверсии зависимостей (DIP)

// Плохо — зависимость от конкретной реализации
type OrderService struct {
    repo *PostgresOrderRepo // жёсткая привязка
}

// Хорошо — зависимость от абстракции
type OrderService struct {
    repo OrderRepository // можно подменить любой реализацией
}

Г. Композиция поведения

// Мелкие интерфейсы — принцип из Go Proverbs
type Reader interface {
    Read(p []byte) (n int, err error)
}

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

// Композиция
type ReadWriter interface {
    Reader
    Writer
}

// Реализация автоматически удовлетворяет обоим
type Buffer struct {
    data []byte
}

func (b *Buffer) Read(p []byte) (int, error) { /* ... */ }
func (b *Buffer) Write(p []byte) (int, error) { /* ... */ }

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

В Go интерфейсы реализуются неявно — не нужно явно указывать implements:

type Stringer interface {
    String() string
}

type Point struct {
    X, Y int
}

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

// Любой тип с методом String() автоматически является Stringer
func printStringer(s Stringer) {
    fmt.Println(s.String())
}

printStringer(Point{1, 2}) // "(1, 2)"

Пустой интерфейс и type assertions

// interface{} (или any в Go 1.18+) — может содержать любой значение
func processValue(v interface{}) {
    switch val := v.(type) {
    case string:
        fmt.Println("string:", val)
    case int:
        fmt.Println("int:", val)
    case error:
        fmt.Println("error:", val.Error())
    default:
        fmt.Printf("unknown type: %T\n", val)
    }
}

// Type assertion — безопасное извлечение типа
func getStringLength(v interface{}) (int, error) {
    s, ok := v.(string)
    if !ok {
        return 0, fmt.Errorf("expected string, got %T", v)
    }
    return len(s), nil
}

Интерфейсы в стандартной библиотеке

// io.Reader — один из самых используемых интерфейсов
type Reader interface {
    Read(p []byte) (n int, err error)
}

// Реализации: *os.File, *bytes.Buffer, *strings.Reader, net.Conn, http.Body

// Полиморфная функция
func readAll(r io.Reader) ([]byte, error) {
    return io.ReadAll(r)
}

// Работает с любым Reader
readAll(os.Stdin)          // файл
readAll(strings.NewReader("hello")) // строка
readAll(bytes.NewBuffer(data))     // буфер

Паттерн: Accept interfaces, return structs

// Плохо — возвращаем интерфейс
func NewStorage() Storage {
    return &PostgresStorage{}
}

// Хорошо — возвращаем конкретный тип
func NewPostgresStorage() *PostgresStorage {
    return &PostgresStorage{}
}

// Но принимаем интерфейс
func NewService(storage Storage) *Service {
    return &Service{storage: storage}
}

Ключевые выводы

Интерфейсы определяют поведение, а не данные.
Утиная типизация позволяет создавать адаптеры без изменения существующего кода.
Мелкие интерфейсы (1–3 метода) предпочтительнее крупных.
Принцип: принимай интерфейсы, возвращай структуры.
Интерфейсы — основа для моков в тестах и плагинной архитектуры.

Фраза Роба Пайка из Go Proverbs: "The bigger the interface, the weaker the abstraction." — чем больше интерфейс, тем слабее абстракция.

Вопрос 14. Как реализовываны принципы ООП (инкапсуляция, абстракция, наследование, полиморфизм) в Go?

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

Ответ собеседника: Правильный. Инкапсуляция — через публичные/приватные поля и пакеты. Наследование — через композицию и встраивание структур. Полиморфизм — через интерфейсы, дженерики и switch-тайпинг. Дженерики работают как кодогенерация на этапе компиляции.

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

Go не является классическим ООП-языком, но поддерживает все четыре принципа объектно-ориентированного программирования — через свои механизмы.

А. Инкапсуляция (Encapsulation)

Инкапсуляция в Go реализуется через экспортируемость имён — первая буква определяет видимость:

package user

// User — экспортируемая структура
type User struct {
    ID        int    // экспортируемое поле — доступно извне
    Name      string // экспортируемое поле
    email     string // неэкспортируемое — доступно только внутри пакета
    createdAt time.Time // неэкспортируемое
}

// NewUser — конструктор (фабричная функция)
func NewUser(name, email string) *User {
    return &User{
        Name:      name,
        email:     email,
        createdAt: time.Now(),
    }
}

// Email — геттер для приватного поля
func (u *User) Email() string {
    return u.email
}

// SetEmail — сеттер с валидацией
func (u *User) SetEmail(email string) error {
    if !isValidEmail(email) {
        return ErrInvalidEmail
    }
    u.email = email
    return nil
}

Уровни видимости:

Область	Пример	Доступ
Пакет	`email`, `createdAt`	Только внутри пакета
Экспорт	`ID`, `Name`	Из любого пакета
Метод	`Email()`, `SetEmail()`	Контролируемый доступ

Б. Абстракция (Abstraction)

Абстракция — сокрытие сложности за интерфейсами:

// Абстракция — что делает, а не как
type PaymentProcessor interface {
    ProcessPayment(ctx context.Context, amount decimal.Decimal, currency string) (*PaymentResult, error)
    Refund(ctx context.Context, transactionID string) error
}

// Клиент работает с абстракцией
func Checkout(ctx context.Context, processor PaymentProcessor, cart *Cart) error {
    result, err := processor.ProcessPayment(ctx, cart.Total(), cart.Currency())
    if err != nil {
        return fmt.Errorf("payment failed: %w", err)
    }
    return nil
}

// Реализации скрыты
type StripeProcessor struct { apiKey string }
type PayPalProcessor struct { clientID string }

В. Наследование (Inheritance)

В Go нет классического наследования. Вместо него — композиция и встраивание (embedding):

// Встраивание — не наследование!
type Animal struct {
    Name string
    Age  int
}

func (a *Animal) Speak() string {
    return "..."
}

func (a *Animal) Info() string {
    return fmt.Sprintf("%s (%d years)", a.Name, a.Age)
}

// Dog "встраивает" Animal — получает его методы
type Dog struct {
    Animal // встраивание (embedding)
    Breed  string
}

// Переопределение метода
func (d *Dog) Speak() string {
    return "Woof!"
}

// Добавление нового метода
func (d *Dog) Fetch(item string) string {
    return fmt.Sprintf("%s fetches %s!", d.Name, item)
}

func main() {
    dog := Dog{
        Animal: Animal{Name: "Rex", Age: 3},
        Breed:  "Labrador",
    }
    
    fmt.Println(dog.Speak())  // "Woof!" — переопределённый метод
    fmt.Println(dog.Info())   // "Rex (3 years)" — унаследованный метод
    fmt.Println(dog.Fetch("ball")) // "Rex fetches ball!" — новый метод
}

Композиция предпочтительнее встраивания:

// Плохо — встраивание раскрывает все методы
type UserService struct {
    *sql.DB // все методы DB доступны — нарушение инкапсуляции
}

// Хорошо — композиция с явным интерфейсом
type UserService struct {
    db Database // только нужные методы
}

type Database interface {
    QueryContext(ctx context.Context, query string, args ...interface{}) (*sql.Rows, error)
    ExecContext(ctx context.Context, query string, args ...interface{}) (sql.Result, error)
}

Г. Полиморфизм (Polymorphism)

Полиморфизм в Go реализуется через интерфейсы, дженерики и type switches:

// 1. Полиморфизм через интерфейсы
type Shape interface {
    Area() float64
    Perimeter() float64
}

type Circle struct{ Radius float64 }
type Rectangle struct{ Width, Height float64 }

func (c Circle) Area() float64      { return math.Pi * c.Radius * c.Radius }
func (c Circle) Perimeter() float64 { return 2 * math.Pi * c.Radius }

func (r Rectangle) Area() float64      { return r.Width * r.Height }
func (r Rectangle) Perimeter() float64 { return 2 * (r.Width + r.Height) }

// Полиморфная функция
func PrintShapeInfo(s Shape) {
    fmt.Printf("Area: %.2f, Perimeter: %.2f\n", s.Area(), s.Perimeter())
}

PrintShapeInfo(Circle{Radius: 5})
PrintShapeInfo(Rectangle{Width: 3, Height: 4})

// 2. Полиморфизм через дженерики (Go 1.18+)
type Number interface {
    ~int | ~int64 | ~float64
}

func Min[T Number](a, b T) T {
    if a < b {
        return a
    }
    return b
}

func Sum[T Number](values []T) T {
    var sum T
    for _, v := range values {
        sum += v
    }
    return sum
}

Min(3, 5)           // int
Min(3.14, 2.71)     // float64
Sum([]int{1, 2, 3}) // 6

// 3. Полиморфизм через type switch
func Describe(v interface{}) string {
    switch val := v.(type) {
    case string:
        return fmt.Sprintf("string of length %d", len(val))
    case int:
        return fmt.Sprintf("integer: %d", val)
    case Shape:
        return fmt.Sprintf("shape with area %.2f", val.Area())
    case fmt.Stringer:
        return val.String()
    default:
        return fmt.Sprintf("unknown type: %T", v)
    }
}

Дженерики: реализация

Дженерики в Go реализованы через мономорфизацию (code specialization) — компилятор генерирует отдельную версию функции для каждого конкретного типа:

// Исходный код
func Map[T, U any](slice []T, fn func(T) U) []U {
    result := make([]U, len(slice))
    for i, v := range slice {
        result[i] = fn(v)
    }
    return result
}

// Компилятор генерирует:
// func Map_int_string(slice []int, fn func(int) string) []string { ... }
// func Map_string_int(slice []string, fn func(string) int) []int { ... }

Сравнение с классическим ООП

Принцип	Классическое ООП	Go
Инкапсуляция	`private`/`protected`/`public`	Экспортируемость имён
Абстракция	Абстрактные классы	Интерфейсы
Наследование	`extends`	Композиция + embedding
Полиморфизм	Переопределение методов	Интерфейсы + дженерики

Ключевые выводы

Go предпочитает композицию наследованию — это более гибкий подход.
Интерфейсы реализуются неявно — нет необходимости в implements.
Дженерики добавлены в Go 1.18 для типобезопасного переиспользования кода.
Принцип: "Favor composition over inheritance" — из книги "Design Patterns" (GoF).

Вопрос 15. Почему в Go до версии 1.22 переменная в цикле for переиспользовалась на каждой итерации?

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

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

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

До Go 1.22 переменная цикла в for и for-range создавалась один раз и переиспользовалась на каждой итерации. Это было сделано из соображений производительности, но приводило к неочевидным багам.

Проблема до Go 1.22

// Go 1.21 и ранее
func main() {
    var funcs []func()
    
    for i := 0; i < 3; i++ {
        funcs = append(funcs, func() {
            fmt.Println(i) // замыкание захватывает переменную i, а не её значение
        })
    }
    
    for _, f := range funcs {
        f() // выводит 3, 3, 3 (а не 0, 1, 2)
    }
}

Почему так происходило:

Переменная i создавалась один раз в стеке. Все замыкания захватывали ссылку на ту же переменную. К моменту вызова функций цикл завершился, и i == 3.

Ещё один пример с range:

// Go 1.21 и ранее
func main() {
    items := []int{10, 20, 30}
    var refs []*int
    
    for _, v := range items {
        refs = append(refs, &v) // все указатели на одну переменную!
    }
    
    for _, r := range refs {
        fmt.Println(*r) // выводит 30, 30, 30
    }
}

Решение до Go 1.22:

// Явное создание локальной копии
for _, v := range items {
    v := v // shadowing — создаём новую переменную в каждой итерации
    refs = append(refs, &v)
}

// Или передача в функцию
for _, v := range items {
    func(val int) {
        refs = append(refs, &val)
    }(v)
}

Что изменилось в Go 1.22

Начиная с Go 1.22 (февраль 2024), переменные цикла создаются заново на каждой итерации:

// Go 1.22+
func main() {
    var funcs []func()
    
    for i := 0; i < 3; i++ {
        funcs = append(funcs, func() {
            fmt.Println(i) // каждое замыкание захватывает свою копию
        })
    }
    
    for _, f := range funcs {
        f() // выводит 0, 1, 2 — как ожидается
    }
}

Механизм реализации

Компилятор Go 1.22 генерирует код, эквивалентный:

// Что делает компилятор (упрощённо)
for {
    i := i // новая переменная на каждой итерации
    if i >= 3 {
        break
    }
    // тело цикла
    i++
}

Влияние на производительность

Новая семантика требует дополнительной аллокации на каждой итерации:

// Бенчмарк (иллюстративный)
func BenchmarkLoopOld(b *testing.B) {
    for i := 0; i < b.N; i++ {
        _ = i // одна переменная
    }
}

func BenchmarkLoopNew(b *testing.B) {
    for i := 0; i < b.N; i++ {
        i := i // новая переменная на каждой итерации
        _ = i
    }
}

В большинстве случаев разница незначительна — компилятор оптимизирует простые случаи. Накладные расходы заметны только в очень горячих циклах с миллиардами итераций.

Как включить новое поведение в старых версиях

В go.mod можно указать версию языка:

// go.mod
module example.com/myapp

go 1.22 // включает новую семантику циклов

// Или для постепенного перехода:
go 1.21 // старая семантика

Обратная совместимость

Для проектов, которые полагаются на старое поведение, есть переменная окружения:

GOEXPERIMENT=loopvar go run main.go

Ключевые выводы

До Go 1.22 переменная цикла переиспользовалась — это было частым источником багов.
Go 1.22 создаёт новую переменную на каждой итерации — поведение стало интуитивным.
Для замыканий в циклах теперь не нужен трюк v := v.
Незначительное влияние на производительность в большинстве случаев.
Изменение контролируется через go.mod — можно мигрировать постепенно.

Вопрос 16. Что выведет программа с горутинами и циклом for без синхронизации?

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

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

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

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

Проблема 1: Завершение главной горутины

func main() {
    for i := 0; i < 5; i++ {
        go func() {
            fmt.Println(i)
        }()
    }
    
    // main завершается сразу — горутины не успевают выполниться
    fmt.Println("done")
}

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

Решение с WaitGroup:

func main() {
    var wg sync.WaitGroup
    
    for i := 0; i < 5; i++ {
        wg.Add(1)
        go func() {
            defer wg.Done()
            fmt.Println(i)
        }()
    }
    
    wg.Wait() // ждём завершения всех горутин
    fmt.Println("done")
}

Проблема 2: Захват переменной цикла (до Go 1.22)

func main() {
    var wg sync.WaitGroup
    
    for i := 0; i < 5; i++ {
        wg.Add(1)
        go func() {
            defer wg.Done()
            fmt.Println(i) // замыкание захватывает переменную i
        }()
    }
    
    wg.Wait()
}

Вывод (Go 1.21 и ранее): 5 5 5 5 5 — все горутины видят финальное значение i.

Почему: Замыкание захватывает ссылку на переменную i, а не её значение. К моменту выполнения горутин цикл завершился, и i == 5.

Решения:

// Вариант 1: Передача как параметр
for i := 0; i < 5; i++ {
    wg.Add(1)
    go func(val int) {
        defer wg.Done()
        fmt.Println(val) // каждый вызов получает свою копию
    }(i)
}

// Вариант 2: Локальная переменная (до Go 1.22)
for i := 0; i < 5; i++ {
    i := i // shadowing — новая переменная в каждой итерации
    wg.Add(1)
    go func() {
        defer wg.Done()
        fmt.Println(i) // захватывает локальную копию
    }()
}

// Вариант 3: Go 1.22+ — работает из коробки
for i := 0; i < 5; i++ {
    wg.Add(1)
    go func() {
        defer wg.Done()
        fmt.Println(i) // каждая итерация создаёт новую переменную
    }()
}

Проблема 3: Data Race

func main() {
    counter := 0
    var wg sync.WaitGroup
    
    for i := 0; i < 1000; i++ {
        wg.Add(1)
        go func() {
            defer wg.Done()
            counter++ // DATA RACE!
        }()
    }
    
    wg.Wait()
    fmt.Println(counter) // непредсказуемое значение < 1000
}

Решение с мьютексом:

func main() {
    counter := 0
    var wg sync.WaitGroup
    var mu sync.Mutex
    
    for i := 0; i < 1000; i++ {
        wg.Add(1)
        go func() {
            defer wg.Done()
            mu.Lock()
            counter++
            mu.Unlock()
        }()
    }
    
    wg.Wait()
    fmt.Println(counter) // 1000
}

Решение с атомарными операциями:

func main() {
    var counter atomic.Int64
    var wg sync.WaitGroup
    
    for i := 0; i < 1000; i++ {
        wg.Add(1)
        go func() {
            defer wg.Done()
            counter.Add(1)
        }()
    }
    
    wg.Wait()
    fmt.Println(counter.Load()) // 1000
}

Полный корректный пример:

func main() {
    var wg sync.WaitGroup
    
    for i := 0; i < 5; i++ {
        wg.Add(1)
        go func(val int) {
            defer wg.Done()
            fmt.Printf("goroutine %d started\n", val)
            time.Sleep(time.Duration(rand.Intn(100)) * time.Millisecond)
            fmt.Printf("goroutine %d done\n", val)
        }(i)
    }
    
    wg.Wait()
    fmt.Println("all goroutines completed")
}

Ключевые выводы

Главная горутина не ждёт завершения дочерних — используйте sync.WaitGroup или каналы.
Замыкания захватывают переменные по ссылке — передавайте значения как параметры.
Конкурентный доступ к общим данным — data race — используйте sync.Mutex или atomic.
Go 1.22+ решает проблему захвата переменной цикла, но не проблему синхронизации.
Запускайте тесты с флагом -race для обнаружения гонок: go test -race ./...

Вопрос 17. Как устроена модель GMP в Go и зачем горутины вместо системных потоков?

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

Ответ собеседника: Правильный. Модель GMP: Machine (процессоры), P (логические процессоры с очередями), G (горутины). Горутины легковеснее трейдов: не требуют системных вызовов, можно запускать тысячи.

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

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

Компоненты модели GMP

G (Goroutine)

Горутина — легковесная нить выполнения, управляемая runtime Go, а не ОС.

type g struct {
    stack       stack   // стек [lo, hi]
    stackguard0 uintptr // граница стека для проверки переполнения
    m           *m      // текущий M, на котором выполняется
    
    sched       gobuf   // контекст для переключения
    status      uint32  // состояние: _Gidle, _Grunning, _Gwaiting, ...
    waitreason  uint8   // причина ожидания
    
    // ...
}

Характеристики горутины:

Параметр	Горутина	Системный поток
Размер стека	2–8 КБ (начальный)	1–8 МБ (фиксированный)
Создание	~200 нс	~10–100 мкс
Переключение контекста	~200 нс	~1–10 мкс
Максимум	Миллионы	Тысячи

M (Machine / OS Thread)

M — системный поток ОС, на котором выполняются горутины.

type m struct {
    g0      *g    // специальная горутина для планировщика
    curg    *g    // текущая выполняемая горутина
    p       puintptr // привязанный P
    nextp   puintptr // следующий P для привязки
    
    spinning bool // ищет ли работу
    blocked  bool // заблокирован на syscall
}

Характеристики M:

Количество ограничено GOMAXPROCS (по умолчанию = числу CPU).
M может быть заблокирован на syscall — тогда P отвязывается и переходит к другому M.
При необходимости создаются новые M (до предела в 10000).

P (Processor / Logical Processor)

P — логический процессор, владеет локальной очередью горутин.

type p struct {
    id          int32
    status      uint32  // _Pidle, _Prunning, _Psyscall, ...
    m           muintptr // привязанный M
    
    runqhead uint32     // голова локальной очереди
    runqtail uint32     // хвост локальной очереди
    runq     [256]guintptr // локальная очередь (256 горутин)
    
    runnext guintptr // следующая горутина для выполнения (приоритет)
    
    mcache   *mcache   // локальный кэш памяти
    pcache   pageCache // локальный кэш страниц
}

Характеристики P:

Количество = GOMAXPROCS (по умолчанию = числу CPU).
Каждый P имеет локальную очередь из 256 горутин.
P привязан к одному M в каждый момент времени.

Схема взаимодействия

┌─────────────────────────────────────────────────────────┐
│                    Global Run Queue                      │
│  [G1] [G2] [G3] [G4] [G5] [G6] [G7] [G8]              │
└─────────────────────────────────────────────────────────┘
                          ▲
          ┌───────────────┼───────────────┐
          │               │               │
    ┌─────┴─────┐   ┌─────┴─────┐   ┌─────┴─────┐
    │    P0     │   │    P1     │   │    P2     │
    │ M0 ←──────┤   │ M1 ←──────┤   │ M2 ←──────┤
    │ [G][G][G] │   │ [G][G][G] │   │ [G][G][G] │
    │ runnext:G │   │ runnext:G │   │ runnext:G │
    └───────────┘   └───────────┘   └───────────┘
          │               │               │
    ┌─────┴─────┐   ┌─────┴─────┐   ┌─────┴─────┐
    │   CPU 0   │   │   CPU 1   │   │   CPU 2   │
    └───────────┘   └───────────┘   └───────────┘

Алгоритм работы планировщика

Шаг 1: Выбор горутины для выполнения

// Упрощённая логика schedule()
func schedule() {
    _g_ := getg() // текущая горутина
    
    // 1. Проверяем runnext (приоритетная горутина)
    if gp := runqget(_g_.m.p.ptr()); gp != nil {
        return gp
    }
    
    // 2. Проверяем локальную очередь
    if gp := runqget(_g_.m.p.ptr()); gp != nil {
        return gp
    }
    
    // 3. Проверяем глобальную очередь (каждые 61 итерацию)
    if gp := globrunqget(_g_.m.p.ptr(), 0); gp != nil {
        return gp
    }
    
    // 4. Work stealing — воруем у других P
    if gp := findrunnable(); gp != nil {
        return gp
    }
    
    // 5. Ничего не нашли — паркуем M
    stopm()
}

Шаг 2: Work Stealing

Когда у P нет горутин, он «ворует» работу у других P:

func stealWork(p2 *p) *g {
    // Случайно выбираем жертву
    for i := 0; i < 4; i++ {
        p2 := allp[fastrand()%uint32(gomaxprocs)]
        
        // Берём половину горутин из очереди жертвы
        n := runqsteal(p, p2, true)
        if n > 0 {
            return gp
        }
    }
    return nil
}

Шаг 3: Переключение контекста

func mcall(fn func(*g)) {
    // Сохраняем контекст текущей горутины
    // Переключаемся на g0 (стек планировщика)
    // Вызываем fn
}

func gostartcallfn(gobuf *gobuf, fn *funcval) {
    // Восстанавливаем контекст новой горутины
    // Прыгаем на её стек
}

Состояния горутины

_Gidle → _Grunnable → _Grunning → _Gwaiting → _Grunnable
                         ↓
                     _Gdead

Состояние	Описание
`_Gidle`	Создана, но не инициализирована
`_Grunnable`	В очереди, ожидает выполнения
`_Grunning`	Выполняется на M
`_Gwaiting`	Заблокирована (канал, мьютекс, syscall)
`_Gdead`	Завершена
`_Gcopystack`	Стек растёт

Пример: что происходит при блокировке

func worker() {
    // Горутина выполняется на M через P
    
    data := make(chan int)
    <-data // блокировка на канале
    
    // 1. G переходит в _Gwaiting
    // 2. M продолжает выполнять другие G из P
    // 3. G остаётся в очереди ожидания канала
}

func main() {
    go worker()
    
    // Если M блокируется на syscall:
    // 1. P отвязывается от M
    // 2. Создаётся новый M (или берётся из пула)
    // 3. P привязывается к новому M
    // 4. Заблокированный M ждёт завершения syscall
}

Настройка GOMAXPROCS

func main() {
    // По умолчанию = runtime.NumCPU()
    runtime.GOMAXPROCS(4) // явно задаём
    
    // Для CPU-bound задач: GOMAXPROCS = NumCPU
    // Для I/O-bound задач: можно увеличить
}

Практические следствия

// Горутина с бесконечным циклом может заблокировать P
func cpuIntensive() {
    for {
        // без точек переключения — голодие других горутин
    }
}

// Решение: добавляем точки переключения
func cpuIntensive() {
    for {
        runtime.Gosched() // явная передача управления
        // или вызов любой функции (не inline)
    }
}

// Или используем GOMAXPROCS > 1

Ключевые выводы

G — горутина: легковесная, 2 КБ стека, создаётся за ~200 нс.
M — системный поток: ограничен GOMAXPROCS, может блокироваться на syscall.
P — логический процессор: владеет локальной очередью из 256 горутин.
Work stealing — балансировка нагрузки между P.
M:N модель — M горутин на N системных потоков.
Планировщик Go — кооперативный с вытеснением на точках безопасности (function calls, channel operations).

Вопрос 18. Какие проблемы в коде с горутинами и общим ресурсом, как решить?

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

Ответ собеседника: Правильный. Две проблемы: 1) нет синхронизации (нужен WaitGroup); 2) состояние гонки при обращении к общему ресурсу. Решение — atomic или mutex.

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

Конкурентный доступ к общим ресурсам — одна из самых частых источников багов. Рассмотрим основные проблемы и способы их решения.

Проблема 1: Data Race (Состояние гонки)

// Проблема
func main() {
    counter := 0
    var wg sync.WaitGroup
    
    for i := 0; i < 1000; i++ {
        wg.Add(1)
        go func() {
            defer wg.Done()
            counter++ // DATA RACE: read-modify-write не атомарна
        }()
    }
    
    wg.Wait()
    fmt.Println(counter) // непредсказуемое значение < 1000
}

Почему это проблема:

counter++ — это три операции: чтение, инкремент, запись. Между ними может вклиниться другая горутина.

Горутина A: читает counter = 5
Горутина B: читает counter = 5
Горутина A: записывает counter = 6
Горутина B: записывает counter = 6 // потерянный инкремент!

Решение 1: sync.Mutex

func main() {
    counter := 0
    var wg sync.WaitGroup
    var mu sync.Mutex
    
    for i := 0; i < 1000; i++ {
        wg.Add(1)
        go func() {
            defer wg.Done()
            mu.Lock()
            counter++
            mu.Unlock()
        }()
    }
    
    wg.Wait()
    fmt.Println(counter) // 1000
}

Решение 2: atomic

func main() {
    var counter atomic.Int64
    var wg sync.WaitGroup
    
    for i := 0; i < 1000; i++ {
        wg.Add(1)
        go func() {
            defer wg.Done()
            counter.Add(1) // атомарная операция
        }()
    }
    
    wg.Wait()
    fmt.Println(counter.Load()) // 1000
}

Решение 3: sync/atomic для старых версий Go

var counter int64

atomic.AddInt64(&counter, 1)
atomic.LoadInt64(&counter)
atomic.StoreInt64(&counter, 42)
atomic.CompareAndSwapInt64(&counter, 42, 43) // CAS

Проблема 2: Захват переменной цикла

// Проблема (до Go 1.22)
func main() {
    var wg sync.WaitGroup
    
    for i := 0; i < 5; i++ {
        wg.Add(1)
        go func() {
            defer wg.Done()
            fmt.Println(i) // замыкание захватывает переменную i
        }()
    }
    
    wg.Wait()
    // Вывод: 5 5 5 5 5 (или другое непредсказуемое)
}

Решения:

// Вариант 1: Параметр функции
for i := 0; i < 5; i++ {
    wg.Add(1)
    go func(val int) {
        defer wg.Done()
        fmt.Println(val)
    }(i)
}

// Вариант 2: Локальная переменная
for i := 0; i < 5; i++ {
    i := i // shadowing
    wg.Add(1)
    go func() {
        defer wg.Done()
        fmt.Println(i)
    }()
}

Проблема 3: Утечка горутин (Goroutine Leak)

// Проблема: горутина никогда не завершится
func process(ch chan int) {
    for val := range ch {
        fmt.Println(val)
    }
}

func main() {
    ch := make(chan int)
    go process(ch)
    
    ch <- 1
    ch <- 2
    // ch не закрыт — горутина process зависнет навсегда
}

Решения:

// Вариант 1: Закрытие канала
close(ch) // process завершится после обработки всех значений

// Вариант 2: Использование контекста
func process(ctx context.Context, ch chan int) {
    for {
        select {
        case val, ok := <-ch:
            if !ok {
                return // канал закрыт
            }
            fmt.Println(val)
        case <-ctx.Done():
            return // контекст отменён
        }
    }
}

// Вариант 3: done-канал
func process(ch chan int, done chan struct{}) {
    for {
        select {
        case val := <-ch:
            fmt.Println(val)
        case <-done:
            return
        }
    }
}

Проблема 4: Голодание (Starvation)

// Проблема: одна горутина монополизирует ресурс
func greedyWorker(mu *sync.Mutex) {
    for {
        mu.Lock()
        // долгая работа без разблокировки
        time.Sleep(time.Second)
        mu.Unlock()
    }
}

func starvingWorker(mu *sync.Mutex) {
    for {
        mu.Lock() // может ждать очень долго
        // короткая работа
        mu.Unlock()
    }
}

Решение: RWMutex для читателей-писателей

func main() {
    var mu sync.RWMutex
    data := make(map[string]string)
    
    // Множество читателей
    for i := 0; i < 100; i++ {
        go func() {
            for {
                mu.RLock()
                _ = data["key"]
                mu.RUnlock()
            }
        }()
    }
    
    // Редкий писатель
    go func() {
        for {
            mu.Lock()
            data["key"] = "value"
            mu.Unlock()
        }
    }()
}

Проблема 5: Deadlock (Взаимная блокировка)

// Проблема: deadlock
func main() {
    mu1 := sync.Mutex{}
    mu2 := sync.Mutex{}
    
    go func() {
        mu1.Lock()
        time.Sleep(10 * time.Millisecond)
        mu2.Lock() // ждёт, пока горутина 2 отпустит mu2
        mu2.Unlock()
        mu1.Unlock()
    }()
    
    go func() {
        mu2.Lock()
        time.Sleep(10 * time.Millisecond)
        mu1.Lock() // ждёт, пока горутина 1 отпустит mu1
        mu1.Unlock()
        mu2.Unlock()
    }()
    
    time.Sleep(time.Second)
    fmt.Println("deadlock!")
}

Решение: порядок блокировки

// Всегда блокируйте мьютексы в одном порядке
func safeWorker(mu1, mu2 *sync.Mutex) {
    first, second := mu1, mu2
    if uintptr(unsafe.Pointer(mu1)) > uintptr(unsafe.Pointer(mu2)) {
        first, second = mu2, mu1
    }
    
    first.Lock()
    second.Lock()
    // работа
    second.Unlock()
    first.Unlock()
}

Общий паттерн: безопасный конкурентный счётчик

type SafeCounter struct {
    mu    sync.RWMutex
    count map[string]int
}

func NewSafeCounter() *SafeCounter {
    return &SafeCounter{
        count: make(map[string]int),
    }
}

func (c *SafeCounter) Inc(key string) {
    c.mu.Lock()
    defer c.mu.Unlock()
    c.count[key]++
}

func (c *SafeCounter) Get(key string) int {
    c.mu.RLock()
    defer c.mu.RUnlock()
    return c.count[key]
}

func (c *SafeCounter) GetAll() map[string]int {
    c.mu.RLock()
    defer c.mu.RUnlock()
    
    // Возвращаем копию, чтобы избежать race при чтении
    result := make(map[string]int, len(c.count))
    for k, v := range c.count {
        result[k] = v
    }
    return result
}

Обнаружение гонок

# Компиляция с детектором гонок
go build -race .

# Тесты с детектором гонок
go test -race ./...

# Запуск с детектором гонок
go run -race main.go

// Пример вывода детектора гонок
/*
WARNING: DATA RACE
Write at 0x00c000122000 by goroutine 7:
  main.main.func1()
      /tmp/main.go:15 +0x3a

Previous read at 0x00c000122000 by goroutine 8:
  main.main.func1()
      /tmp/main.go:15 +0x2b

Goroutine 7 (running) created at:
  main.main()
      /tmp/main.go:14 +0x88

Goroutine 8 (running) created at:
  main.main()
      /tmp/main.go:14 +0x88
*/

Сравнение примитивов синхронизации

Примитив	Когда использовать	Производительность
`sync.Mutex`	Исключительный доступ к данным	Средняя
`sync.RWMutex`	Много читателей, мало писателей	Выше при преобладании чтения
`atomic`	Простые операции (счётчики, флаги)	Максимальная
`sync.Once`	Однократная инициализация	Однократные накладные расходы
`sync.WaitGroup`	Ожидание завершения группы горутин	Минимальная
`sync.Cond`	Сложные условия ожидания	Средняя
`chan`	Передаданных между горутинами	Средняя

Ключевые выводы

Data race — конкурентный доступ к данным без синхронизации.
Mutex — для сложных структур данных, atomic — для простых операций.
Goroutine leak — всегда предусматривайте механизм завершения горутин.
Deadlock — соблюдайте порядок блокировки мьютексов.
Race detector (-race) — обязательный инструмент при разработке конкурентного кода.

Вопрос 19. В чём разница между atomic и mutex, как работает CompareAndSwap?

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

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

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

atomic и mutex — два разных подхода к синхронизации, основанные на разных механизмах.

Atomic: Lock-Free операции

Атомарные операции реализуются через процессорные инструкции без блокировок:

// x86-64: LOCK XADD, LOCK CMPXCHG
// ARM: LDXR/STXR, CAS

var counter atomic.Int64

// Атомарный инкремент — одна инструкция процессора
counter.Add(1)

// Атомарное чтение
value := counter.Load()

// Атомарная запись
counter.Store(42)

Mutex: Блокирующая синхронизация

Мьютекс использует блокировку потока — горутина засыпает и ожидает разблокировки:

var mu sync.Mutex
counter := 0

mu.Lock()
counter++ // критическая секция
mu.Unlock()

CompareAndSwap (CAS) — фундамент атомарных операций

// Семантика CAS (псевдокод)
func CompareAndSwap(addr *int64, old, new int64) bool {
    if *addr == old {
        *addr = new
        return true // успешно
    }
    return false // значение изменилось другой горутиной
}

На уровне процессора (x86-64):

; LOCK CMPXCHG [addr], new_value
; Сравнивает [addr] с EAX, если равно — записывает new_value

Реализация CAS в Go:

var value atomic.Int64

func incrementIf(expected int64) bool {
    // Пытаемся заменить expected на expected+1
    return value.CompareAndSwap(expected, expected+1)
}

// Использование в цикле (CAS loop)
func atomicIncrement() {
    for {
        old := value.Load()
        new := old + 1
        if value.CompareAndSwap(old, new) {
            return // успех
        }
        // CAS не удался — другая горутина изменила значение
        // Повторяем попытку
    }
}

Пример: Lock-Free стек на CAS

type Node struct {
    Value int
    Next  *Node
}

type LockFreeStack struct {
    head atomic.Pointer[Node]
}

func NewLockFreeStack() *LockFreeStack {
    return &LockFreeStack{}
}

func (s *LockFreeStack) Push(value int) {
    newNode := &Node{Value: value}
    
    for {
        oldHead := s.head.Load()
        newNode.Next = oldHead
        
        if s.head.CompareAndSwap(oldHead, newNode) {
            return // успех
        }
        // CAS не удался — другой поток изменил head
    }
}

func (s *LockFreeStack) Pop() (*Node, bool) {
    for {
        oldHead := s.head.Load()
        if oldHead == nil {
            return nil, false // стек пуст
        }
        
        newHead := oldHead.Next
        if s.head.CompareAndSwap(oldHead, newHead) {
            return oldHead, true // успех
        }
    }
}

Проблема ABA

CAS уязвим к проблеме ABA:

Горутина A читает head = A
Горутина B: Pop A, Pop B, Push A → head = A
Горутина A: CAS(A, new) — успешен, но структура изменилась!

Решение: Tagged pointers

type TaggedPointer struct {
    Pointer unsafe.Pointer
    Tag     uint64 // счётчик модификаций
}

type SafeLockFreeStack struct {
    head atomic.Uint64 // упакованный TaggedPointer
}

func (s *SafeLockFreeStack) Push(value int) {
    newNode := &Node{Value: value}
    
    for {
        oldPack := s.head.Load()
        oldPtr, oldTag := unpack(oldPack)
        newNode.Next = (*Node)(oldPtr)
        
        newPack := pack(unsafe.Pointer(newNode), oldTag+1)
        if s.head.CompareAndSwap(oldPack, newPack) {
            return
        }
    }
}

Сравнение atomic и mutex

Характеристика	Atomic	Mutex
Механизм	Процессорные инструкции	Блокировка горутины
Блокировка	Нет (lock-free)	Да
Конкуренция	Spin-retry (busy wait)	Парковка горутины
Сложность	Только простые операции	Любые операции
Производительность	Выше при низкой конкуренции	Выше при высокой конкуренции
Риск	ABA-проблем	Deadlock, голодание

Когда что использовать

// Atomic — для простых счётчиков и флагов
var requestCount atomic.Int64
var isReady atomic.Bool

requestCount.Add(1)
isReady.Store(true)

// Mutex — для сложных структур данных
type Cache struct {
    mu    sync.RWMutex
    items map[string]*Item
}

func (c *Cache) Get(key string) (*Item, bool) {
    c.mu.RLock()
    defer c.mu.RUnlock()
    item, ok := c.items[key]
    return item, ok
}

func (c *Cache) Set(key string, item *Item) {
    c.mu.Lock()
    defer c.mu.Unlock()
    c.items[key] = item
}

Бенчмарк: atomic vs mutex

func BenchmarkAtomicAdd(b *testing.B) {
    var counter atomic.Int64
    b.RunParallel(func(pb *testing.PB) {
        for pb.Next() {
            counter.Add(1)
        }
    })
}

func BenchmarkMutexAdd(b *testing.B) {
    var counter int64
    var mu sync.Mutex
    b.RunParallel(func(pb *testing.PB) {
        for pb.Next() {
            mu.Lock()
            counter++
            mu.Unlock()
        }
    })
}

Типичные результаты:

BenchmarkAtomicAdd-8    100000000    10.2 ns/op
BenchmarkMutexAdd-8      50000000    28.5 ns/op

Atomic быстрее в ~2–3 раза при простых операциях.

Ключевые выводы

Atomic — lock-free операции через процессорные инструкции, идеальны для счётчиков и флагов.
Mutex — блокирующая синхронизация, подходит для сложных критических секций.
CAS — фундаментальная операция: сравнивает и заменяет значение атомарно.
CAS loop — паттерн для реализации lock-free структур данных.
ABA-проблема — классическая ловушка CAS, решается tagged pointers.
При низкой конкуренции atomic значительно быстрее; при высокой — разница уменьшается из-за spin-retries.

Вопрос 20. Будет ли влиять исчерпание файловых дескрипторов на горутины?

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

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

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

Файловые дескрипторы (FD) — это ресурс операционной системы, и их исчерпание напрямую влияет на работу горутин, выполняющих I/O операции.

Что такое файловые дескрипторы

Файловый дескриптор — неотрицательное целое число, идентифицирующее открытый ресурс в ядре ОС:

Тип ресурса	Пример
Файл	`os.Open("file.txt")`
Сокет	`net.Dial("tcp", "host:port")`
Канал (pipe)	`os.Pipe()`
epoll/kqueue	`runtime` использует для netpoller
Timerfd	`runtime` использует для таймеров

Лимиты в Linux

# Системный лимит
cat /proc/sys/fs/file-max
# 1000000

# Пользовательский лимит
ulimit -n
# 1024 (по умолчанию)

# Лимит для процесса
cat /proc/<pid>/limits | grep "open files"
# Max open files  1024  4096  files

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

func main() {
    var conns []net.Conn
    
    for i := 0; i < 10000; i++ {
        conn, err := net.Dial("tcp", "localhost:8080")
        if err != nil {
            // Ошибка: socket: too many open files
            fmt.Printf("Failed at connection %d: %v\n", i, err)
            break
        }
        conns = append(conns, conn)
    }
}

Ошибки при исчерпании FD:

socket: too many open files
accept: too many open files
open /path/to/file: too many open files

Влияние на горутины

А. Блокировка M на syscall

Когда горутина выполняет блокирующий syscall (например, accept, read, connect), M (системный поток) блокируется:

func handleConnection(conn net.Conn) {
    buf := make([]byte, 1024)
    n, err := conn.Read(buf) // блокирующий syscall read()
    // M блокируется до появления данных
}

Б. Отвязка P от M

Если M заблокирован на syscall, P отвязывается и привязывается к другому M:

До syscall:
  P0 → M0 (заблокирован на read)
  
После отвязки:
  P0 → M1 (новый или из пула)
  M0 → заблокирован, ждёт завершения syscall

В. Создание новых M

Если все M заблокированы, runtime создаёт новые (до лимита в 10000):

// runtime/proc.go
func lockOSThread() {
    // ...
}

// Лимит на количество M
var maxmcount int32 = 10000

Практические последствия

1. HTTP-сервер перестаёт принимать соединения:

func main() {
    http.HandleFunc("/", handler)
    log.Fatal(http.ListenAndServe(":8080", nil))
}

func handler(w http.ResponseWriter, r *http.Request) {
    // Медленная обработка без тайм-аута
    time.Sleep(30 * time.Second)
    w.Write([]byte("OK"))
}

// При 1000 одновременных запросах и лимите FD=1024:
// - первые ~1000 запросов принимаются
// - остальные получают ошибку "too many open files"

2. Утечка соединений:

// Плохо — соединение не закрывается
func badHandler(w http.ResponseWriter, r *http.Request) {
    resp, err := http.Get("http://backend/api")
    if err != nil {
        http.Error(w, err.Error(), 500)
        return
    }
    // resp.Body не закрыт — утечка FD!
    io.Copy(w, resp.Body)
}

// Хорошо — всегда закрываем
func goodHandler(w http.ResponseWriter, r *http.Request) {
    resp, err := http.Get("http://backend/api")
    if err != nil {
        http.Error(w, err.Error(), 500)
        return
    }
    defer resp.Body.Close() // освобождаем FD
    io.Copy(w, resp.Body)
}

Решения и лучшие практики

1. Увеличение лимита FD:

# Временно
ulimit -n 65535

# Постоянно — /etc/security/limits.conf
* soft nofile 65535
* hard nofile 65535

# Для systemd-сервиса — /etc/systemd/system/myapp.service
[Service]
LimitNOFILE=65535

2. Использование пула соединений:

// HTTP-клиент с пулом соединений
var httpClient = &http.Client{
    Transport: &http.Transport{
        MaxIdleConns:        100,
        MaxIdleConnsPerHost: 100,
        IdleConnTimeout:     90 * time.Second,
    },
    Timeout: 10 * time.Second,
}

3. Ограничение конкурентности:

// Semaphore для ограничения одновременных запросов
type Semaphore struct {
    sem chan struct{}
}

func NewSemaphore(max int) *Semaphore {
    return &Semaphore{sem: make(chan struct{}, max)}
}

func (s *Semaphore) Acquire() { s.sem <- struct{}{} }
func (s *Semaphore) Release() { <-s.sem }

var sem = NewSemaphore(100)

func handler(w http.ResponseWriter, r *http.Request) {
    sem.Acquire()
    defer sem.Release()
    
    // обработка запроса
}

4. Тайм-ауты на все операции:

// Контекст с тайм-аутом
ctx, cancel := context.WithTimeout(r.Context(), 5*time.Second)
defer cancel()

req, _ := http.NewRequestWithContext(ctx, "GET", "http://backend/api", nil)
resp, err := httpClient.Do(req)

5. Graceful shutdown:

func main() {
    srv := &http.Server{Addr: ":8080", Handler: handler()}
    
    go func() {
        sigCh := make(chan os.Signal, 1)
        signal.Notify(sigCh, syscall.SIGINT, syscall.SIGTERM)
        <-sigCh
        
        ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second)
        defer cancel()
        srv.Shutdown(ctx) // закрываем все соединения
    }()
    
    srv.ListenAndServe()
}

Мониторинг FD:

# Количество открытых FD для процесса
ls /proc/<pid>/fd | wc -l

# Детальная информация
ls -la /proc/<pid>/fd/

# Через lsof
lsof -p <pid> | wc -l

// В Go — через runtime
import "runtime"

func logFDCount() {
    // Косвенная метрика — количество goroutines
    log.Printf("Goroutines: %d", runtime.NumGoroutine())
}

Ключевые выводы

Файловые дескрипторы — ресурс ОС, горутины используют их для I/O.
Исчерпание FD приводит к ошибкам too many open files.
Блокирующие syscall блокируют M, но P переходит к другому M.
Утечка соединений — частая причина исчерпания FD.
Решения: увеличение лимита, пулы соединений, тайм-ауты, ограничение конкурентности.
Всегда закрывайте resp.Body, файлы и сокеты через defer.

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

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

Ответ собеседника: Правильный. Mutex блокирует и на чтение, и на запись. RWMutex позволяет не блокировать читателей друг от друга, но блокирует писателей.

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

sync.RWMutex реализует паттерн Read-Write Lock, разделяя блокировки на чтение и запись для повышения параллелизма.

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

Mutex — эксклюзивный доступ:

Горутина A: Lock() → [=========] Unlock()
Горутина B:         Lock() → ждёт... [====] Unlock()
Горутина C:                   Lock() → ждёт... [====] Unlock()

RWMutex — параллельное чтение:

Чтение:  A: RLock() → [===] RUnlock()
Чтение:  B: RLock() → [===] RUnlock()  ← параллельно с A!
Чтение:  C: RLock() → [===] RUnlock()  ← параллельно с A и B!
Запись:  D: Lock() → ждёт... [=========] Unlock()

API

type RWMutex struct {
    // Внутренняя реализация на основе Mutex + atomic
}

func (rw *RWMutex) Lock()    // эксклюзивная блокировка на запись
func (rw *RWMutex) Unlock()  // разблокировка записи
func (rw *RWMutex) RLock()   // разделяемая блокировка на чтение
func (rw *RWMutex) RUnlock() // разблокировка чтения
func (rw *RWMutex) RLocker() // возвращает интерфейс{Lock, Unlock}

Реализация кэша с RWMutex

type Cache struct {
    mu    sync.RWMutex
    items map[string]*cacheItem
    ttl   time.Duration
}

type cacheItem struct {
    value      interface{}
    expiration time.Time
}

func NewCache(ttl time.Duration) *Cache {
    c := &Cache{
        items: make(map[string]*cacheItem),
        ttl:   ttl,
    }
    
    // Фоновая очистка просроченных записей
    go c.cleanupLoop()
    
    return c
}

func (c *Cache) Get(key string) (interface{}, bool) {
    c.mu.RLock() // множество горутин могут читать параллельно
    defer c.mu.RUnlock()
    
    item, ok := c.items[key]
    if !ok || time.Now().After(item.expiration) {
        return nil, false
    }
    return item.value, true
}

func (c *Cache) Set(key string, value interface{}) {
    c.mu.Lock() // эксклюзивный доступ — блокирует и читателей, и писателей
    defer c.mu.Unlock()
    
    c.items[key] = &cacheItem{
        value:      value,
        expiration: time.Now().Add(c.ttl),
    }
}

func (c *Cache) Delete(key string) {
    c.mu.Lock()
    defer c.mu.Unlock()
    delete(c.items, key)
}

func (c *Cache) cleanupLoop() {
    ticker := time.NewTicker(c.ttl)
    defer ticker.Stop()
    
    for range ticker.C {
        c.mu.Lock()
        now := time.Now()
        for key, item := range c.items {
            if now.After(item.expiration) {
                delete(c.items, key)
            }
        }
        c.mu.Unlock()
    }
}

Внутренняя реализация RWMutex

// Упрощённая реализация (sync/rwmutex.go)
type RWMutex struct {
    w           sync.Mutex  // защищает внутреннее состояние
    writerSem   uint32      // семафор для писателей
    readerSem   uint33      // семафор для читателей
    readerCount int32       // количество активных читателей
    readerWait  int32       // количество читателей, ожидающих писателя
}

const rwmutexMaxReaders = 1 << 30 // максимум 1 073 741 824 читателей

Правила блокировки

Состояние	RLock()	Lock()
Нет блокировок	Разрешено	Разрешено
Есть читатели	Разрешено	Блокируется
Есть писатель	Блокируется	Блокируется
Есть ожидающие писатели	Блокируется	Блокируется

Проблема: голодание писателей

// Если читатели непрерывно приходят, писатель может ждать бесконечно
func main() {
    var mu sync.RWMutex
    
    // 1000 читателей приходят непрерывно
    for i := 0; i < 1000; i++ {
        go func() {
            for {
                mu.RLock()
                time.Sleep(time.Microsecond)
                mu.RUnlock()
            }
        }()
    }
    
    // Писатель может никогда не получить доступ
    time.Sleep(time.Second)
    mu.Lock() // может заблокироваться надолго
    fmt.Println("Writer acquired")
    mu.Unlock()
}

Решение в Go runtime:

Go предотвращает голодание писателей — когда писатель ждёт, новые читатели блокируются:

func (rw *RWMutex) RLock() {
    // Если есть ожидающий писатель — блокируемся
    if atomic.AddInt32(&rw.readerCount, 1) < 0 {
        // Писатель ждёт — паркуемся
        runtime_SemacquireMutex(&rw.readerSem, false, 0)
    }
}

func (rw *RWMutex) Lock() {
    rw.w.Lock()
    // Увеличиваем readerCount на отрицательное значение
    // Это сигнализирует новым читателям, что писатель ждёт
    r := atomic.AddInt32(&rw.readerCount, -rwmutexMaxReaders) + rwmutexMaxReaders
    // Ждём, пока все текущие читатели завершатся
    if r != 0 && atomic.AddInt32(&rw.readerWait, r) != 0 {
        runtime_SemacquireMutex(&rw.writerSem, false, 0)
    }
}

Бенчмарк: Mutex vs RWMutex

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

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

func BenchmarkRWMutexMixed(b *testing.B) {
    var mu sync.RWMutex
    data := map[string]int{"key": 42}
    
    b.RunParallel(func(pb *testing.PB) {
        i := 0
        for pb.Next() {
            if i%100 == 0 { // 1% записей
                mu.Lock()
                data["key"] = i
                mu.Unlock()
            } else { // 99% чтений
                mu.RLock()
                _ = data["key"]
                mu.RUnlock()
            }
            i++
        }
    })
}

Типичные результаты:

BenchmarkMutexRead-8        50000000    24.5 ns/op
BenchmarkRWMutexRead-8     100000000    10.2 ns/op  ← быстрее в 2.4 раза
BenchmarkRWMutexMixed-8     80000000    14.8 ns/op

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

// Хорошо — много чтений, мало записей
type Config struct {
    mu   sync.RWMutex
    data map[string]string
}

func (c *Config) Get(key string) string {
    c.mu.RLock()
    defer c.mu.RUnlock()
    return c.data[key]
}

func (c *Config) Set(key, value string) {
    c.mu.Lock()
    defer c.mu.Unlock()
    c.data[key] = value
}

// Плохо — много записей (RWMutex не даёт преимущества)
type Counter struct {
    mu    sync.RWMutex // избыточно!
    count int
}

func (c *Counter) Inc() {
    c.mu.Lock()
    defer c.mu.Unlock()
    c.count++
}

Сравнительная таблица

Характеристика	Mutex	RWMutex
Параллельное чтение	Нет	Да
Сложность	Простой	Сложнее
Производительность (чтение)	Ниже	Выше
Производительность (запись)	Выше	Ниже (overhead)
Голодание писателей	Нет	Предотвращено
Размер	8 байт	32 байта
Когда использовать	Любой доступ	Много чтений, мало записей

Ключевые выводы

RWMutex позволяет параллельное чтение — ускоряет read-heavy нагрузки.
Запись по-прежнему эксклюзивна — блокирует и читателей, и писателей.
Go предотвращает голодание писателей — новые читатели блокируются, если писатель ждёт.
Используйте RWMutex при соотношении чтений к записям > 10:1.
Для простых счётчиков с частой записью лучше подойдёт Mutex или atomic.

Вопрос 22. Можно ли вынести чтение переменной из-под мьютекса для оптимизации?

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

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

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

Вынесение чтения из-под мьютекса — распространённая ошибка, которая приводит к data race и непредсказуемому поведению.

Почему нельзя выносить чтение

// Плохо — data race!
func (c *Cache) Get(key string) interface{} {
    // Чтение БЕЗ блокировки — другая горутина может изменить items
    if item, ok := c.items[key]; ok { // ← race здесь
        c.mu.RLock()
        defer c.mu.RUnlock()
        return item.value
    }
    return nil
}

// Хорошо — всё чтение под блокировкой
func (c *Cache) Get(key string) interface{} {
    c.mu.RLock()
    defer c.mu.RUnlock()
    
    if item, ok := c.items[key]; ok {
        return item.value
    }
    return nil
}

Проблема: torn read

Для сложных типов данных чтение без блокировки может вернуть повреждённое значение:

type Config struct {
    Host string
    Port int
    TLS  bool
}

// Горутина A пишет:
config = Config{Host: "new-host", Port: 8080, TLS: true}

// Горутина B читает без блокировки:
// Может получить {Host: "new-host", Port: 3000, TLS: false}
// — смесь старых и новых значений!

Проблема: висящие указатели

// Плохо
func (c *Cache) Get(key string) *Item {
    c.mu.RLock()
    item := c.items[key]
    c.mu.RUnlock()
    
    // item может быть удалён другой горутиной после RUnlock!
    return item // ← висящий указатель
}

// Хорошо
func (c *Cache) Get(key string) (*Item, bool) {
    c.mu.RLock()
    defer c.mu.RUnlock()
    
    item, ok := c.items[key]
    return item, ok
}

Когда можно читать без блокировки

1. Атомарные типы:

type Server struct {
    isReady atomic.Bool
    counter atomic.Int64
}

func (s *Server) IsReady() bool {
    return s.isReady.Load() // атомарно — безопасно
}

func (s *Server) Counter() int64 {
    return s.counter.Load() // атомарно — безопасно
}

2. Неизменяемые данные (immutable):

type Config struct {
    mu   sync.RWMutex
    data atomic.Value // хранит неизменяемый snapshot
}

func (c *Config) Update(newData map[string]string) {
    c.mu.Lock()
    defer c.mu.Unlock()
    c.data.Store(newData) // атомарная замена указателя
}

func (c *Config) Get(key string) (string, bool) {
    // Без блокировки — читаем атомарный указатель
    data := c.data.Load().(map[string]string)
    val, ok := data[key]
    return val, ok
}

3. Copy-on-write:

type CowMap struct {
    mu   sync.Mutex
    data map[string]string
}

func (m *CowMap) Update(key, value string) {
    m.mu.Lock()
    defer m.mu.Unlock()
    
    // Создаём новую копию
    newData := make(map[string]string, len(m.data)+1)
    for k, v := range m.data {
        newData[k] = v
    }
    newData[key] = value
    m.data = newData // атомарная замена указателя
}

func (m *CowMap) Get(key string) (string, bool) {
    // Чтение без блокировки — указатель неизменен
    data := m.data // атомарное чтение указателя
    val, ok := data[key]
    return val, ok
}

Оптимизация: двойная проверка (Double-Checked Locking)

// Паттерн для ленивой инициализации
type Singleton struct {
    mu    sync.Mutex
    instance *ExpensiveObject
}

func (s *Singleton) Get() *ExpensiveObject {
    // Первая проверка без блокировки — быстро для уже инициализированного
    if s.instance != nil {
        return s.instance
    }
    
    // Блокировка только при необходимости
    s.mu.Lock()
    defer s.mu.Unlock()
    
    // Вторая проверка под блокировкой
    if s.instance != nil {
        return s.instance
    }
    
    s.instance = createExpensiveObject()
    return s.instance
}

Лучше использовать sync.Once:

type Singleton struct {
    once     sync.Once
    instance *ExpensiveObject
}

func (s *Singleton) Get() *ExpensiveObject {
    s.once.Do(func() {
        s.instance = createExpensiveObject()
    })
    return s.instance
}

Оптимизация: RWMutex вместо Mutex

// Вместо вынесения чтения — используйте RWMutex
type Cache struct {
    mu    sync.RWMutex // позволяет параллельное чтение
    items map[string]*Item
}

func (c *Cache) Get(key string) (*Item, bool) {
    c.mu.RLock() // не блокирует другие RLock
    defer c.mu.RUnlock()
    
    item, ok := c.items[key]
    return item, ok
}

func (c *Cache) Set(key string, item *Item) {
    c.mu.Lock() // блокирует всех
    defer c.mu.Unlock()
    
    c.items[key] = item
}

Пример: безопасное чтение снимка (snapshot)

type Store struct {
    mu   sync.RWMutex
    data map[string]int
}

// GetAll возвращает копию — безопасно использовать без блокировки
func (s *Store) GetAll() map[string]int {
    s.mu.RLock()
    defer s.mu.RUnlock()
    
    snapshot := make(map[string]int, len(s.data))
    for k, v := range s.data {
        snapshot[k] = v
    }
    return snapshot
}

// Клиент может работать со снимком без блокировки
func processData(store *Store) {
    data := store.GetAll() // получаем копию под блокировкой
    
    // Работаем с копией без блокировки
    for k, v := range data {
        fmt.Println(k, v)
    }
}

Ключевые выводы

Нельзя выносить чтение из-под мьютекса — это data race.
Можно читать без блокировки атомарные типы (atomic.Bool, atomic.Int64).
Можно читать неизменяемые данные (immutable, copy-on-write).
Для оптимизации чтения используйте RWMutex вместо Mutex.
Для ленивой инициализации — sync.Once или double-checked locking.
Для безопасного чтения коллекций — возвращайте копии (snapshot).

Вопрос 23. Напишите Worker Pool с использованием каналов в Go

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

Ответ собеседника: Неполный. Кандидат начал обсуждать архитектуру Worker Pool: создание пула воркеров, которые выполняют задачи. Обсудили, что функция Start должна принимать контекст для graceful shutdown. Кандидат начал писать код, но решение не было завершено.

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

Worker Pool — паттерн для ограничения количества одновременно выполняемых задач. Реализация с каналами:

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

package workerpool

import (
    "context"
    "sync"
)

// Task — функция-задача для выполнения
type Task func() error

// Pool — пул воркеров
type Pool struct {
    workers   int
    taskCh    chan Task
    errCh     chan error
    ctx       context.Context
    cancel    context.CancelFunc
    wg        sync.WaitGroup
}

// New создаёт новый пул воркеров
func New(workers, queueSize int) *Pool {
    ctx, cancel := context.WithCancel(context.Background())
    return &Pool{
        workers: workers,
        taskCh:  make(chan Task, queueSize),
        errCh:   make(chan error, queueSize),
        ctx:     ctx,
        cancel:  cancel,
    }
}

// Start запускает воркеры
func (p *Pool) Start() {
    for i := 0; i < p.workers; i++ {
        p.wg.Add(1)
        go p.worker(i)
    }
}

// worker — горутина, выполняющая задачи
func (p *Pool) worker(id int) {
    defer p.wg.Done()
    
    for {
        select {
        case task, ok := <-p.taskCh:
            if !ok {
                return // канал закрыт — завершаемся
            }
            if err := task(); err != nil {
                select {
                case p.errCh <- err:
                case <-p.ctx.Done():
                    return
                }
            }
        case <-p.ctx.Done():
            return // контекст отменён
        }
    }
}

// Submit добавляет задачу в очередь
func (p *Pool) Submit(task Task) error {
    select {
    case p.taskCh <- task:
        return nil
    case <-p.ctx.Done():
        return context.Canceled
    }
}

// SubmitSync добавляет задачу и ждёт её выполнения
func (p *Pool) SubmitSync(task Task) error {
    errCh := make(chan error, 1)
    
    submitErr := p.Submit(func() error {
        err := task()
        errCh <- err
        return err
    })
    if submitErr != nil {
        return submitErr
    }
    
    return <-errCh
}

// Stop ожидает завершения всех задач
func (p *Pool) Stop() {
    p.cancel()
    close(p.taskCh)
    p.wg.Wait()
    close(p.errCh)
}

// Errors возвращает канал ошибок
func (p *Pool) Errors() <-chan error {
    return p.errCh
}

Расширенная реализация с приоритетами и метриками

package workerpool

import (
    "context"
    "fmt"
    "sync"
    "sync/atomic"
    "time"
)

// Job — задача с контекстом
type Job struct {
    ID      string
    Execute func(ctx context.Context) error
}

// Result — результат выполнения
type Result struct {
    JobID string
    Err   error
    Duration time.Duration
}

// AdvancedPool — расширенный пул воркеров
type AdvancedPool struct {
    numWorkers    int
    jobCh         chan Job
    resultCh      chan Result
    ctx           context.Context
    cancel        context.CancelFunc
    wg            sync.WaitGroup
    
    // Метрики
    jobsSubmitted   atomic.Int64
    jobsCompleted   atomic.Int64
    jobsFailed      atomic.Int64
    totalDuration   atomic.Int64 // в наносекундах
}

// NewAdvanced создаёт расширенный пул
func NewAdvanced(numWorkers, queueSize int) *AdvancedPool {
    ctx, cancel := context.WithCancel(context.Background())
    return &AdvancedPool{
        numWorkers: numWorkers,
        jobCh:      make(chan Job, queueSize),
        resultCh:   make(chan Result, queueSize),
        ctx:        ctx,
        cancel:     cancel,
    }
}

// Start запускает воркеры
func (p *AdvancedPool) Start() {
    for i := 0; i < p.numWorkers; i++ {
        p.wg.Add(1)
        go p.worker(i)
    }
}

func (p *AdvancedPool) worker(id int) {
    defer p.wg.Done()
    
    for {
        select {
        case job, ok := <-p.jobCh:
            if !ok {
                return
            }
            p.processJob(job)
            
        case <-p.ctx.Done():
            // Обрабатываем оставшиеся задачи в канале
            for job := range p.jobCh {
                p.processJob(job)
            }
            return
        }
    }
}

func (p *AdvancedPool) processJob(job Job) {
    start := time.Now()
    
    // Создаём контекст с тайм-аутом для задачи
    ctx, cancel := context.WithTimeout(p.ctx, 30*time.Second)
    defer cancel()
    
    err := job.Execute(ctx)
    duration := time.Since(start)
    
    result := Result{
        JobID:    job.ID,
        Err:      err,
        Duration: duration,
    }
    
    p.totalDuration.Add(int64(duration))
    
    if err != nil {
        p.jobsFailed.Add(1)
    } else {
        p.jobsCompleted.Add(1)
    }
    
    select {
    case p.resultCh <- result:
    case <-p.ctx.Done():
    }
}

// Submit отправляет задачу
func (p *AdvancedPool) Submit(job Job) error {
    p.jobsSubmitted.Add(1)
    
    select {
    case p.jobCh <- job:
        return nil
    case <-p.ctx.Done():
        return fmt.Errorf("pool is stopped")
    }
}

// SubmitWithTimeout отправляет задачу с тайм-аутом
func (p *AdvancedPool) SubmitWithTimeout(job Job, timeout time.Duration) error {
    p.jobsSubmitted.Add(1)
    
    ctx, cancel := context.WithTimeout(p.ctx, timeout)
    defer cancel()
    
    select {
    case p.jobCh <- job:
        return nil
    case <-ctx.Done():
        return fmt.Errorf("submit timed out")
    }
}

// Results возвращает канал результатов
func (p *AdvancedPool) Results() <-chan Result {
    return p.resultCh
}

// Stop graceful shutdown
func (p *AdvancedPool) Stop() {
    p.cancel()
    close(p.jobCh)
    p.wg.Wait()
    close(p.resultCh)
}

// Stats возвращает статистику
func (p *AdvancedPool) Stats() map[string]interface{} {
    submitted := p.jobsSubmitted.Load()
    completed := p.jobsCompleted.Load()
    failed := p.jobsFailed.Load()
    totalDur := time.Duration(p.totalDuration.Load())
    
    avgDuration := time.Duration(0)
    if completed > 0 {
        avgDuration = totalDur / time.Duration(completed)
    }
    
    return map[string]interface{}{
        "submitted":    submitted,
        "completed":    completed,
        "failed":       failed,
        "in_progress":  submitted - completed - failed,
        "avg_duration": avgDuration,
    }
}

Пример использования

func main() {
    // Создаём пул с 5 воркерами и очередью на 100 задач
    pool := workerpool.NewAdvanced(5, 100)
    pool.Start()
    
    // Горутина для сбора результатов
    go func() {
        for result := range pool.Results() {
            if result.Err != nil {
                log.Printf("Job %s failed: %v", result.JobID, result.Err)
            } else {
                log.Printf("Job %s completed in %v", result.JobID, result.Duration)
            }
        }
    }()
    
    // Отправляем задачи
    for i := 0; i < 50; i++ {
        id := fmt.Sprintf("job-%d", i)
        pool.Submit(workerpool.Job{
            ID: id,
            Execute: func(ctx context.Context) error {
                // Имитация работы
                select {
                case <-time.After(time.Duration(rand.Intn(100)) * time.Millisecond):
                    return nil
                case <-ctx.Done():
                    return ctx.Err()
                }
            },
        })
    }
    
    // Graceful shutdown
    pool.Stop()
    
    // Выводим статистику
    stats := pool.Stats()
    fmt.Printf("Stats: %+v\n", stats)
}

Реализация с динамическим масштабированием

type DynamicPool struct {
    minWorkers    int
    maxWorkers    int
    jobCh         chan Job
    resultCh      chan Result
    ctx           context.Context
    cancel        context.CancelFunc
    wg            sync.WaitGroup
    
    mu            sync.Mutex
    workers       int
    idleWorkers   int
}

func NewDynamic(min, max, queueSize int) *DynamicPool {
    ctx, cancel := context.WithCancel(context.Background())
    return &DynamicPool{
        minWorkers: min,
        maxWorkers: max,
        jobCh:      make(chan Job, queueSize),
        resultCh:   make(chan Result, queueSize),
        ctx:        ctx,
        cancel:     cancel,
    }
}

func (p *DynamicPool) Start() {
    for i := 0; i < p.minWorkers; i++ {
        p.addWorker()
    }
    
    // Мониторинг для масштабирования
    go p.scaleLoop()
}

func (p *DynamicPool) addWorker() {
    p.mu.Lock()
    defer p.mu.Unlock()
    
    if p.workers >= p.maxWorkers {
        return
    }
    
    p.workers++
    p.wg.Add(1)
    go p.worker()
}

func (p *DynamicPool) removeWorker() {
    p.mu.Lock()
    defer p.mu.Unlock()
    
    if p.workers <= p.minWorkers {
        return
    }
    
    // Отправляем сигнал завершения
    p.jobCh <- Job{
        ID: "__stop__",
        Execute: func(ctx context.Context) error {
            return errWorkerStop
        },
    }
}

var errWorkerStop = fmt.Errorf("worker stop")

func (p *DynamicPool) worker() {
    defer p.wg.Done()
    
    for {
        select {
        case job, ok := <-p.jobCh:
            if !ok {
                return
            }
            
            if job.ID == "__stop__" {
                p.mu.Lock()
                p.workers--
                p.mu.Unlock()
                return
            }
            
            start := time.Now()
            err := job.Execute(p.ctx)
            
            select {
            case p.resultCh <- Result{
                JobID:    job.ID,
                Err:      err,
                Duration: time.Since(start),
            }:
            case <-p.ctx.Done():
                return
            }
            
        case <-p.ctx.Done():
            return
        }
    }
}

func (p *DynamicPool) scaleLoop() {
    ticker := time.NewTicker(5 * time.Second)
    defer ticker.Stop()
    
    for {
        select {
        case <-ticker.C:
            // Если очередь заполнена — добавляем воркера
            if len(p.jobCh) > cap(p.jobCh)*3/4 {
                p.addWorker()
            }
            // Если очередь пуста и воркеров больше минимума — убираем
            if len(p.jobCh) == 0 {
                p.mu.Lock()
                idle := p.idleWorkers
                p.mu.Unlock()
                
                if idle > p.minWorkers {
                    p.removeWorker()
                }
            }
        case <-p.ctx.Done():
            return
        }
    }
}

Ключевые выводы

Worker Pool ограничивает количество одновременных задач.
Канал taskCh — очередь задач с буферизацией.
context.Context — для graceful shutdown.
sync.WaitGroup — для ожидания завершения всех воркеров.
Расширенные возможности: метрики, тайм-ауты, динамическое масштабирование.
Паттерн применим для: обработки HTTP-запросов, воркеров очередей, ограничения нагрузки на внешние сервисы.

Вопрос 24. Чем отличается context.TODO() от context.Background()?

Таймкод: 01:07:27

Ответ собеседника: Правильный. Подкапотом ничем не отличаются — оба пустые контексты. Разница в семантике: TODO — когда ещё не решили, Background — корневой контекст по умолчанию.

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

context.Background() и context.TODO() — это два предопределённых пустых контекста, которые идентичны по реализации, но имеют разное семантическое назначение.

Реализация

// context.go
var (
    background = new(emptyCtx)
    todo       = new(emptyCtx)
)

func Background() Context {
    return background
}

func TODO() Context {
    return todo
}

type emptyCtx int

func (*emptyCtx) Deadline() (deadline time.Time, ok bool) {
    return
}

func (*emptyCtx) Done() <-chan struct{} {
    return nil
}

func (*emptyCtx) Err() error {
    return nil
}

func (*emptyCtx) Value(key any) any {
    return nil
}

Оба возвращают *emptyCtx — без дедлайна, без отмены, без значений.

Семантическое различие

context.Background() — корневой контекст верхнего уровня:

// Использование: точка входа приложения
func main() {
    ctx := context.Background()
    
    // Передаём вниз по стеку
    srv := NewServer(ctx, config)
    srv.Start()
}

// HTTP-сервер
func (s *Server) handleRequest(w http.ResponseWriter, r *http.Request) {
    ctx := r.Context() // контекст запроса, а не Background
    processOrder(ctx, orderID)
}

// gRPC-обработчик
func (s *Server) GetOrder(ctx context.Context, req *pb.OrderRequest) {
    // ctx уже приходит из gRPC
    return s.service.GetOrder(ctx, req.Id)
}

context.TODO() — заглушка «на потом»:

// Использование: когда не уверены, какой контекст нужен
func NewService(db *sqlx.DB) *Service {
    // TODO: добавить контекст после рефакторинга
    return &Service{db: db}
}

func (s *Service) processJob(job Job) error {
    // TODO: переделать на ctx, когда рефакторим вызывающий код
    ctx := context.TODO()
    return s.repo.Save(ctx, job)
}

// Или при работе с внешним API без контекста
func callLegacyAPI(data []byte) error {
    // Legacy API не принимает контекст — используем TODO как заглушку
    ctx := context.TODO()
    span, _ := tracer.Start(ctx, "legacy-call")
    defer span.End()
    // ...
}

Когда что использовать

Ситуация	Использовать
`main()`, инициализация	`Background()`
HTTP/gRPC handler	Контекст из запроса
Фоновые задачи	`Background()`
Не уверен какой контекст	`TODO()`
Рефакторинг в процессе	`TODO()`
Внешний API без контекста	`TODO()`

Пример: правильное использование

// main.go
func main() {
    ctx, cancel := context.WithCancel(context.Background())
    defer cancel()
    
    // Graceful shutdown
    sigCh := make(chan os.Signal, 1)
    signal.Notify(sigCh, syscall.SIGINT, syscall.SIGTERM)
    
    go func() {
        <-sigCh
        cancel()
    }()
    
    if err := run(ctx); err != nil {
        log.Fatal(err)
    }
}

// service.go
type OrderService struct {
    repo   OrderRepository
    client PaymentClient
}

func (s *OrderService) ProcessOrder(ctx context.Context, orderID int) error {
    // ctx приходит сверху — не создаём Background/TODO
    order, err := s.repo.GetByID(ctx, orderID)
    if err != nil {
        return err
    }
    
    return s.client.Charge(ctx, order.Amount)
}

// legacy_integration.go
func callExternalService(data []byte) error {
    // Внешняя библиотека не поддерживает контекст
    ctx := context.TODO() // семантика: «пока нечего передать»
    
    // Но если нужно трассирование:
    span, ctx := tracer.Start(ctx, "external-call")
    defer span.End()
    
    return external.Call(data)
}

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

// Плохо — Background в сервисном слое
func (s *Service) GetOrder(id int) (*Order, error) {
    ctx := context.Background() // теряем трассировку, тайм-ауты, отмену
    return s.repo.GetByID(ctx, id)
}

// Хорошо — принимаем контекст
func (s *Service) GetOrder(ctx context.Context, id int) (*Order, error) {
    return s.repo.GetByID(ctx, id)
}

// Плохо — TODO в продакшн-коде навсегда
func (s *Service) Process(ctx context.Context, data []byte) error {
    // TODO остался из прототипа и никогда не был заменён
    ctx = context.TODO() // перезаписали входящий контекст!
    return s.doWork(ctx, data)
}

Ключевые выводы

Background() и TODO() идентичны по реализации.
Background() — для корневого контекста верхнего уровня.
TODO() — как маркер «на потом» при рефакторинге.
TODO() должен быть временным — замените на реальный контекст при первой возможности.
Никогда не используйте Background() внутри сервисного слоя — принимайте контекст как параметр.
Оба контекста неотменяемы и без дедлайна.

Вопрос 25. Как правильно реализовать Worker Pool на каналах в Go?

Таймкод: 01:08:41

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

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

Этот вопрос дублирует Вопрос 23. Приведу краткое резюме с акцентом на ключевые моменты.

Минимальная реализация

type Pool struct {
    workers  int
    taskCh   chan func()
    ctx      context.Context
    cancel   context.CancelFunc
    wg       sync.WaitGroup
}

func New(workers, queueSize int) *Pool {
    ctx, cancel := context.WithCancel(context.Background())
    return &Pool{
        workers: workers,
        taskCh:  make(chan func(), queueSize),
        ctx:     ctx,
        cancel:  cancel,
    }
}

func (p *Pool) Start() {
    for i := 0; i < p.workers; i++ {
        p.wg.Add(1)
        go func() {
            defer p.wg.Done()
            for {
                select {
                case task, ok := <-p.taskCh:
                    if !ok {
                        return
                    }
                    task()
                case <-p.ctx.Done():
                    return
                }
            }
        }()
    }
}

func (p *Pool) Submit(task func()) error {
    select {
    case p.taskCh <- task:
        return nil
    case <-p.ctx.Done():
        return context.Canceled
    }
}

func (p *Pool) Stop() {
    p.cancel()
    close(p.taskCh)
    p.wg.Wait()
}

Ключевые компоненты

Канал задач (taskCh) — буферизованная очередь для распределения задач между воркерами.
Воркеры — горутины, читающие из канала и выполняющие задачи.
Контекст — для graceful shutdown.
WaitGroup — для ожидания завершения всех воркеров.

Распределение задач

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

// Канал сам балансирует нагрузку
// Воркеры, освободившиеся первыми, получают следующие задачи
for task := range taskCh {
    task() // выполняем
}

Graceful shutdown

func (p *Pool) Stop() {
    p.cancel()      // сигнализируем о завершении
    close(p.taskCh) // закрываем канал — воркеры завершатся после обработки
    p.wg.Wait()     // ждём завершения всех воркеров
}

Подробная реализация с метриками, обработкой ошибок и динамическим масштабированием — см. ответ на Вопрос 23.

Вопрос 26. Как реализовать неблокирующий метод Schedule в Worker Pool?

Таймкод: 01:26:48

Ответ собеседника: Правильный. Вынести запись в канал в отдельную горутину с select: либо задача отправляется, либо контекст завершается. Это позволяет не блокировать вызывающий код.

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

Неблокирующий Schedule — метод, который не блокирует вызывающий код, даже если очередь задач заполнена или пул остановлен.

Проблема блокирующего Submit

// Блокирующий — останавливает вызывающий код
func (p *Pool) Submit(task Task) error {
    p.taskCh <- task // блокируется, если канал полон!
    return nil
}

Вариант 1: Неблокирующий с немедленной ошибкой

// TrySubmit — возвращает ошибку, если очередь полна
func (p *Pool) TrySubmit(task Task) error {
    select {
    case p.taskCh <- task:
        return nil
    default:
        return ErrQueueFull
    }
}

Вариант 2: Неблокирующий с горутиной

// Schedule — не блокирует вызывающий код
func (p *Pool) Schedule(task Task) {
    go func() {
        select {
        case p.taskCh <- task:
            // задача отправлена
        case <-p.ctx.Done():
            // пул остановлен — задача отброшена
        }
    }()
}

Вариант 3: Schedule с callback и обработкой ошибок

// ScheduleResult — результат попытки отправки
type ScheduleResult struct {
    Submitted bool
    Err       error
}

// ScheduleAsync — неблокирующий с уведомлением
func (p *Pool) ScheduleAsync(task Task, callback func(ScheduleResult)) {
    go func() {
        select {
        case p.taskCh <- task:
            if callback != nil {
                callback(ScheduleResult{Submitted: true})
            }
        case <-p.ctx.Done():
            if callback != nil {
                callback(ScheduleResult{Err: ErrPoolStopped})
            }
        default:
            if callback != nil {
                callback(ScheduleResult{Err: ErrQueueFull})
            }
        }
    }()
}

Вариант 4: Полная реализация с приоритетами

type Pool struct {
    workers    int
    taskCh     chan Task          // обычные задачи
    priorityCh chan Task          // приоритетные задачи
    dropped    atomic.Int64       // счётчик отброшенных
    ctx        context.Context
    cancel     context.CancelFunc
    wg         sync.WaitGroup
}

func (p *Pool) Start() {
    for i := 0; i < p.workers; i++ {
        p.wg.Add(1)
        go p.worker()
    }
}

func (p *Pool) worker() {
    defer p.wg.Done()
    
    for {
        // Приоритетная очередь обрабатывается первой
        select {
        case task := <-p.priorityCh:
            p.execute(task)
            continue
        default:
        }
        
        select {
        case task := <-p.priorityCh:
            p.execute(task)
        case task := <-p.taskCh:
            p.execute(task)
        case <-p.ctx.Done():
            return
        }
    }
}

func (p *Pool) execute(task Task) {
    defer func() {
        if r := recover(); r != nil {
            log.Printf("task panic: %v", r)
        }
    }()
    task()
}

// Submit — блокирующий
func (p *Pool) Submit(task Task) error {
    select {
    case p.taskCh <- task:
        return nil
    case <-p.ctx.Done():
        return ErrPoolStopped
    }
}

// TrySubmit — неблокирующий с ошибкой
func (p *Pool) TrySubmit(task Task) error {
    select {
    case p.taskCh <- task:
        return nil
    default:
        p.dropped.Add(1)
        return ErrQueueFull
    }
}

// Schedule — полностью неблокирующий
func (p *Pool) Schedule(task Task) {
    go func() {
        select {
        case p.taskCh <- task:
        case <-p.ctx.Done():
            p.dropped.Add(1)
        default:
            p.dropped.Add(1)
        }
    }()
}

// SubmitPriority — приоритетная задача
func (p *Pool) SubmitPriority(task Task) error {
    select {
    case p.priorityCh <- task:
        return nil
    case <-p.ctx.Done():
        return ErrPoolStopped
    }
}

func (p *Pool) DroppedCount() int64 {
    return p.dropped.Load()
}

Пример использования

func main() {
    pool := NewPool(5, 100)
    pool.Start()
    defer pool.Stop()
    
    // Блокирующий Submit — ждёт свободного места
    err := pool.Submit(func() {
        fmt.Println("blocking task")
    })
    if err != nil {
        log.Printf("submit failed: %v", err)
    }
    
    // Неблокирующий TrySubmit — ошибка если полон
    err = pool.TrySubmit(func() {
        fmt.Println("try task")
    })
    if err != nil {
        log.Printf("queue full: %v", err)
    }
    
    // Полностью неблокирующий Schedule — не ждёт вообще
    pool.Schedule(func() {
        fmt.Println("scheduled task")
    })
    
    // С callback
    pool.ScheduleAsync(func() {
        fmt.Println("async task")
    }, func(result ScheduleResult) {
        if result.Err != nil {
            log.Printf("schedule failed: %v", result.Err)
        }
    })
    
    time.Sleep(time.Second)
    fmt.Printf("Dropped: %d\n", pool.DroppedCount())
}

Сравнение подходов

Метод	Блокирует	Ошибка при полной очереди	Использование
`Submit`	Да	Нет (ждёт)	Критичные задачи
`TrySubmit`	Нет	Да	Когда нужна обратная связь
`Schedule`	Нет	Нет (отбрасывает)	Некритичные задачи
`ScheduleAsync`	Нет	Callback	Нужно уведомление

Ключевые выводы

select с default — основа неблокирующих операций с каналами.
Горутина внутри Schedule — цена неблокируемости (накладные расходы на создание горутины).
Счётчик отброшенных задач — важен для мониторинга.
Приоритетная очередь — через отдельный канал с проверкой в первую очередь.
Выбирайте подход в зависимости от требований: можно ли отбрасывать задачи, нужна ли обратная связь.

Вопрос 27. Как дождаться завершения всех задач и получить результаты в Worker Pool?

Таймкод: 01:28:05

Ответ собеседника: Правильный. Создать отдельный канал результатов, в который воркеры записывают результаты. Закрыть канал Jobs после отправки задач. Использовать метод Stop/Results для ожидания завершения.

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

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

Архитектура

Producer → [taskCh] → Workers → [resultCh] → Consumer

Полная реализация с результатами

package workerpool

import (
    "context"
    "fmt"
    "sync"
)

// Task — задача для выполнения
type Task func() (interface{}, error)

// Result — результат выполнения задачи
type Result struct {
    Value interface{}
    Err   error
}

// Pool — пул воркеров с результатами
type Pool struct {
    workers  int
    taskCh   chan Task
    resultCh chan Result
    ctx      context.Context
    cancel   context.CancelFunc
    wg       sync.WaitGroup
}

// New создаёт новый пул
func New(workers, queueSize int) *Pool {
    ctx, cancel := context.WithCancel(context.Background())
    return &Pool{
        workers:  workers,
        taskCh:   make(chan Task, queueSize),
        resultCh: make(chan Result, queueSize),
        ctx:      ctx,
        cancel:   cancel,
    }
}

// Start запускает воркеры
func (p *Pool) Start() {
    for i := 0; i < p.workers; i++ {
        p.wg.Add(1)
        go p.worker()
    }
}

func (p *Pool) worker() {
    defer p.wg.Done()
    
    for {
        select {
        case task, ok := <-p.taskCh:
            if !ok {
                return // канал задач закрыт
            }
            value, err := task()
            
            // Отправляем результат
            select {
            case p.resultCh <- Result{Value: value, Err: err}:
            case <-p.ctx.Done():
                return
            }
            
        case <-p.ctx.Done():
            return
        }
    }
}

// Submit отправляет задачу
func (p *Pool) Submit(task Task) error {
    select {
    case p.taskCh <- task:
        return nil
    case <-p.ctx.Done():
        return fmt.Errorf("pool stopped")
    }
}

// Results возвращает канал результатов
func (p *Pool) Results() <-chan Result {
    return p.resultCh
}

// Stop закрывает канал задач и ждёт завершения
func (p *Pool) Stop() {
    close(p.taskCh) // сигнал воркерам завершиться
    p.wg.Wait()     // ждём завершения всех воркеров
    close(p.resultCh) // закрываем канал результатов
}

Паттерн: SubmitAll + CollectResults

// ProcessAll отправляет все задачи и собирает результаты
func ProcessAll(tasks []Task, workers int) ([]Result, error) {
    pool := New(workers, len(tasks))
    pool.Start()
    
    // Отправляем все задачи
    for _, task := range tasks {
        if err := pool.Submit(task); err != nil {
            return nil, err
        }
    }
    
    // Закрываем канал задач — воркеры завершатся после обработки
    pool.Stop()
    
    // Собираем результаты
    var results []Result
    for result := range pool.Results() {
        results = append(results, result)
    }
    
    return results, nil
}

Паттерн: с контекстом и тайм-аутом

// ProcessWithTimeout — с ограничением времени
func ProcessWithTimeout(ctx context.Context, tasks []Task, workers int, timeout time.Duration) ([]Result, []error) {
    ctx, cancel := context.WithTimeout(ctx, timeout)
    defer cancel()
    
    pool := New(workers, len(tasks))
    pool.ctx = ctx
    pool.cancel = cancel
    pool.Start()
    
    // Горутина для отправки задач
    go func() {
        defer pool.Stop()
        for _, task := range tasks {
            select {
            case pool.taskCh <- task:
            case <-ctx.Done():
                return
            }
        }
    }()
    
    // Собираем результаты
    var results []Result
    var errs []error
    
    for {
        select {
        case result, ok := <-pool.Results():
            if !ok {
                return results, errs
            }
            results = append(results, result)
            if result.Err != nil {
                errs = append(errs, result.Err)
            }
        case <-ctx.Done():
            return results, append(errs, ctx.Err())
        }
    }
}

Паттерн: раннее завершение при ошибке

// ProcessUntilError — останавливается при первой ошибке
func ProcessUntilError(ctx context.Context, tasks []Task, workers int) error {
    pool := New(workers, len(tasks))
    pool.Start()
    
    ctx, cancel := context.WithCancel(ctx)
    defer cancel()
    
    // Отправляем задачи
    go func() {
        defer pool.Stop()
        for _, task := range tasks {
            select {
            case pool.taskCh <- task:
            case <-ctx.Done():
                return
            }
        }
    }()
    
    // Проверяем результаты
    for result := range pool.Results() {
        if result.Err != nil {
            cancel() // отменяем оставшиеся задачи
            return result.Err
        }
    }
    
    return nil
}

Пример использования

func main() {
    // Создаём задачи
    tasks := make([]Task, 10)
    for i := 0; i < 10; i++ {
        id := i
        tasks[i] = func() (interface{}, error) {
            time.Sleep(time.Duration(rand.Intn(100)) * time.Millisecond)
            return fmt.Sprintf("result-%d", id), nil
        }
    }
    
    // Обрабатываем и собираем результаты
    results, err := ProcessAll(tasks, 3)
    if err != nil {
        log.Fatal(err)
    }
    
    // Выводим результаты
    for _, r := range results {
        if r.Err != nil {
            fmt.Printf("Error: %v\n", r.Err)
        } else {
            fmt.Printf("Value: %v\n", r.Value)
        }
    }
}

Паттерн: с порядком результатов

// IndexedResult — результат с индексом для сохранения порядка
type IndexedResult struct {
    Index  int
    Value  interface{}
    Err    error
}

// ProcessOrdered — возвращает результаты в порядке отправки
func ProcessOrdered(tasks []Task, workers int) ([]Result, error) {
    pool := New(workers, len(tasks))
    pool.Start()
    
    resultCh := make(chan IndexedResult, len(tasks))
    
    // Воркеры с индексами
    var wg sync.WaitGroup
    for i := 0; i < workers; i++ {
        wg.Add(1)
        go func() {
            defer wg.Done()
            for task := range pool.taskCh {
                value, err := task()
                resultCh <- IndexedResult{Value: value, Err: err}
            }
        }()
    }
    
    // Отправляем задачи с индексами
    for i, task := range tasks {
        pool.taskCh <- func(idx int, t Task) Task {
            return func() (interface{}, error) {
                val, err := t()
                return IndexedResult{Index: idx, Value: val, Err: err}, nil
            }
        }(i, task)
    }
    
    close(pool.taskCh)
    wg.Wait()
    close(resultCh)
    
    // Собираем и сортируем результаты
    indexed := make([]Result, len(tasks))
    for r := range resultCh {
        ir := r.Value.(IndexedResult)
        indexed[ir.Index] = Result{Value: ir.Value, Err: ir.Err}
    }
    
    return indexed, nil
}

Ключевые выводы

Отдельный канал результатов — для сбора результатов от воркеров.
Закрытие taskCh — сигнал воркерам завершиться после обработки всех задач.
WaitGroup — ожидание завершения всех воркеров перед закрытием resultCh.
Порядок закрытия: taskCh → wg.Wait() → resultCh.
Контекст — для тайм-аутов и ранней отмены.
IndexedResult — для сохранения порядка результатов.

Вопрос 28. Можно ли хранить контекст в поле структуры и как организовать отмену?

Таймкод: 01:28:50

Ответ собеседника: Правильный. Хранение контекста в поле — антипаттерн, но для отмены можно использовать канал отмены (done channel). Из дочернего контекста извлечь канал Done() и сохранить в структуре.

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

Хранение контекста в поле структуры — распространённая дискуссия в Go-сообществе. Есть как сторонники, так и противники этого подхода.

Антипаттерн: хранение контекста в структуре

// Плохо — контекст в поле структуры
type Service struct {
    ctx context.Context // антипаттерн!
    db  *sqlx.DB
}

func (s *Service) GetOrder(id int) (*Order, error) {
    // ctx из поля — откуда он пришёл? Какой у него тайм-аут?
    return s.repo.GetByID(s.ctx, id)
}

Почему это плохо:

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

Правильный подход: контекст как параметр

// Хорошо — контекст передаётся явно
type Service struct {
    db *sqlx.DB
}

func (s *Service) GetOrder(ctx context.Context, id int) (*Order, error) {
    return s.repo.GetByID(ctx, id)
}

Когда хранение контекста допустимо

1. Долгоживущие объекты с жизненным циклом:

// Допустимо — сервис с явным жизненным циклом
type Server struct {
    ctx    context.Context
    cancel context.CancelFunc
    db     *sqlx.DB
}

func NewServer(db *sqlx.DB) *Server {
    ctx, cancel := context.WithCancel(context.Background())
    return &Server{
        ctx:    ctx,
        cancel: cancel,
        db:     db,
    }
}

func (s *Server) Start() {
    for {
        select {
        case <-s.ctx.Done():
            return
        case job := <-s.jobCh:
            s.processJob(job)
        }
    }
}

func (s *Server) Stop() {
    s.cancel()
}

2. Рабочие горутины (worker):

type Worker struct {
    ctx    context.Context
    cancel context.CancelFunc
    taskCh chan Task
}

func NewWorker(parent context.Context) *Worker {
    ctx, cancel := context.WithCancel(parent)
    return &Worker{
        ctx:    ctx,
        cancel: cancel,
        taskCh: make(chan Task, 100),
    }
}

func (w *Worker) Run() {
    for {
        select {
        case <-w.ctx.Done():
            return
        case task := <-w.taskCh:
            task()
        }
    }
}

func (w *Worker) Stop() {
    w.cancel()
}

Паттерн: канал отмены вместо контекста

// Альтернатива — собственный канал отмены
type Worker struct {
    done   chan struct{}
    taskCh chan Task
}

func NewWorker() *Worker {
    return &Worker{
        done:   make(chan struct{}),
        taskCh: make(chan Task, 100),
    }
}

func (w *Worker) Run() {
    for {
        select {
        case <-w.done:
            return
        case task := <-w.taskCh:
            task()
        }
    }
}

func (w *Worker) Stop() {
    close(w.done)
}

Паттерн: обёртка над контекстом

// Если нужна отмена без контекста
type Cancellable struct {
    mu     sync.Mutex
    done   chan struct{}
    closed bool
}

func NewCancellable() *Cancellable {
    return &Cancellable{
        done: make(chan struct{}),
    }
}

func (c *Cancellable) Done() <-chan struct{} {
    return c.done
}

func (c *Cancellable) Cancel() {
    c.mu.Lock()
    defer c.mu.Unlock()
    
    if !c.closed {
        close(c.done)
        c.closed = true
    }
}

func (c *Cancellable) IsCancelled() bool {
    select {
    case <-c.done:
        return true
    default:
        return false
    }
}

Паттерн: композиция контекстов

// Несколько источников отмены
type MultiCancel struct {
    ctx    context.Context
    cancel context.CancelFunc
    done   chan struct{}
}

func NewMultiCancel(parent context.Context) *MultiCancel {
    ctx, cancel := context.WithCancel(parent)
    return &MultiCancel{
        ctx:    ctx,
        cancel: cancel,
        done:   make(chan struct{}),
    }
}

func (mc *MultiCancel) Done() <-chan struct{} {
    // Объединяем два источника отканцеляции
    merged := make(chan struct{})
    
    go func() {
        select {
        case <-mc.ctx.Done():
        case <-mc.done:
        }
        close(merged)
    }()
    
    return merged
}

func (mc *MultiCancel) Cancel() {
    mc.cancel()
    close(mc.done)
}

Рекомендации по организации отмены

// Сервис с правильной организацией отмены
type OrderService struct {
    ctx    context.Context
    cancel context.CancelFunc
    repo   OrderRepository
    wg     sync.WaitGroup
}

func NewOrderService(parent context.Context, repo OrderRepository) *OrderService {
    ctx, cancel := context.WithCancel(parent)
    return &OrderService{
        ctx:    ctx,
        cancel: cancel,
        repo:   repo,
    }
}

// Фоновая задача
func (s *OrderService) StartBackgroundWorker() {
    s.wg.Add(1)
    go func() {
        defer s.wg.Done()
        
        ticker := time.NewTicker(5 * time.Second)
        defer ticker.Stop()
        
        for {
            select {
            case <-s.ctx.Done():
                return
            case <-ticker.C:
                s.processPendingOrders()
            }
        }
    }()
}

// Graceful shutdown
func (s *OrderService) Shutdown() error {
    s.cancel()      // отменяем контекст
    s.wg.Wait()     // ждём завершения горутин
    return nil
}

// Метод с контекстом из параметра — для внешних вызовов
func (s *OrderService) GetOrder(ctx context.Context, id int) (*Order, error) {
    return s.repo.GetByID(ctx, id)
}

Ключевые выводы

Контекст как параметр — предпочтительный подход для API.
Контекст в поле — допустим для долгоживущих объектов с явным жизненным циклом.
Канал отмены — альтернатива, если не нужны значения и дедлайны контекста.
Graceful shutdown: cancel → WaitGroup.Wait() → закрытие ресурсов.
Дочерний контекст наследует отмену от родителя, но может быть отменён независимо.

Вопрос 29. Где на практике используются арены в Go?

Таймкод: 01:41:52

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

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

Арены (arenas) — механизм выделения памяти, позволяющий группировать объекты и освобождать их одним вызовом. В Go представлены экспериментальным пакетом arena (Go 1.20+).

Что такое арена

Арена — непрерывный блок памяти, из которого выделяются объекты. Все объекты в арене освобождаются одновременно при вызове Free().

import "arena"

func process() {
    a := arena.NewArena()
    defer a.Free() // все объекты в арене освобождаются разом
    
    s := arena.MakeSlice[int](a, 0, 100)
    s = arena.Append(a, s, 1, 2, 3)
    
    p := arena.New[Point](a)
    p.X = 10
    p.Y = 20
}

Практические случаи использования

1. Обработка запросов с известным временем жизни

func handleRequest(w http.ResponseWriter, r *http.Request) {
    a := arena.NewArena()
    defer a.Free()
    
    // Все временные объекты для этого запроса
    params := arena.MakeSlice[string](a, 0, 10)
    headers := arena.MakeMap[string, string](a)
    buffer := arena.MakeSlice[byte](a, 0, 4096)
    
    // Обработка...
    processData(params, headers, buffer)
    
    // При завершении запроса — вся память освобождается одним вызовом
}

2. Парсинг и десериализация

func parseJSON(data []byte) (*Document, error) {
    a := arena.NewArena()
    // Если нужен long-lived результат — копируем перед Free
    
    var tempDoc Document
    if err := json.Unmarshal(data, &tempDoc); err != nil {
        a.Free()
        return nil, err
    }
    
    // Копируем результат в обычную память
    result := &Document{
        Title:   tempDoc.Title,
        Content: tempDoc.Content,
    }
    
    a.Free() // все временные объекты парсинга освобождаются
    return result, nil
}

3. Графы и деревья с известным временем жизни

type Node struct {
    Value int
    Left  *Node
    Right *Node
}

func buildTree(values []int) *Node {
    a := arena.NewArena()
    defer a.Free()
    
    var build func([]int) *Node
    build = func(vals []int) *Node {
        if len(vals) == 0 {
            return nil
        }
        
        mid := len(vals) / 2
        node := arena.New[Node](a)
        node.Value = vals[mid]
        node.Left = build(vals[:mid])
        node.Right = build(vals[mid+1:])
        return node
    }
    
    return build(values)
}

4. Игровые движки и симуляции

type GameWorld struct {
    arena *arena.Arena
    entities []Entity
}

func NewGameWorld() *GameWorld {
    a := arena.NewArena()
    return &GameWorld{arena: a}
}

func (w *GameWorld) AddEntity(x, y float64) {
    e := arena.New[Entity](w.arena)
    e.X = x
    e.Y = y
    w.entities = append(w.entities, *e)
}

func (w *GameWorld) Reset() {
    w.arena.Free() // все сущности удалены разом
    w.arena = arena.NewArena()
    w.entities = nil
}

5. Высокочастотная торговля (HFT)

type OrderBook struct {
    arena *arena.Arena
    orders []Order
}

func NewOrderBook() *OrderBook {
    return &OrderBook{
        arena: arena.NewArena(),
    }
}

func (ob *OrderBook) AddOrder(price, qty float64) {
    o := arena.New[Order](ob.arena)
    o.Price = price
    o.Quantity = qty
    ob.orders = append(ob.orders, *o)
}

func (ob *OrderBook) Clear() {
    ob.arena.Free()
    ob.arena = arena.NewArena()
    ob.orders = nil
}

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

// 1. Нельзя использовать объекты после Free()
a := arena.NewArena()
p := arena.New[Point](a)
a.Free()
// p теперь невалиден — use-after-free!

// 2. Нельзя хранить ссылки на арену в долгоживущих объектах
type Cache struct {
    data *arena.Arena // опасно!
}

// 3. Арены не совместимы с GC для отдельных объектов
// Нельзя освободить один объект — только всю арену

Когда арены дают выигрыш

Сценарий	Выигрыш
Много мелких аллокаций с одинаковым временем жизни	Значительный
Частые аллокации/освобождения в горячем цикле	Значительный
Редкие аллокации	Минимальный
Объекты с разным временем жизни	Нет

Бенчмарк: арена vs обычная аллокация

func BenchmarkArena(b *testing.B) {
    for i := 0; i < b.N; i++ {
        a := arena.NewArena()
        defer a.Free()
        
        for j := 0; j < 1000; j++ {
            p := arena.New[Point](a)
            p.X = float64(j)
            p.Y = float64(j)
        }
    }
}

func BenchmarkHeap(b *testing.B) {
    for i := 0; i < b.N; i++ {
        points := make([]*Point, 0, 1000)
        for j := 0; j < 1000; j++ {
            p := &Point{X: float64(j), Y: float64(j)}
            points = append(points, p)
        }
        // GC должен собрать все эти объекты
    }
}

Ключевые выводы

Арены полезны для групп объектов с одинаковым временем жизни.
Основные области: парсинг, обработка запросов, игры, HFT.
Арены не заменяют GC — они дополнение для специфических случаев.
В обычном бизнес-коде обычно не нужны — Go GC достаточно эффективен.
Экспериментальный API — может измениться в будущих версиях Go.
Главный риск: use-after-free при неаккуратном использовании.

Вопрос 1. Кандидат рассказывает о себе и профессиональном опыте работы.​

Вопрос 2. Что будет выведено в программе с указателями и функцией в Go?​

Вопрос 3. Как исправить код, чтобы вывелась 5?​

Вопрос 4. Что такое слайс в Go и как он устроен внутренне?​

Вопрос 5. Как работает append и почему используется коэффициент роста слайса?​

Вопрос 6. Как работает добавление элементов (append) в слайс и почему используется коэффициент роста?​

Вопрос 7. Какие абстракции памяти используются в Go для избежания фрагментации?​

Вопрос 8. Как устроена мапа в Go и какие методы разрешения коллизий существуют?​

Вопрос 9. Какие методы открытой адресации существуют помимо линейного пробинга?​

Вопрос 10. Как происходит эвакуация бакетов в мапе Go и при каких операциях?​

Вопрос 11. Для чего нужен контекст в Go и что обычно в него кладут?​

Вопрос 12. Что такое структурированное логирование и какие пакеты используются в Go?​

Вопрос 13. Для чего нужны интерфейсы в Go?​

Вопрос 14. Как реализовываны принципы ООП (инкапсуляция, абстракция, наследование, полиморфизм) в Go?​

Вопрос 15. Почему в Go до версии 1.22 переменная в цикле for переиспользовалась на каждой итерации?​

Вопрос 16. Что выведет программа с горутинами и циклом for без синхронизации?​

Вопрос 17. Как устроена модель GMP в Go и зачем горутины вместо системных потоков?​

Вопрос 18. Какие проблемы в коде с горутинами и общим ресурсом, как решить?​

Вопрос 19. В чём разница между atomic и mutex, как работает CompareAndSwap?​

Вопрос 20. Будет ли влиять исчерпание файловых дескрипторов на горутины?​

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

Вопрос 22. Можно ли вынести чтение переменной из-под мьютекса для оптимизации?​

Вопрос 23. Напишите Worker Pool с использованием каналов в Go​

Вопрос 24. Чем отличается context.TODO() от context.Background()?​

Вопрос 25. Как правильно реализовать Worker Pool на каналах в Go?​

Вопрос 26. Как реализовать неблокирующий метод Schedule в Worker Pool?​

Вопрос 27. Как дождаться завершения всех задач и получить результаты в Worker Pool?​

Вопрос 28. Можно ли хранить контекст в поле структуры и как организовать отмену?​

Вопрос 29. Где на практике используются арены в Go?​

Вопрос 1. Кандидат рассказывает о себе и профессиональном опыте работы.

Вопрос 2. Что будет выведено в программе с указателями и функцией в Go?

Вопрос 3. Как исправить код, чтобы вывелась 5?

Вопрос 4. Что такое слайс в Go и как он устроен внутренне?

Вопрос 5. Как работает append и почему используется коэффициент роста слайса?

Вопрос 6. Как работает добавление элементов (append) в слайс и почему используется коэффициент роста?

Вопрос 7. Какие абстракции памяти используются в Go для избежания фрагментации?

Вопрос 8. Как устроена мапа в Go и какие методы разрешения коллизий существуют?

Вопрос 9. Какие методы открытой адресации существуют помимо линейного пробинга?

Вопрос 10. Как происходит эвакуация бакетов в мапе Go и при каких операциях?

Вопрос 11. Для чего нужен контекст в Go и что обычно в него кладут?

Вопрос 12. Что такое структурированное логирование и какие пакеты используются в Go?

Вопрос 13. Для чего нужны интерфейсы в Go?

Вопрос 14. Как реализовываны принципы ООП (инкапсуляция, абстракция, наследование, полиморфизм) в Go?

Вопрос 15. Почему в Go до версии 1.22 переменная в цикле for переиспользовалась на каждой итерации?

Вопрос 16. Что выведет программа с горутинами и циклом for без синхронизации?

Вопрос 17. Как устроена модель GMP в Go и зачем горутины вместо системных потоков?

Вопрос 18. Какие проблемы в коде с горутинами и общим ресурсом, как решить?

Вопрос 19. В чём разница между atomic и mutex, как работает CompareAndSwap?

Вопрос 20. Будет ли влиять исчерпание файловых дескрипторов на горутины?

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

Вопрос 22. Можно ли вынести чтение переменной из-под мьютекса для оптимизации?

Вопрос 23. Напишите Worker Pool с использованием каналов в Go

Вопрос 24. Чем отличается context.TODO() от context.Background()?

Вопрос 25. Как правильно реализовать Worker Pool на каналах в Go?

Вопрос 26. Как реализовать неблокирующий метод Schedule в Worker Pool?

Вопрос 27. Как дождаться завершения всех задач и получить результаты в Worker Pool?

Вопрос 28. Можно ли хранить контекст в поле структуры и как организовать отмену?

Вопрос 29. Где на практике используются арены в Go?