100 вопросов по Go на собеседовании с ответами

Короткий ответ: Массив ([N]T) содержит фиксированное число элементов; длина входит в его тип. Присваивание массива копирует элементы. Слайс ([]T) описывает окно в общем базовом массиве (backing array), поэтому присваивание слайса оставляет этот массив общим.

Подробно:

• Слайс удобно представлять как {указатель, len, cap}: указатель задаёт первый элемент, len — число видимых элементов, cap — насколько можно расширить слайс от этой позиции без нового массива.
• arr[1:3] включает индексы 1 и 2. Верхняя граница не включается. Для массива из пяти элементов длина такого слайса равна 2, ёмкость — 4.
• В стандартной реализации дескриптор занимает три машинных слова: обычно 24 байта на 64-битной системе и 12 на 32-битной. Это деталь реализации, а не основание зашивать размер в код.

arr := [5]int{0, 1, 2, 3, 4}
s := arr[1:3] // [1 2], len=2, cap=4
copyOfArray := arr
alias := s
alias[0] = 9
fmt.Println(arr, copyOfArray, s)
// [0 9 2 3 4] [0 1 2 3 4] [9 2]

Важно: Копирование массива копирует элементы, но не объекты, на которые ссылаются элементы-указатели, мапы или слайсы. Размещение памяти массива и слайса зависит от escape analysis компилятора.

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

Короткий ответ: append возвращает слайс с добавленными элементами. Если len(s) + числоНовыхЭлементов <= cap(s), используется прежний базовый массив. Иначе выделяется больший массив и в него копируются существующие элементы. Всегда используйте возвращённый слайс.

Подробно:

1. Запас ёмкости может вызвать алиасинг: append через подслайс способен перезаписать элементы, видимые через другой слайс.
2. Рост зависит от общего числа добавляемых элементов, а не только от условия len < cap перед вызовом.
3. Язык не обещает определённый коэффициент роста. Результат зависит от версии компилятора/рантайма и классов размеров аллокатора; рассчитывать на удвоение нельзя.

a := []int{1, 2, 3}
b := a[:2]
b = append(b, 9)
fmt.Println(a) // [1 2 9]: общий массив

c := a[:2:2]  // len=2, cap=2
c = append(c, 8)
fmt.Println(a, c) // [1 2 9] [1 2 8]: для c новый массив

Важно: s[:k:k] не позволяет добавлению новых элементов перезаписать хвост исходного массива. Это не копия: запись в существующий элемент, например c[0] до такого append, всё ещё изменит a[0].

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

Короткий ответ: Используйте slices.Clone(src) (Go 1.21+) или скопируйте элементы в отдельный слайс назначения. Простое присваивание копирует дескриптор слайса и оставляет базовый массив общим.

src := []int{1, 2, 3}

// Три независимых варианта:
a := slices.Clone(src) // import "slices"
b := make([]int, len(src))
n := copy(b, src)      // n == 3
c := append([]int(nil), src...)

_ = n
_ = c
a[0] = 9
fmt.Println(src, a, b) // [1 2 3] [9 2 3] [1 2 3]

Подробно: copy записывает min(len(dst), len(src)) элементов. Назначением может быть готовый слайс или срез массива; именно make не обязателен. Одной ёмкости недостаточно: у make([]int, 0, len(src)) нет элементов, в которые copy может записать данные.

Все варианты дают поверхностную копию. У [][]int, []map[string]int или структур с указателями вложенные объекты остаются общими. Их тоже нужно копировать, если контракт владения требует полной независимости.

Важно: Full slice expression только ограничивает ёмкость и не копирует элементы. slices.Clone сохраняет nil-состояние, а append([]T(nil), empty...) вернёт nil даже для ненулевого пустого источника.

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

Короткий ответ: Пустой слайс означает len(s) == 0; он может быть nil или не-nil и иметь запас ёмкости. Именно nil-слайс имеет len == 0, cap == 0 и s == nil.

Подробно: range делает ноль итераций во всех трёх случаях; append работает для всех. Индексация s[0] паникует при нулевой длине независимо от ёмкости. Проверяйте len(s) == 0, если нужно узнать, есть ли элементы; s == nil отвечает на другой вопрос.

Где это важно: Для обычного слайса целых чисел encoding/json.Marshal выдаёт null для nil и [] для пустого не-nil слайса. Теги полей вроде omitempty могут исключить оба варианта, а у []byte особая кодировка строкой base64. Если API обещает массив, перед кодированием обеспечьте не-nil слайс.

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

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

Подробно:

• Запись s[i] или m[key] меняет общие данные, поэтому результат виден вызывающему коду.
• Переприсваивание параметра меняет только локальную переменную. Это относится и к замене мапы, и к изменению длины слайса через append, даже без выделения памяти.
• Если длина меняется, верните обновлённый слайс и присвойте его результату у вызывающей стороны.

func grow(s []int) []int {
    return append(s, 99)
}
func set(s []int) {
    s[0] = 7
}
func replace(m map[string]int) {
    m = make(map[string]int) // только локальная переменная мапы
    m["x"] = 1
}

func main() {
    a := []int{1, 2}
    set(a)
    a = grow(a)
    m := map[string]int{}
    replace(m)
    fmt.Println(a, len(m)) // [7 2 99] 0
}

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

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

Короткий ответ: new(T) создаёт переменную типа T с нулевым значением и возвращает *T. make инициализирует слайс, мапу или канал и возвращает сам этот тип. Ни одна форма не гарантирует размещение в куче.

Подробно: Nil-слайс уже пригоден для len, range и append. Nil-мапа допускает чтение, но не вставку; nil-канал не может передавать значения. make даёт инициализированное хранилище для нужных операций.

Go 1.26+: new также принимает выражение-значение: p := new(42) создаёт *int, инициализированный числом 42. Прежняя форма new(int) по-прежнему создаёт ноль. Новый синтаксис требует версии языка Go 1.26+.

Важно: p := new(map[string]int); (*p)["x"] = 1 паникует, потому что мапа всё ещё nil. Для вставки записей используйте литерал мапы или make(map[string]int).

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

Короткий ответ: У всех перечисленных zero value — nil, но ведут они себя по-разному. С nil-слайсом можно работать (len, append), из nil-мапы можно читать, но не писать, nil-канал блокируется навсегда, разыменование nil-указателя паникует, а вызов метода на nil-интерфейсе паникует.

Подробно:

1. Слайс — nil; len, range, append работают. Самый «дружелюбный» nil.
2. Мапа — nil; чтение отдаёт zero value, запись паникует.
3. Канал — nil; отправка и приём блокируются навсегда (используется осознанно, чтобы «выключить» ветку в select).
4. Указатель — nil; разыменование *p → panic: nil pointer dereference.
5. Интерфейс — nil; сравнение с nil ок, вызов метода паникует.

⚠️ Частая ошибка: валить всё в кучу «nil есть nil». Ключевой нюанс — nil-мапа читается, но не пишется, а отправка и приём на nil-канале блокируются, но close(nilChannel) паникует. Индексация nil-слайса тоже паникует: append возвращает пригодный слайс, но не делает s[0] допустимым до появления элемента.

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

Короткий ответ: Чтение из nil-мапы безопасно — возвращается zero value типа значения, а в comma-ok форме ok == false. Запись в nil-мапу паникует: panic: assignment to entry in nil map.

Подробно:

1. Чтение — v := m[k] вернёт zero value, v, ok := m[k] даст ok == false. Итерация по nil-мапе — ноль проходов, тоже без паники.
2. Запись — m[k] = v в nil-мапе вызывает панику. Мапу надо сначала инициализировать: m := make(map[K]V) или литералом map[K]V{}.
3. Контраст со слайсом — в nil-слайс append работает и возвращает новый слайс, а в nil-мапу писать напрямую нельзя.

var m map[string]int // nil-мапа

n := m["x"]      // 0, паники нет
n, ok := m["x"]  // 0, false
for range m {}   // 0 итераций

m["x"] = 1       // panic: assignment to entry in nil map

⚠️ Частая ошибка: объявить var m map[string]int и сразу писать в неё. Читается как рабочий код, но падает в рантайме — сначала инициализируйте мапу. delete(m, key) и len(m) тоже безопасны для nil-мапы с допустимым ключом.

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

Короткий ответ: Ключом может быть любой comparable-тип — тот, для которого определён оператор ==. Слайсы, мапы и функции несравнимы (для них == не определён, только сравнение с nil), поэтому ключами быть не могут. Структуры и массивы годятся, если все их поля/элементы тоже comparable.

Подробно:

1. Можно — числа, строки, bool, указатели, каналы, интерфейсы, а также структуры и массивы из comparable-полей.
2. Нельзя — слайс, мапа, функция: у них нет ==, только проверка на nil.
3. Почему — ключ надо уметь хешировать и сравнивать на равенство; для слайса равенство неоднозначно (по указателю? поэлементно?), поэтому язык его запрещает.

⚠️ Частая ошибка: взять interface{} (или any) ключом и положить туда слайс. Компилируется, но паникует в рантайме: panic: runtime error: hash of unhashable type.

Пример: Координату можно представить ключом [2]int{x, y}, потому что массив целых чисел сравним. []int{x, y} ключом быть не может. Для интерфейсного ключа динамическое значение тоже должно быть сравнимым, в том числе значения интерфейсных полей структуры-ключа.

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

Короткий ответ: Выражение индексации мапы неадресуемо, поэтому &m[key] запрещено. Это правило языка позволяет реализации перемещать записи при росте, не обещая каждой записи постоянный адрес.

Два полезных приёма:

type Counter struct{ N int }
m := map[string]Counter{"a": {}}

// m["a"].N++   // нельзя: структура-значение неадресуема
// _ = &m["a"] // нельзя взять адрес записи
v := m["a"]
v.N++
m["a"] = v     // заменить значение целиком

mp := map[string]*Counter{"a": {}}
mp["a"].N++    // меняет отдельно хранящийся Counter

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

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

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

Короткий ответ: Язык не задаёт порядок обхода мапы; он не обязан меняться при каждом обходе и не является равномерной случайной перестановкой. Рандомизация рантайма сделана намеренно: при каждом range рантайм выбирает случайную стартовую позицию. Так язык не даёт коду завязываться на порядок, который всё равно не гарантирован (рост может менять физическое расположение).

Подробно:

1. Сделано специально — иначе разработчики начали бы неявно полагаться на «стабильный» порядок, а он поменялся бы при смене версии Go или размера мапы.
2. Порядок и так не определён — вставка не сохраняет очерёдность; рост может переместить элементы.
3. Нужен стабильный порядок — соберите ключи в слайс и отсортируйте.

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

⚠️ Частая ошибка: писать тест, который ждёт конкретный порядок range. Он может упасть в другом запуске или версии рантайма. Речь об обходе: некоторые пакеты форматирования и сериализации специально сортируют ключи мапы. Сортируйте ключи или сравнивайте как множество.

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

Короткий ответ: Мапа — хеш-таблица, но бакеты и эвакуация описывают старую реализацию. В Go 1.24 появились Swiss Tables. Сначала назовите версию Go, затем объясните хеширование, коллизии и рост именно для неё.

Современная схема, появившаяся в Go 1.24:

1. Ключ хешируется; группа содержит восемь слотов ключ/значение и управляющее слово. Управляющие байты хранят состояние слотов и семибитный фрагмент хеша, отбирая кандидатов перед полным сравнением ключей.
2. Коллизии разрешаются пробированием других групп, а не цепочками overflow-бакетов.
3. Мапа может состоять из нескольких таблиц. При необходимости растёт или разделяется отдельная таблица, поэтому одна вставка не перестраивает всю большую мапу. В этой схеме у таблицы не более 1 024 слотов.
4. Обычная таблица заполняется примерно до 7/8 (87,5%); у маленькой мапы из одной группы есть особый режим. Эти числа — детали рантайма, не гарантии языка.

Историческая схема, до Go 1.24: Бакет содержал восемь пар и ссылку на overflow-бакеты. При примерно 6,5 элемента на бакет (около 81% заполнения) число бакетов обычно удваивалось, а эвакуация шла постепенно. Избыток overflow мог также вызвать рост без увеличения числа бакетов.

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

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

Короткий ответ: Конкурентные записи в одну мапу без синхронизации — гонка данных, даже если ключи разные. Рантайм может обнаружить пересекающиеся операции и завершить процесс с fatal error: concurrent map writes; обнаружение не гарантировано в каждом запуске.

Подробно:

• Чтение одновременно с записью тоже требует синхронизации. Параллельные чтения безопасны, если ни одна горутина не меняет мапу.
• Фатальная ошибка рантайма не перехватывается через recover. Отсутствие падения в конкретном запуске не доказывает корректность программы.
• Защищайте все обращения одним мьютексом или передайте владение мапой одной горутине. sync.Map — специализированная альтернатива, а не универсальное исправление.

m := make(map[int]int)
var mu sync.Mutex
var wg sync.WaitGroup
for i := 0; i < 8; i++ {
    wg.Add(1)
    go func(i int) {
        defer wg.Done()
        mu.Lock()
        m[i] = i
        mu.Unlock()
    }(i)
}
wg.Wait() // до этого чтения все писатели завершились
fmt.Println(len(m)) // 8

Проверка: Запускайте подходящие тесты с go test -race. Детектор находит гонки в выполненных сценариях, но не доказывает их отсутствие во всех возможных запусках.

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

Короткий ответ: len("привет") равно 12: len считает байты. utf8.RuneCountInString("привет") равно 6: функция считает кодовые точки Unicode (руны). Один видимый символ может состоять из нескольких рун, поэтому сначала уточните смысл слова «символ».

Подробно:

1. Строка Go — неизменяемая последовательность байтов; она не обязана содержать корректный UTF-8. Исходный текст и обычные строковые литералы без escape-последовательностей записываются в UTF-8.
2. s[i] возвращает байт. range декодирует руны и возвращает байтовое смещение начала каждой руны.
3. utf8.RuneCountInString считает руны без создания слайса рун. len([]rune(s)) даёт то же число; реальное выделение памяти при преобразовании зависит от оптимизаций компилятора.
4. Комбинируемый знак или составной emoji могут образовывать один видимый символ. Подсчёт рун — не подсчёт графем. Некорректные байты UTF-8 учитываются как руны замены; для проверки корректности есть utf8.ValidString.

s := "привет"
fmt.Println(len(s), utf8.RuneCountInString(s)) // 12 6
for i, r := range s {
    fmt.Printf("%d:%c ", i, r)
}
// 0:п 2:р 4:и 6:в 8:е 10:т
fmt.Println(utf8.RuneCountInString("e\u0301")) // 2: e + акцент

Важно: Строки неизменяемы, а байтовый срез вроде s[:1] может разрезать последовательность UTF-8. Выбирайте единицу по задаче: байты для байтовых протоколов, руны для кодовых точек, графемы для редактирования видимого текста.

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

Короткий ответ: iota — это автоинкрементный счётчик внутри блока const: он равен 0 в первой спецификации констант блока и увеличивается на 1 с каждой следующей декларацией ConstSpec. Обнуляется в каждом новом блоке const. На нём строят enum-подобные наборы констант.

Подробно:

1. Базовый enum — перечисляем константы, iota подставляет 0, 1, 2… автоматически.
2. Пропуск значения — _ = iota пропускает 0 (часто чтобы zero value означал «не задано»).
3. Битовые флаги — 1 << iota даёт степени двойки для масок.

type Weekday int
const (
    Sunday Weekday = iota // 0
    Monday                // 1
    Tuesday               // 2
)

type Perm uint
const (
    Read  Perm = 1 << iota // 1
    Write                  // 2
    Exec                   // 4
)

const (
    _  = iota            // пропускаем 0
    KiB = 1 << (10 * iota) // 1024
    MiB                   // 1048576
)

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

Ограничение enum: Определённый целочисленный тип с константами не задаёт закрытое множество: Weekday(99) допустимо. Проверяйте внешние значения, если разрешены только именованные константы.

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

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

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

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

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

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

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

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

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

Короткий ответ: Pointer receiver (*T) может менять оригинал и не копирует структуру при вызове; value receiver (T) работает с копией. Для интерфейсов ключевое: method set у *T содержит и value-, и pointer-методы, а у T — только value-методы. Поэтому если метод объявлен на *T, значение типа T интерфейс не удовлетворяет.

Подробно:

1. Мутация — pointer-метод меняет получателя; присваивание полям value-получателя меняет только копию. Но скопированные поля-слайсы, мапы и указатели всё ещё позволяют менять общие вложенные объекты.
2. Копирование — value receiver копирует всю структуру на каждый вызов; для больших структур это может быть важно, хотя компилятор может оптимизировать копирование. Не копируйте значение с мьютексом после его первого использования.
3. Method set — определяет, что подходит под интерфейс:

Отсюда: если M объявлен на *T, то var _ I = T{} не скомпилируется — нужно var _ I = &T{}. При прямом вызове t.M() на адресуемой переменной Go сам берёт &t, но для удовлетворения интерфейса эта магия не работает.

⚠️ Частая ошибка: смешивать value- и pointer-ресиверы на одном типе, а потом удивляться, почему T{} не подходит под интерфейс. Единообразные ресиверы часто упрощают API, но смешивание допустимо; выбирайте по требованиям к мутациям, копированию и набору методов.

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

Короткий ответ: Встраивание (embedding) — включение типа в структуру без имени поля; его методы и поля продвигаются (promotion) на внешнюю структуру. Метод внешней структуры затеняет одноимённый встроенный. Если два встроенных типа несут метод с одним именем на одной глубине — селектор становится неоднозначным (ambiguous), и компилятор ругается при вызове без явного пути.

Подробно:

1. Promotion — a.Method() вызывает метод встроенного типа, если у внешнего своего нет.
2. Затенение (shadowing) — метод/поле внешнего уровня перекрывает встроенное; выигрывает ближайший по глубине.
3. Ambiguous selector — два кандидата на одной глубине → ошибка компиляции; разрешается явным путём a.Inner.Method().

type A struct{}
func (A) Hello() string { return "A" }

type B struct{}
func (B) Hello() string { return "B" }

type C struct{ A; B } // оба встроены на одной глубине

func main() {
    c := C{}
    // c.Hello()     // ошибка компиляции: ambiguous selector
    _ = c.A.Hello()  // "A" — явный путь
    _ = c.B.Hello()  // "B"
}

⚠️ Частая ошибка: ждать от embedding переопределения, как в ООП. Само встраивание не добавляет виртуальные вызовы: если метод с получателем a A вызывает a.Hello(), он позовёт именно A.Hello(), а не «переопределённый» на уровне C.

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

Короткий ответ: Используйте v, ok := x.(T) и проверяйте ok. При неудаче возвращаются нулевое значение T и false; одиночная форма x.(T) вместо этого паникует. Для нескольких ожидаемых типов подходит type switch.

var x any = "hello"
s, ok := x.(string)
fmt.Println(s, ok) // hello true
n, ok := x.(int)
fmt.Println(n, ok) // 0 false

switch v := x.(type) {
case string:
    fmt.Println("text:", v)
case int:
    fmt.Println("number:", v)
case nil:
    fmt.Println("nil interface")
default:
    fmt.Printf("unsupported type %T\n", v)
}

Подробно: Если T — конкретный тип, динамический тип должен быть идентичен T; assertion не преобразует значения между типами. Если T — интерфейс, динамический тип должен его реализовывать. Nil-интерфейс не проходит ни одно утверждение типа, а интерфейс с типизированным nil-указателем может успешно пройти assertion к этому типу указателя: результат nil, но ok == true.

Важно: После успешного assertion к указателю результат всё ещё может быть nil. Неудачный одиночный assertion вызывает панику; завершится ли весь процесс, зависит от recover на окружающей границе обработки.

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

Короткий ответ: Концептуально интерфейс — это пара (тип, значение), и он равен nil только когда обе части пусты. Если положить в него типизированный nil-указатель ((*MyErr)(nil)), часть «тип» заполнена, поэтому iface == nil даёт false, хотя данные внутри — nil.

Подробно:

1. Пара (тип, значение) — сравнение i == nil истинно, только если у интерфейса нет динамического типа и значения.
2. Типизированный nil — переменная var e *MyErr сама равна nil, но при возврате через error в интерфейс уезжает её тип *MyErr. Тип задан → интерфейс не nil.
3. Классический прод-баг — функция возвращает error, вызывающий пишет if err != nil, и ветка ошибки срабатывает на «успехе».

type MyErr struct{}
func (e *MyErr) Error() string { return "boom" }

func do() error {
    var e *MyErr = nil // типизированный nil
    return e           // уходит в интерфейс error вместе с типом
}

func main() {
    err := do()
    fmt.Println(err == nil) // false — ловушка!
}

чистый error(nil)         error с (*MyErr)(nil)
┌──────┬───────┐          ┌─────────┬─────────┐
│ type │ value │          │  *MyErr │   nil   │
│ nil  │  nil  │          │ (задан) │ (данные)│
└──────┴───────┘          └─────────┴─────────┘
    == nil ✔                    != nil ✘

⚠️ Частая ошибка: заводить переменную ошибки конкретного типа (var e *MyErr) и возвращать её из функции с сигнатурой error. Держите переменную как var err error или делайте return nil явно — типизированный nil-указатель не должен утекать в интерфейс.

Проверка: Вызов метода интерфейса с nil-указателем может успешно выполниться, если метод обрабатывает nil-получателя; сам интерфейс всё равно не nil. Это отличается от вызова метода nil-интерфейса.

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

Короткий ответ: В стандартном рантайме Go пустой интерфейс (any, псевдоним interface{}) представлен как eface: метаданные типа и слово данных. Интерфейс с методами — как iface: указатель на itab и слово данных. Это детали реализации; модель на уровне языка — динамический тип и значение.

any / eface               интерфейс с методами / iface
(type, data)              (itab, data)
   |                         |
 конкретный тип           тип интерфейса + конкретный тип
                          + адреса реализаций методов

Подробно:

• itab описывает соответствие конкретного типа определённому интерфейсу. Часть таблиц создаёт компилятор, остальные строит и кэширует рантайм.
• Слово данных представляет сохранённое значение. В зависимости от типа и решений компилятора оно может хранить значение-указатель напрямую или указывать на отдельно размещённые данные.
• Присваивание значения интерфейсу копирует это значение. Если оно содержит указатели, мапу или слайс, объекты по ссылкам могут остаться общими.
• Преобразование в интерфейс не обязательно выделяет память в куче. Стоимость зависит от escape analysis, девиртуализации и инлайнинга.

Важно: В обычном приложении не приводите интерфейс к самодельному заголовку рантайма. Используйте type assertion или рефлексию. Перед оптимизацией измерьте аллокации бенчмарком и изучите диагностику компилятора, например -gcflags=-m=2.

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

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

Подробно:

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

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

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

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

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

unbuffered := make(chan int)
go func() { unbuffered <- 7 }()
fmt.Println(<-unbuffered) // 7: встреча с отправителем

buffered := make(chan int, 1)
buffered <- 9            // получатель пока не нужен
fmt.Println(<-buffered)  // 9: освобождает слот

Подробно:

• make(chan T) имеет ёмкость ноль; make(chan T, N) — ёмкость N.
• Отправка через небуферизированный канал синхронизируется с приёмом значения. Это не означает, что получатель закончил обработку. Если важно завершение, нужен отдельный ответ-подтверждение.
• Буфер сглаживает ограниченные всплески. Если производитель постоянно быстрее потребителя, буфер заполнится и создаст обратное давление.
• У закрытого канала другие правила: приём забирает остаток буфера, затем возвращает ноль с ok == false; отправка паникует.

Важно: В одной горутине ch <- 1, а затем <-ch на небуферизированном канале не могут продвинуться: выполнение не дойдёт до приёма. Если других способных работать горутин нет, рантайм сообщает о deadlock. Используйте другую горутину или буфер, соответствующий протоколу обмена.

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

Короткий ответ: Отправка в закрытый канал вызывает панику. Чтение из закрытого канала сначала возвращает оставшиеся в буфере значения, а затем — нулевое значение типа с ok == false. Повторный close того же канала тоже паникует.

Подробно:

1. Send в закрытый — panic: send on closed channel. Поэтому канал закрывает горутина, которая владеет жизненным циклом отправки и знает, что новых значений точно не будет; главное — доказать завершение всех отправителей.
2. Receive из закрытого — буфер дренируется как обычно; когда он пуст, чтения мгновенно возвращают zero value и ok == false без блокировки.
3. Повторный close — panic: close of closed channel; двойной close — типичный симптом отсутствия единого владельца.
4. Close nil-канала — тоже паника (close of nil channel).

⚠️ Частая ошибка: считать, что чтение из закрытого канала блокируется. Наоборот — оно возвращается мгновенно, поэтому закрытый канал в select в цикле остаётся готовым на каждой итерации и может создать busy-loop. При ok == false выйдите или занулите переменную канала; другие готовые ветки тоже могут выбираться.

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

Короткий ответ: Через форму v, ok := <-ch: после закрытия и полного дренажа буфера ok становится false. Либо через for v := range ch — цикл сам завершается, когда канал закрыт и опустошён.

Подробно:

1. Comma-ok — v, ok := <-ch: для полученного значения, присланного отправителем, ok == true; открытый пустой канал блокируется, а не возвращает статус; после закрытия и опустошения v — нулевое значение типа, ok == false.
2. range — for v := range ch читает до закрытия и выходит без лишнего кода; идиоматичный способ для потребителя.
3. Зачем именно ok — отличить «прислали настоящий zero value» (например, 0 или "") от «канал закрыт» можно только по ok; само значение неотличимо.

// форма 1: comma-ok
v, ok := <-ch
if !ok {
    // канал закрыт и пуст
}

// форма 2: range — выходит после close и опустошения буфера
for v := range ch {
    process(v)
}

⚠️ Частая ошибка: проверять «канал закрыт?» сравнением значения с нулём (if v == 0). Настоящий 0, отправленный в канал, неотличим от zero value закрытого канала — единственный надёжный сигнал это ok.

Важно: Это приём, а не проверка «закрыт ли канал?» без побочных эффектов. Он может блокироваться или забрать значение и не защищает последующую отправку от конкурентного закрытия.

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

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

Подробно:

1. Получатель не должен закрывать канал данных, пока производители ещё могут отправлять: следующая отправка вызовет панику.
2. При нескольких отправителях нужно дождаться всех и выполнить единственный close. sync.WaitGroup — счётчик завершения: Add регистрирует работу до запуска, Done отмечает окончание, Wait ждёт нуля.
3. Закрытие не требуется, если получатель точно знает число ожидаемых значений или останавливается по отдельному сигналу отмены. Недостижимые каналы собирает GC; заблокированным горутинам всё равно нужен путь выхода.

out := make(chan int)
var wg sync.WaitGroup
for i := 0; i < 3; i++ {
    wg.Add(1)
    go func(i int) {
        defer wg.Done()
        out <- i
    }(i)
}
go func() {
    wg.Wait()
    close(out) // координатор знает, что все отправители закончили
}()
for v := range out {
    fmt.Println(v) // по одному 0, 1, 2; порядок не задан
}

Важно: Право закрытия определяется владением, а не названием горутины или тем, кто вызвал make. Если потребитель может уйти раньше, отправителям нужна отмена блокирующих отправок; один wait group их не разблокирует.

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

Короткий ответ: select делает равномерный псевдослучайный выбор среди операций обмена, которые могут выполниться. Порядок веток в коде не задаёт приоритет. Если ни одна не готова, он блокируется; при наличии default вместо этого сразу выполняется эта ветка.

select {
case value, ok := <-ch:
    if !ok {
        fmt.Println("channel closed and empty")
    } else {
        fmt.Println(value)
    }
default:
    fmt.Println("nothing available right now")
}

Подробно:

• default не конкурирует с готовыми каналами: она выполняется только при отсутствии готовой операции обмена.
• Случайный выбор убирает постоянный приоритет первой ветки, но не обещает round-robin или ограниченного ожидания каждой ветки.
• Ветка отмены <-ctx.Done() не имеет автоматического приоритета перед готовой работой.
• Если все каналы nil и нет default, select блокируется навсегда. Закрытый канал на приём остаётся готовым: при ok == false выйдите или отключите этот канал.

Важно: Цикл с default без блокирующей работы может крутиться и расходовать CPU. Для ожидания используйте блокирующий select. Для одного таймаута добавьте case <-time.After(d); создание нового таймера на каждой итерации начинает ожидание заново и может давать лишние аллокации.

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

Короткий ответ: И send, и receive на nil-канале блокируются навсегда. Это не баг, а инструмент: присвоив переменной канала nil, вы «выключаете» соответствующую ветку select — она перестаёт быть готовой и больше не выбирается.

Подробно:

1. Семантика nil-канала — <-nilCh и nilCh <- v блокируются вечно; close(nilCh) паникует.
2. Зачем это в select — закрытый канал в select готов мгновенно и в цикле «стреляет» zero value без конца. Чтобы отключить исчерпанный вход, его переменную зануляют — тогда ветка навсегда не готова.
3. Паттерн fan-in — сливаем два канала в один и по мере закрытия источников выключаем их ветки. В этом конечном примере оба источника должны закрыться, получатель — вычитать out, а эта функция — быть единственным отправителем и владельцем закрытия out.

for a != nil || b != nil {
    select {
    case v, ok := <-a:
        if !ok { a = nil; continue } // выключаем ветку a
        out <- v
    case v, ok := <-b:
        if !ok { b = nil; continue } // выключаем ветку b
        out <- v
    }
}
close(out)

⚠️ Частая ошибка: оставить закрытый канал в select как есть. Ветка case <-closedCh остаётся готовой и может создать busy-loop, но не получает приоритета над другими готовыми ветками. Если получатель может прекратить чтение раньше, защитите отправки out <- v отменой тоже.

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

Короткий ответ: До семантики языка Go 1.22 замыкания могли разделять переменную цикла и видеть её поздние значения; конкурентный доступ также мог создавать гонку. В Go 1.22 каждая итерация получает собственную переменную, если она объявлена самим циклом (:=). Переменные вне цикла остаются общими.

Версия важна: Проверяйте версию языка пакета, обычно выбранную строкой go в go.mod, а не только установленный компилятор. Изменение не делает общие мапы, слайсы или объекты по указателям безопасными и не гарантирует порядок вывода горутин.

// Работает при старой и новой семантике: передаём i аргументом.
var wg sync.WaitGroup
for i := 0; i < 3; i++ {
    wg.Add(1)
    go func(value int) {
        defer wg.Done()
        fmt.Println(value)
    }(i)
}
wg.Wait() // по одному 0, 1, 2, порядок не задан

Всё ещё общее в Go 1.22+: var i int; for i = 0; i < 3; i++ { ... } присваивает уже существующей переменной. Замыкания с этим i могут видеть поздние записи, если доступ не синхронизирован.

Важно: Старый ошибочный пример не гарантировал 3 3 3: результат зависел от планирования, и могла возникнуть гонка. Без ожидания возврат из main также мог завершить программу раньше любого вывода.

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

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

// process должна учитывать ctx при долгой работе и блокирующем I/O.
func worker(ctx context.Context, in <-chan Job) error {
    for {
        select {
        case <-ctx.Done():
            return ctx.Err()
        case job, ok := <-in:
            if !ok {
                return nil
            }
            if err := process(ctx, job); err != nil {
                return err
            }
        }
    }
}

Подробно: Создайте контекст через context.WithCancel, вызовите возвращённую функцию отмены, когда владелец закончил, и передавайте контекст через всю операцию. Для отдельного канала done один владелец закрывает его, сообщая об отмене всем. Канал завершения, wait group или группа с передачей ошибок позволяют убедиться, что работа действительно остановилась.

Внешний select не прервёт вызов process, который игнорирует отмену. Потенциально блокирующим отправкам тоже нужен select с ctx.Done(). Готовая ветка работы может выиграть одновременно с отменой; отмена кооперативная и не гарантирует приоритет планирования.

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

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

Короткий ответ: Утечка горутины — работа, которая пережила свой ожидаемый жизненный цикл и не имеет действенного пути завершения. Она может зависнуть на отправке, приёме, блокировке или I/O либо продолжать цикл после ухода владельца. Её стек и объекты по ссылкам остаются живыми.

Как найти: Сравните число горутин при сопоставимой нагрузке, затем повторно снимите goroutine-профили: ищите стеки, оставшиеся после завершения соответствующих запросов. runtime.NumGoroutine() — сигнал, не доказательство: обычная нагрузка тоже меняет число горутин. Профиль runtime/pprof показывает места ожидания; диагностические endpoint должны быть доступны через предназначенный для диагностики путь доступа.

// Протокол одного результата: expensive должна завершаться.
func result() <-chan int {
    ch := make(chan int, 1)
    go func() { ch <- expensive() }()
    return ch
}

Почему здесь помогает буфер: Есть ровно одна отправка и один свободный слот, поэтому горутина завершится, даже если вызывающий код перестал ждать. Закрытие для такого протокола одного результата не нужно. Буфер не отменяет expensive, не решает проблему повторных отправок и не помогает, если само вычисление никогда не возвращает управление.

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

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

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

func runTask(task func()) (err error) {
    defer func() {
        if value := recover(); value != nil {
            err = fmt.Errorf("task panicked: %v", value)
        }
    }()
    task()
    return nil
}

Подробно: Этот helper задаёт осознанную границу задачи. Вызывающий код получает ошибку и может записать её, сообщить о сбое задачи и решить, безопасно ли продолжать. При необходимости снимите диагностический стек внутри recovery через debug.Stack(). Если helper запускают в горутине, ошибку всё равно нужно передать владельцу и дождаться завершения.

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

Важно: Recovery относится только к текущему стеку. Если task запустит другую горутину, её панику этот helper не поймает. Аналогично recovery стандартного HTTP-сервера не покрывает горутины, запущенные хендлером. Фатальные ошибки рантайма, например обнаруженная конкурентная запись в мапу, не являются перехватываемыми паниками.

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

Короткий ответ: net/http может вызывать один хендлер конкурентно, поэтому общее изменяемое состояние требует синхронизации. «Одно соединение» не равно «один запрос»: HTTP/1 keep-alive переиспользует соединение, а HTTP/2 может одновременно обслуживать несколько потоков запросов в одном соединении.

Подробно:

• Server.Serve запускает служебную горутину на принятое соединение. В HTTP/1 запросы одного соединения обычно обслуживаются последовательно, а разные соединения — конкурентно. В HTTP/2 хендлеры потоков запускаются независимо.
• Общим мапе, кэшу или счётчику нужна согласованная синхронизация чтений и записей. Доступ к мапе без неё — гонка, способная вызвать фатальную ошибку рантайма.
• Контекст серверного запроса отменяется при закрытии клиентского соединения, отмене HTTP/2-запроса или возврате из ServeHTTP. Дедлайн есть только если он задан контексту; таймауты чтения/записи сокета не становятся автоматически дедлайном контекста.
• Передавайте r.Context() в БД и вызовы внешних сервисов. ResponseWriter нельзя использовать после возврата из ServeHTTP; завершайте работу с ответом до возврата.

var (
    mu sync.Mutex
    visits = make(map[string]int)
)
func count(w http.ResponseWriter, r *http.Request) {
    mu.Lock()
    visits[r.URL.Path]++
    n := visits[r.URL.Path]
    mu.Unlock()
    fmt.Fprintf(w, "visits: %d\n", n)
}

Важно: Защищать только записи недостаточно, если другие хендлеры конкурентно читают ту же мапу. Не держите её мьютекс во время медленного вывода ответа или сетевого I/O.

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

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

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

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

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

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

Короткий ответ: Mutex нельзя копировать после первого использования. Копии — разные замки; при копировании структуры обе копии могут указывать на одну map, но защищать её разными mutex. Для такого состояния используй pointer receiver.

type Cache struct {
    mu sync.Mutex
    values map[string]int
}

func (c *Cache) Put(key string, value int) {
    c.mu.Lock()
    defer c.mu.Unlock()
    c.values[key] = value
}
// При создании: values: make(map[string]int).

Если Put объявлен с (c Cache), каждый вызов копирует замок и дескриптор map. Конкурентные вызовы меняют общее хранилище под независимыми замками — это настоящая data race. Структура только с целочисленным счётчиком может просто менять отброшенную копию: обновление теряется даже без конкурентности.

Анализатор copylocks в go vet отмечает подозрительные присваивания, аргументы, возвраты и value receiver типов с замками. Он консервативен и не доказывает наличие гонки. Нетронутый нулевой mutex можно скопировать до использования, но работа со всей структурой через указатель предотвращает случайные последующие копии.

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

Короткий ответ: WaitGroup ждёт завершения зарегистрированных задач. В ручном варианте вызови Add до запуска горутины и отложи Done внутри задачи. Иначе Wait может увидеть ноль и вернуться до регистрации задачи.

var wg sync.WaitGroup
for _, job := range jobs {
    wg.Add(1)
    go func(job Job) {
        defer wg.Done()
        process(job)
    }(job)
}
wg.Wait()

Контекст примера: Job, jobs и process обозначают тип задачи, входную коллекцию и обработчик приложения. Нужен импорт sync.

Go 1.25+: wg.Go(func() { task() }) объединяет регистрацию, запуск и завершение задачи. Переданная функция не должна паниковать. Если счётчик пуст, вызови Go до Wait. Ручной вариант по-прежнему корректен на новых версиях.

WaitGroup не отменяет работу и не возвращает ошибки задач. Для ошибок нужен явный канал или группа с их обработкой. Не копируй использованный WaitGroup, не уменьшай счётчик ниже нуля и не начинай новую независимую группу задач до возврата предыдущих Wait.

Частая ошибка: Пропущенный Done при раннем возврате оставляет Wait заблокированным. Необработанная паника обычно завершает процесс; WaitGroup не является механизмом обработки паник.

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

Короткий ответ: Один экземпляр sync.Once вызывает функцию из первого Do не более одного раза. Конкурентные вызовы ждут завершения этой функции; после этого результат инициализации безопасно виден вызывающим горутинам.

var once sync.Once
var config string

func Config() string {
    once.Do(func() { config = "production" })
    return config
}

Границы гарантии: Это один раз на экземпляр, а не на всю программу. Если f паникует, Do всё равно считает вызов завершённым и не повторяет его. Рекурсивный Do на том же экземпляре вызывает deadlock. После использования экземпляр нельзя копировать.

В Go 1.21+ OnceValue сохраняет одно возвращаемое значение, а OnceValues — два, например (Config, error). Ошибка тоже сохраняется: для повторных попыток нужен другой механизм. В отличие от Once.Do, функция, возвращённая OnceFunc/OnceValue, повторяет ту же панику при следующих вызовах, если инициализация паниковала.

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

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

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

// Типизированные атомики доступны с Go 1.19.
var completed atomic.Int64
completed.Add(1)
fmt.Println(completed.Load())

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

Атомарные операции ведут себя как единый последовательно согласованный порядок, но несколько атомарных переменных не образуют согласованный снимок автоматически. Готовый неизменяемый снимок можно публиковать через atomic.Pointer или atomic.Value; после публикации его содержимое нельзя менять.

Частая ошибка: Называть несогласованную комбинацию атомарных значений гонкой данных. Программа может не иметь data race и всё равно нарушать бизнес-инвариант. Сначала определи инвариант, затем выбери и измерь синхронизацию.

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

Короткий ответ: sync.Map предоставляет конкурентные операции с map и особенно подходит для записей «записал один раз, читаю много» или горутин с непересекающимися ключами. Обычно стоит начать с типизированной map и mutex: так явно видны типы и составные инварианты.

Гарантии API: Нулевое значение готово к работе. Отдельные операции безопасны конкурентно; последовательность Load, затем Store не является атомарным обновлением. Используй LoadOrStore или CompareAndSwap, если их контракт подходит задаче. Range не гарантирует согласованный снимок.

Версия важна: Старая реализация использовала read-only и dirty map. В Go 1.24 её заменили конкурентным hash-trie, поэтому прежние объяснения promotion, прогрева и обязательно медленных записей устарели. Внутреннее устройство не является контрактом API.

Пример: Кэш неизменяемых после вставки записей может подойти для sync.Map. Если запись надо обновить вместе с общим размером кэша, обычно нужен один замок вокруг обеих операций. Ключи и значения типа any также требуют проверки типов на границе API. Сравнивай производительность на своей нагрузке.

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

Короткий ответ: Контекст переносит отмену, дедлайн и значения запроса между вызовами. WithCancel добавляет ручную отмену, WithDeadline — абсолютный дедлайн, WithTimeout — длительность от текущего момента. Отмена родителя отменяет производные контексты.

ctx, cancel := context.WithTimeout(parent, 2*time.Second)
defer cancel()
return fetch(ctx)

Эффективный дедлайн не может продлить более ранний дедлайн родителя. Вызывай возвращённый cancel после завершения операции, чтобы быстро освободить ресурсы, даже если таймер позже сработает сам. Повторная отмена безопасна.

Отмена кооперативная: Закрытие ctx.Done() сигнализирует о необходимости остановиться, но не убивает горутину, не прерывает произвольный код и не ждёт завершения. Передавай ctx в поддерживающие его I/O-вызовы и проверяй в длительных циклах. Для ожидания завершения нужен WaitGroup или другой сигнал.

ctx.Err() различает context.Canceled и context.DeadlineExceeded. Если в select готовы результат и отмена, может быть выбран любой вариант: приоритета отмены нет. Обрабатывающая функция тоже должна учитывать контекст; одного select при отправке результата недостаточно.

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

Короткий ответ: Оба возвращают ненулевой контекст без дедлайна, значений и сигнала отмены (Done() равен nil). Background обозначает осознанный корень, TODO — место, где правильный родитель ещё не определён.

Используй Background() в корне, которым владеет приложение, например в main, а затем создай отменяемый контекст для завершения работы. TODO() временно подходит для API, через который контекст ещё не проведён.

В HTTP-обработчике используй r.Context(). Замена на любой корневой контекст теряет отмену клиента и дедлайн запроса. Одинаковое пустое поведение не делает эти корни заменой контексту вызывающего кода; не полагайся на их внутренние типы или равенство.

Проверь понимание: Должен ли запрос к базе продолжаться после отключения клиента? Для работы, принадлежащей запросу, передай входящий контекст в QueryContext; новый Background скроет отмену.

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

Короткий ответ: Первый параметр ctx context.Context явно задаёт время жизни и отмену каждого вызова. Долгоживущий сервис должен получать контекст текущего вызывающего кода для каждой операции, а не повторно использовать контекст создавшего его запроса.

type Store interface {
    Get(context.Context, string) (string, error)
}
type Service struct { store Store }

func (s *Service) Fetch(ctx context.Context, id string) (string, error) {
    return s.store.Get(ctx, id)
}

Пример сбоя: Сервис сохраняет контекст запроса A в поле. После таймаута A запрос B использует тот же отменённый контекст и сразу завершается ошибкой. Храни зависимости в сервисе, а контекст передавай на каждый вызов.

Это важное соглашение API, а не запрет языка. Некоторые существующие API, например http.Request, хранят контекст ради совместимости и владения в рамках запроса. Осознанное исключение требует ясного времени жизни. Контекст может также описывать завершение приложения или фоновую задачу; он не ограничен HTTP-запросами.

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

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

type traceKey struct{}

func WithTraceID(ctx context.Context, id string) context.Context {
    return context.WithValue(ctx, traceKey{}, id)
}

func TraceID(ctx context.Context) (string, bool) {
    id, ok := ctx.Value(traceKey{}).(string)
    return id, ok
}

Ключ должен быть сравнимым. Приватный тип ключа и типизированный accessor предотвращают случайные коллизии и небезопасные assertions; избегай общих строковых ключей. Неэкспортируемость ключа не универсальное требование: важен API без коллизий.

Пример: Middleware аутентификации может добавить проверенную личность пользователя; доменная функция LoadOrder(ctx, orderID) всё равно должна явно получать нужный заказ и проверять доступ. Значения контекста не делают изменяемые объекты автоматически безопасными для конкурентного использования.

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

Короткий ответ: Начни с инварианта и владения. Mutex подходит для связанных изменяемых полей, атомики — для простых независимых значений или публикации снимка, каналы — для координации и передачи владения, неизменяемые значения — для общего чтения после безопасной публикации.

Почему публикация важна: Если одна горутина строит read-only map и без синхронизации записывает указатель в глобальную переменную, пока другая читает её, это всё ещё гонка. Опубликуй данные до запуска читателей, через канал, под замком или атомарным указателем.

Канал отправляет копию значения, но не делает глубокую копию слайсов, map и объектов по указателю. Передачу владения обязан соблюдать код. Несколько атомарных полей могут не иметь data race по отдельности, но быть несогласованными вместе. Каналы и атомики не обязаны быть быстрее или идиоматичнее простого замка.

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

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

Запускай go test -race ./... для тестов или собирай сервис через go build -race и проверяй реалистичные сценарии. Отчёт показывает стеки конфликтующих обращений и места создания участвующих горутин.

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

Инструментация существенно расходует CPU и память; стоимость зависит от нагрузки. Используй тесты и контролируемые интеграционные или нагрузочные запуски. Инструментированный сервис под реалистичным трафиком полезен, если стоимость допустима. Поддержка платформ и нативного кода ограничена — сверяйся с документацией toolchain.

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

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

Короткий ответ: В стандартном рантайме Go G — горутина, M — поток ОС, P — ресурс рантайма, необходимый для исполнения Go-кода. Число P равно GOMAXPROCS; M должен получить P для обычного Go-кода. Это ограничивает параллельное исполнение, а не общее число горутин или потоков.

Проследим задачу: Готовая G ждёт в локальной или глобальной очереди. M с P выбирает работу. Если локальная очередь пуста, планировщик может взять глобальную работу, проверить I/O или забрать готовые горутины у другого P. Блокировка G на канале позволяет M/P исполнять другую G. Блокирующий системный вызов может занять M, пока рантайм передаёт его P другому потоку.

готовые G → локальные/глобальная очереди → M + P → Go-код
ожидающие G → готовность I/O или синхронизации → снова готовы

Граница гарантии: Размеры очередей, доли work stealing, периодические проверки и точный порядок — детали реализации. GOMAXPROCS=4 означает не более четырёх потоков с Go-кодом одновременно; это не обещает постоянную загрузку всех четырёх и не ограничивает потоки в syscall.

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

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

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

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

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

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

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

Короткий ответ: Современный Go сочетает кооперативные точки переключения с асинхронным вытеснением. В Go 1.14 добавили асинхронное вытеснение на поддерживаемых платформах: плотные циклы без вызовов функций перестали так легко монополизировать исполнение и задерживать GC.

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

Не обещай фиксированный квант: Вытеснение выполняется только там, где рантайм может безопасно остановить и просканировать горутину. Названия сигналов, интервалы монитора, пороги и поддержка платформ — детали реализации. Это не real-time планировщик с гарантией запуска каждой горутины за заданное число миллисекунд.

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

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

Короткий ответ: Блокирующий системный вызов может занять горутину и поток ОС. Рантайм способен передать или забрать P этого потока, чтобы другой поток исполнял Go-код. Короткий syscall может завершиться раньше, чем потребуется передача.

При возврате поток пытается получить P. Если свободного P нет, горутина становится готовой и ждёт планирования. Поэтому общее число потоков ОС может превышать GOMAXPROCS, когда много вызовов блокируются.

Сетевой I/O устроен иначе: Pollable-сокеты под управлением netpoller обычно паркуют горутину без отдельного ожидающего потока на каждое соединение. Поток выполняет другую работу, а готовность дескриптора возвращает горутину в очередь. Но не вся сетевая работа неблокирующая: DNS, cgo, неподдерживаемые дескрипторы и другие вызовы могут блокировать потоки.

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

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

Короткий ответ: Escape analysis помогает компилятору решить, может ли память остаться на стеке горутины или должна жить дольше в куче. Размещение — оптимизация, а не гарантия языка. Проверяй вывод компилятора для реального кода и версии.

func newNumber() *int {
    n := 42
    return &n
}

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

Используй go build -gcflags='-m=2' ./... для решений об escape и инлайнинге. Замыкания, динамический размер и преобразования в интерфейс могут приводить к аллокациям, но это не безусловные правила. Оптимизации меняются: например, Go 1.26 чаще оставляет небольшие backing array слайсов переменного размера на стеке.

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

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

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

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

runtime/debug.SetMaxStack задаёт предел роста одного стека. Документированное начальное ограничение — 1 ГБ на 64-битных системах и 250 МБ на 32-битных; возможны ограничения платформы. Превышение при росте аварийно завершает процесс: это не обычная паника, которую ловит recover.

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

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

Короткий ответ: Стандартный рантайм Go использует конкурентный трассирующий GC, который не перемещает объекты кучи. В трёхцветной модели белые объекты ещё не помечены, серые найдены, но не полностью просканированы, чёрные уже просканированы. После маркировки непомеченные объекты кучи можно освободить.

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

Помимо конкурентной работы есть stop-the-world фазы. Длительность пауз зависит от нагрузки и версии; паузы короче миллисекунды не гарантируются. Green Tea стал GC по умолчанию в Go 1.26 и изменил реализацию маркировки и сканирования, сохранив общую трассирующую модель.

Важное различие: Неперемещаемая куча не означает постоянство всех адресов. Стеки горутин могут перемещаться, а cgo имеет отдельные правила указателей и pinning. Нельзя разрешать произвольные Go-указатели в C только потому, что GC не двигает объекты кучи.

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

Короткий ответ: GOGC меняет баланс между запасом памяти для аллокаций и CPU сборщика. GOMEMLIMIT (Go 1.19+) просит рантайм удерживать управляемую память ниже мягкого лимита; это не предел RSS процесса и не защита от любого OOM.

Для современного Go полезна приближённая цель размера кучи:

целевая куча = живая куча + (живая куча + корни GC) × GOGC / 100

Сборщик стартует до достижения цели, чтобы успеть закончить. Поэтому GOGC=100 не означает буквально «начать, когда куча удвоилась». Меньшие значения обычно расходуют больше CPU ради меньшего запаса памяти; большие разрешают больше памяти между циклами.

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

GOGC=off отключает обычный триггер по росту кучи; настроенный лимит памяти всё ещё может запускать GC. Если к лимиту приближаются сами живые данные, GC не может их удалить. Рантайм может превысить мягкий лимит, чтобы не тратить почти весь CPU на сборку. Сначала исправляй удержание данных или объём нагрузки.

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

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

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

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

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

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

Короткий ответ: Sentinel (var ErrNotFound = errors.New(...)) — это простой опознаваемый сигнал без дополнительных данных, проверяется через errors.Is. Кастомный тип с полями нужен, когда вызывающему важны детали сбоя (код, имя поля, статус) — тогда errors.As извлекает ошибку и даёт доступ к её полям.

Подробно:

1. Sentinel — флаг — одно общее значение ошибки на весь пакет. Дёшево, читаемо, но несёт только сам факт: «не найдено», «нет прав». Проверка — errors.Is.
2. Кастомный тип — структура с данными — когда нужно передать контекст: ValidationError{Field, Rule}, APIError{Code}. Проверка и извлечение — errors.As.
3. Оба варианта — часть API — и то и другое становится публичным контрактом: вызывающие проверяют их по имени.

var ErrNotFound = errors.New("not found")

type ValidationError struct{ Field, Rule string }
func (e *ValidationError) Error() string { return e.Field + ": " + e.Rule }

⚠️ Частая ошибка: забывать, что sentinel — часть публичного API. Пользователи пишут errors.Is(err, pkg.ErrNotFound), поэтому переименование или удаление ломает их код так же, как смена сигнатуры функции.

Нюанс: Sentinel — общая переменная со значением error, а не константа Go. Пользовательский тип может поддерживать errors.Is через Unwrap или метод Is, поэтому подходы можно сочетать. При успехе возвращай именно nil: преобразование nil-указателя *ValidationError в error даёт ненулевой интерфейс.

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

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

Подробно:

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

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

⚠️ Частая ошибка: обрабатывать ошибку дважды — и залогировать, и вернуть её наверх. Обычно добавляй контекст при возврате и логируй на границе обработки; несколько слоёв могут дублировать один сбой. Дополнительный лог полезен, если содержит отдельную значимую информацию.

Проверка контракта: Обёрнутая ошибка зависимости становится видна вызывающему коду по своей идентичности. Делай это осознанно. Go 1.20+ поддерживает несколько %w и errors.Join, поэтому структура может быть деревом. errors.Is/As обходят его, а helper errors.Unwrap для одной ошибки не раскрывает результат Join.

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

Короткий ответ: errors.Is проверяет соответствие ошибки целевому условию. errors.As находит ошибку, присваиваемую нужному типу, и сохраняет её в переменную для чтения полей. Оба обходят обёрнутые ошибки, включая дерево от errors.Join (Go 1.20+).

if errors.Is(err, fs.ErrNotExist) {
    // Отсутствие файла распознаётся и после оборачивания.
}
var pathErr *fs.PathError
if errors.As(err, &pathErr) {
    fmt.Println(pathErr.Op, pathErr.Path)
}

Аргумент As — ненулевой указатель на подходящую переменную. Здесь pathErr уже указатель, поэтому &pathErr передаёт указатель на указатель, позволяя As заполнить переменную. Неверный target может вызвать панику.

Не только равенство: Is может вызывать метод ошибки Is(error) bool; As тоже поддерживает специальное сопоставление. Это не сравнение текста и не строгое совпадение конкретных типов. Go 1.26+ также предоставляет errors.AsType[T](err) для типизированного извлечения; As остаётся полезен для старого кода.

Прямое == допустимо, когда API гарантирует необёрнутый sentinel; если возможны обёртки, предпочитай Is. Не строй логику на тексте сообщения.

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

Короткий ответ: Отложенные вызовы выполняются в обратном порядке регистрации при возврате окружающей функции или раскрутке паники. Значение функции, receiver и аргументы вычисляются в момент выполнения defer; сам вызов происходит позже.

func example() {
    n := 1
    defer fmt.Println(n)                    // сохраняет 1 сейчас
    defer func() { fmt.Println(n) }()       // читает n позже
    n = 2
}
// Вывод: 2, затем 1, на отдельных строках.

В цикле defer fmt.Println(i) сохраняет аргумент текущей итерации при любой версии Go. Замыкание, читающее переменную цикла, устроено иначе: отдельные переменные итераций действуют при семантике языка Go 1.22+ и объявлении переменной самим циклом. Переменная вне цикла остаётся общей.

Время жизни ресурса: Defer внутри цикла выполняется при выходе из функции, а не из итерации. Если файл надо закрыть до открытия следующего, вынеси итерацию в helper или закрой явно. os.Exit не выполняет defer.

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

Короткий ответ: Defer может изменить именованную переменную результата до передачи вызывающему коду. При неименованном результате он не заменит уже вычисленное возвращаемое значение, но может менять объект, доступный через возвращённый указатель, слайс или map.

func named() (n int) {
    defer func() { n++ }()
    return 4 // сначала n = 4, затем defer меняет его на 5
}

func shared() []int {
    values := []int{4}
    defer func() { values[0]++ }()
    return values // вызывающий увидит []int{5}, результат не именован
}

Выражения return вычисляются и записываются в результат до выполнения defer. Если отложенное замыкание лишь присваивает новое значение локальному скаляру, оно не заменяет уже скопированный неименованный результат.

Практическое применение: Именованный err может сохранить ошибку закрытия ресурса, если она определяет успех операции. Не затирай прежнюю значимую ошибку. Преобразование паники в error тоже требует осознанной границы и именованного результата; это не обычный способ обработки ожидаемых ошибок.

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

Короткий ответ: recover() работает только при непосредственном вызове внутри отложенной функции той же горутины, где произошла паника. Вызванный вне defer или из функции, которую отложенная функция сама вызывает, он возвращает nil и ничего не перехватывает.

Подробно:

1. Только напрямую в defer — паника ловится, если recover() вызван прямо в теле функции, которую defer поставил на выполнение. Не в функции, которую эта отложенная функция вызвала.
2. Только своя горутина — паника в другой горутине твоим recover не перехватывается; каждая горутина ловит панику сама, иначе падает весь процесс.
3. Вне паники — nil — если паники нет, recover() просто вернёт nil, так что проверка if r := recover(); r != nil безопасна.

func catch() { _ = recover() }

defer func() { _ = recover() }() // работает
defer catch()                    // тоже работает: catch — сама отложенная функция
defer func() { catch() }()       // НЕ работает: recover на кадр глубже, вернёт nil

⚠️ Частая ошибка: вызвать хелпер с recover() изнутри deferred-замыкания — defer func(){ catch() }(). recover оказывается не в самой отложенной функции, а на кадр глубже и вернёт nil. А вот defer catch() работает: тут catch и есть отложенная функция.

После recover: Выполнение не продолжается на строке, вызвавшей панику. Функция, зарегистрировавшая восстанавливающий defer, возвращается после завершения отложенных вызовов. При стандартном поведении Go 1.21+ даже panic(nil) даёт ненулевое значение recover; старое поведение возвращает GODEBUG=panicnil=1. Аварийные ошибки рантайма и os.Exit не являются перехватываемыми паниками.

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

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

func receive(ctx context.Context, in <-chan int, d time.Duration) (int, error) {
    timer := time.NewTimer(d)
    defer timer.Stop()
    select {
    case value, ok := <-in:
        if !ok { return 0, io.EOF }
        return value, nil
    case <-timer.C:
        return 0, context.DeadlineExceeded
    case <-ctx.Done():
        return 0, ctx.Err()
    }
}

Если готовы несколько веток, select может выбрать любую: нет строгого правила «самое раннее событие выигрывает» или приоритета таймаута. Receive с ok различает закрытый вход и настоящий ноль.

Время жизни таймера: До семантики Go 1.23 недостижимый таймер time.After оставался выделенным до срабатывания. Современная семантика позволяет собирать недостижимые таймеры и ticker, но новая аллокация на каждой итерации горячего цикла всё ещё стоит ресурсов. В Go 1.23–1.26 это зависит от версии главного модуля и GODEBUG=asynctimerchan. Go 1.27 удаляет настройку: каналы таймеров всегда синхронные и действует современное поведение.

Реши, ограничен ли весь вызов или каждый интервал бездействия. Новый таймер на каждой итерации обновляет бюджет ожидания. Для общей длительности создай один таймер до цикла либо передавай контекст с дедлайном. Здесь таймер не переиспользуется, поэтому протокол остановки и очистки перед Reset не нужен.

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

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

func runBounded(parent context.Context, jobs []int, limit int,
    work func(context.Context, int) error,
) error {
    if limit < 1 { return fmt.Errorf("limit must be positive") }
    ctx, cancel := context.WithCancel(parent)
    defer cancel()
    sem := make(chan struct{}, limit)
    var wg sync.WaitGroup
    var once sync.Once
    var firstErr error
launch:
    for _, job := range jobs {
        if ctx.Err() != nil { break }
        select {
        case sem <- struct{}{}:
        case <-ctx.Done():
            break launch
        }
        wg.Add(1)
        go func(job int) {
            defer wg.Done()
            defer func() { <-sem }()
            if err := work(ctx, job); err != nil {
                once.Do(func() { firstErr = err; cancel() })
            }
        }(job)
    }
    wg.Wait()
    if firstErr != nil { return firstErr }
    return ctx.Err()
}

work должна учитывать контекст. Первая наблюдаемая ошибка отменяет группу, но функция ждёт все уже запущенные задачи. Отмена может совпасть с допуском задачи, поэтому допущенная задача всё равно должна проверить или передать контекст. Лимит ограничивает одновременную работу, а не запросы в секунду.

Готовая альтернатива: golang.org/x/sync/errgroup поддерживает SetLimit и WithContext. Group.Go может блокироваться в ожидании места; само это ожидание не является select по контексту. Производный контекст отменяется при первой ошибке или возврате Wait, в том числе успешном. После Wait для другой работы используй исходный родительский контекст и явно проверяй ошибки задач и родителя.

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

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

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

type Result struct {
    Value int
    Err   error
}

func pool(ctx context.Context, jobs <-chan int, n int,
    process func(context.Context, int) (int, error),
) (<-chan Result, error) {
    if n < 1 {
        return nil, fmt.Errorf("worker count must be positive")
    }
    out := make(chan Result)
    var wg sync.WaitGroup
    for i := 0; i < n; i++ {
        wg.Add(1)
        go func() {
            defer wg.Done()
            for {
                if ctx.Err() != nil { return }
                select {
                case <-ctx.Done():
                    return
                case job, ok := <-jobs:
                    if !ok { return }
                    value, err := process(ctx, job)
                    select {
                    case out <- Result{Value: value, Err: err}:
                    case <-ctx.Done():
                        return
                    }
                }
            }
        }()
    }
    go func() { wg.Wait(); close(out) }()
    return out, nil
}

Контракт владения: При штатном завершении производитель закрывает jobs, воркеры заканчивают очередь, вызывающий код читает out до конца. Если чтение прекращается раньше, надо отменить общий контекст; производитель также должен проверять его при отправке. process должна быстро возвращаться при отмене и не оставлять свою работу запущенной.

Нельзя писать case out <- process(job) и ожидать, что select прервёт обработку: значение отправки вычисляется до выбора ветки. Отмена кооперативна и не имеет приоритета в select. Закрытие out подтверждает выход воркеров, если обработка соблюдает контракт отмены.

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

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

func merge[T any](ctx context.Context, inputs ...<-chan T) <-chan T {
    out := make(chan T)
    var wg sync.WaitGroup
    wg.Add(len(inputs))
    for _, input := range inputs {
        go func(input <-chan T) {
            defer wg.Done()
            for {
                if ctx.Err() != nil { return }
                select {
                case <-ctx.Done():
                    return
                case value, ok := <-input:
                    if !ok { return }
                    select {
                    case out <- value:
                    case <-ctx.Done():
                        return
                    }
                }
            }
        }(input)
    }
    go func() { wg.Wait(); close(out) }()
    return out
}

Обобщённый пример требует Go 1.18+: T задаёт один тип элементов для всех входов и выхода (например, merge[int]). Порядок внутри каждого входа сохраняется, но перемешивание разных входов не определено. При отсутствии входов выход закрывается без значений. Nil-вход ждёт отмены.

Раннее завершение: Если нужен только первый результат, потребитель должен отменить контекст. Отмена нужна и в receive, и в send: иначе пустой вход или непрочитанный выход оставит горутину заблокированной. Производители выше по цепочке должны соблюдать тот же контракт отмены либо иметь другой ограниченный путь выхода. Закрытие out означает завершение пересылающих горутин, но не обязательно всех производителей.

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

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

func square(ctx context.Context, in <-chan int) <-chan int {
    out := make(chan int)
    go func() {
        defer close(out)
        for {
            if ctx.Err() != nil { return }
            select {
            case <-ctx.Done():
                return
            case n, ok := <-in:
                if !ok { return }
                select {
                case out <- n * n:
                case <-ctx.Done():
                    return
                }
            }
        }
    }()
    return out
}

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

Если этап имеет несколько отправителей, выход закрывает один координатор после завершения всех отправок. Для длительного I/O передавай контекст и в саму операцию. Явно реши, отменяет ли ошибка весь pipeline или передаётся как результат, и дождись своих воркеров, если shutdown должен закончиться до возврата.

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

Короткий ответ: Семафор ограничивает операции в работе. Rate limiter ограничивает допуск операций во времени. Могут понадобиться оба: API разрешает 10 запросов в секунду, но только три одновременно.

Общий token bucket из golang.org/x/time/rate пополняется с заданной скоростью и разрешает ограниченный burst. rate.NewLimiter(10, 20) даёт 10 токенов в секунду и ёмкость всплеска 20; сначала bucket заполнен. Wait(ctx) ждёт разрешения и возвращает ошибку, если не может дождаться с учётом отмены или дедлайна. Проверяй ошибку до запуска запроса. Allow() сразу отвечает да или нет.

Вариант с ticker: Общий time.Ticker подходит для простого ритма. Он не обещает ровно N запросов в секунду: задержки планирования и медленные потребители могут приводить к пропуску тиков. Ожидай с select по отмене и останавливай ticker при завершении владельца. Политика всплесков отличается от token bucket.

Частая ошибка: Создать каждому воркеру отдельный limiter для общей квоты API. Десять воркеров по 10 запросов в секунду могут суммарно допустить около 100. Размещай общий limiter в области действия реальной квоты.

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

Короткий ответ: map[key]*list.Element поверх двусвязного списка (container/list): map даёт доступ за O(1), список хранит порядок использования. На Get двигаем элемент в голову, на Put при переполнении вытесняем хвост. Потокобезопасность — sync.Mutex вокруг обеих структур.

Подробно:

1. Две структуры — map[K]*list.Element для поиска за O(1) и *list.List (двусвязный) для порядка «свежести».
2. Get — нашли в map → MoveToFront(el) → вернули значение.
3. Put — ключ есть → обновить и MoveToFront; нет → PushFront, а при Len() > capacity удалить Back() и его ключ из map.
4. Потокобезопасность — один Lock() на всю операцию (map и список меняются вместе); при высоком contention — шардирование по хешу ключа.

map[key]                двусвязный список (MRU ⇄ LRU)
┌──────┐   ┌──────┐   ┌──────┐   ┌──────┐
│ "a" ─┼──►│  a   │⇄  │  c   │⇄  │  b   │
│ "c" ─┼──►└──────┘   └──────┘   └──────┘
│ "b" ─┼──►  head=MRU            tail=вытесняем
└──────┘

⚠️ Частая ошибка: RWMutex с RLock на Get. Get двигает элемент в списке — это запись, а не чтение; под RLock две горутины повредят список. Get требует полного Lock.

Определи границы: Реши, означает ли нулевая ёмкость «ничего не хранить» или ошибку; обновляй существующие ключи без роста размера; удаляй элемент и запись индекса под одним замком. Шардирование создаёт несколько независимых LRU и теряет единый глобальный порядок вытеснения. Если значения — изменяемые указатели, замок кэша сам по себе не защищает вызывающий код после возврата Get.

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

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

Проверяй пути остановки в send, receive и работе между ними. Буфер канала не исправляет неограниченную проблему времени жизни.

Запускай go test -race для выполненных путей и go vet для подозрительного кода. Они находят не всё; утечка в живом сервере может никогда не вызвать сообщение о глобальном deadlock. Исправляй конкретный контракт, а не добавляй blanket recover, произвольные буферы и лишние close.

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

Короткий ответ: go.mod объявляет модуль и его требования. go.sum хранит хеши содержимого для проверки загруженных файлов модулей. Minimal Version Selection выбирает наибольшую из требуемых минимальных версий для каждого пути модуля в графе, а не автоматически самый новый релиз.

приложение требует A и B
A требует lib v1.4.0
B требует lib v1.3.0
выбрана lib v1.4.0, даже если существует v1.9.0

Директива go задаёт версию языка и минимальные требования Go; toolchain может направлять выбор toolchain. На зависимости также влияют replace, exclude, workspaces и явные команды обновления, поэтому проверяй фактический список через go list -m all.

go.sum — не lock-файл: он может хранить хеши невыбранных версий и не определяет граф. База контрольных сумм добавляет проверку публичных модулей; настройки приватных могут обходить её. Целостность подтверждает идентичность содержимого, а не отсутствие уязвимостей.

Проверь понимание: Сам выход lib v1.9.0 не обновит сборку, которая выбирает v1.4.0. Выбор изменится при изменении требований или явном обновлении.

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

Короткий ответ: Go 1.18+ позволяет функциям и типам принимать параметры типов с ограничениями. Constraint определяет допустимые типы и операции. comparable разрешает равенство, неравенство и использование ключом map; any не даёт такого требования для произвольного параметра типа.

func Index[T comparable](values []T, target T) int {
    for i, value := range values {
        if value == target { return i }
    }
    return -1
}

Index([]int{3, 5}, 5) выводит T как int и возвращает 1. Ограничение int | float64 разрешает ровно эти типы; ~int | ~float64 также разрешает определённые типы с соответствующим underlying type.

Нюанс интерфейсов (Go 1.20+): Обычный интерфейс, например any, может удовлетворять comparable. Но сравнение интерфейсов паникует, если их динамические значения несравнимы. Например, Index[any]([]any{[]int{1}}, []int{1}) компилируется, но паникует при сравнении слайсов внутри интерфейсов. Статический constraint не обещает сравнимость любого динамического значения.

Используй generics, когда связь конкретных типов делает API полезнее. Обычный интерфейс подходит для общего поведения. Не обещай, что generics всегда исключают boxing или runtime-расходы: машинный код и производительность зависят от реализации и использования.

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

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

func TestTrimSpace(t *testing.T) {
    cases := []struct { name, in, want string }{
        {"empty", "", ""},
        {"unchanged", "Go", "Go"},
        {"surrounding space", "  Go  ", "Go"},
    }
    for _, tc := range cases {
        t.Run(tc.name, func(t *testing.T) {
            if got := strings.TrimSpace(tc.in); got != tc.want {
                t.Errorf("TrimSpace(%q) = %q, want %q", tc.in, got, tc.want)
            }
        })
    }
}

Размести пример в _test.go, импортируй strings и testing. Именованные подтесты помогают найти сбой и выбрать сценарий через go test -run. Для своей функции включай успех, пустые и граничные входы, ожидаемые ошибки; проверяй результаты и идентичность ошибок, а не только вызывай функцию.

Параллельность необязательна: Используй t.Parallel() только с независимыми фикстурами и изменяемым состоянием. При семантике Go 1.22+ переменные самого цикла отдельные для каждой итерации; для старого языка и долгоживущих замыканий нужна локальная копия. Освобождай ресурсы через cleanup и выполняй fatal-assertions в горутине соответствующего теста.

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

Короткий ответ: Внедряй зависимость через небольшой интерфейс или функцию там, где нужна заменяемая граница. Тест передаёт fake с управляемыми результатами и ошибками, не меняя глобальные переменные или машинный код.

type Store interface {
    Name(context.Context, string) (string, error)
}

type fakeStore struct { name string; err error }
func (f fakeStore) Name(context.Context, string) (string, error) {
    return f.name, f.err
}

func greeting(ctx context.Context, store Store, id string) (string, error) {
    name, err := store.Name(ctx, id)
    if err != nil { return "", fmt.Errorf("load name: %w", err) }
    return "Hello, " + name, nil
}

func TestGreetingFailure(t *testing.T) {
    want := errors.New("store unavailable")
    got, err := greeting(context.Background(), fakeStore{err: want}, "42")
    if got != "" || !errors.Is(err, want) {
        t.Fatalf("got (%q, %v), want empty result and %v", got, err, want)
    }
}

Fake и тест размещаются в _test.go; интерфейс и поведение — рядом с потребителем. Нужны context, errors, fmt и testing. Тест проверяет настоящий контракт: ошибка не даёт успешного приветствия и сохраняет исходную причину.

Добавь успешный сценарий и проверку значимых аргументов или отмены, если это важно. Fake не доказывает работу настоящей базы или HTTP, поэтому границе нужны целевые интеграционные тесты. Не создавай огромный интерфейс только ради mocking: параметр-функция или простая реальная реализация могут быть понятнее. Проверки случайного порядка вызовов делают тесты хрупкими.

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

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

Запускай go vet ./... и проверяй контекст каждого сообщения. Vet использует эвристики: сообщение не всегда доказывает достижимый сбой, а чистый вывод не исключает гонки, deadlock, утечки или ошибки бизнес-логики.

go test по умолчанию запускает выбранное подмножество vet; явный go vet выполняет более широкий проход. Дополнительные линтеры полезны, если проект их настроил, но конкретный агрегатор не обязателен. Для конкурентности сочетай тесты под -race с анализом владения и отмены.

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

Короткий ответ: Размести func BenchmarkX(b *testing.B) в _test.go и запускай go test -run='^$' -bench=. -benchmem. Вывод показывает ns/op, выделенные байты на операцию (B/op) и аллокации на операцию (allocs/op); это не пиковая память и не удерживаемая куча.

func BenchmarkJoin(b *testing.B) {
    parts := []string{"go", "build", "test"}
    b.ReportAllocs()
    for b.Loop() {
        strings.Join(parts, "/")
    }
}

Пример импортирует strings и testing, требует Go 1.24+. Точная форма for b.Loop() управляет временем вокруг setup/cleanup и по документированным правилам защищает измеряемые вызовы и результаты от удаления оптимизатором. Это не полный запрет любых оптимизаций компилятора.

На старых версиях используй for i := 0; i < b.N; i++, сбрось таймер после setup и обеспечь наблюдаемость результата, если компилятор может удалить работу. В одном бенчмарке используй либо b.Loop, либо b.N.

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

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

Короткий ответ: Сними профиль под симптом и исследуй его через go tool pprof. CPU-сэмплы показывают дорогое исполнение, heap/allocations — память, стеки горутин — зависшую работу, block/mutex — ожидания и конкуренцию за замки.

import _ "net/http/pprof" регистрирует handlers на http.DefaultServeMux, но не запускает сервер и не добавляет их в пользовательский mux. Выдели диагностике ограниченный listener либо отдельный mux с явной регистрацией. Не открывай endpoints случайно через публичный default mux.

Локальная CPU-выборка: go tool pprof http://127.0.0.1:6060/debug/pprof/profile?seconds=30. Тесты записывают профили через go test -cpuprofile=cpu.out или -memprofile=mem.out. Для block и mutex нужны runtime.SetBlockProfileRate и runtime.SetMutexProfileFraction.

В Go 1.27+ также стабилен профиль goroutineleak (в Go 1.26 он экспериментальный). Анализ достижимости находит часть навсегда заблокированных горутин, но не все утечки. Измеряй реалистичную нагрузку и сравнивай до/после; одного роста числа горутин недостаточно для доказательства утечки.

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

Короткий ответ: Оркестрация — явный координатор (state machine) ведёт сагу и вызывает шаги; хореография — сервисы реагируют на события друг друга без центра. Оба варианта дают только eventual consistency и требуют компенсирующих транзакций — выбор лишь о том, где жить сложности: в явном оркестраторе или в неявном потоке событий.

Подробно:

1. Оркестрация — явные статусы, deadlines и ретраи легче наблюдать. Координатор должен сохранять состояние и восстанавливаться; он может реплицироваться и отвечать за отдельный workflow, не собирая все бизнес-потоки в одном сервисе.
2. Хореография — сервисы деплоятся независимо; цена — поток нигде не записан: новый шаг = «подписаться туда-то», и через год никто не знает всю цепочку.

⚠️ Частая ошибка: подавать хореографию как «более правильную из-за слабой связанности». Связность не исчезает — она переезжает из кода в неявный граф событий, который дороже отлаживать.

Короткий ответ: Компенсирующие транзакции выполняются в обратном порядке: вернуть деньги → отменить заказ. Каждая компенсация обязана быть идемпотентной и ретраибельной; заказ до конца саги живёт в статусе PENDING (semantic lock) и не виден как подтверждённый; компенсация, которая сама не проходит, уходит в ретраи + алерт + очередь ручного разбора — молча бросить её нельзя.

Подробно:

create order (PENDING) ──► charge payment ──► reserve stock ✗ FAIL
                                                     │
  cancel order (PENDING→CANCELLED) ◄── refund payment ◄──┘

1. Компенсируем выполненные эффекты — при достоверном отказе резерва возвращаем деньги и отменяем заказ. После timeout результат резерва неизвестен: проверяем/сверяем его и идемпотентно снимаем успешный резерв до завершения очистки.
2. Semantic lock — другие команды должны учитывать PENDING, например запрещать отгрузку. Статус не скрывает и не откатывает атомарно уже видимые в других сервисах эффекты.
3. Идемпотентная компенсация — стабильный ключ операции возврата, например refund:paymentId:reasonId, отдельный от ключа списания; после timeout повторяем и сверяем ту же операцию.
4. Компенсация не проходит — платёжный шлюз лежит: ретраи с backoff, после N попыток — алерт и запись в очередь ручного разбора. Деньги клиента нельзя потерять в логах.

⚠️ Частая ошибка: считать компенсацию «откатом транзакции». Это обычная бизнес-операция: она может упасть, задублироваться и должна проектироваться так же тщательно, как прямой шаг.

Короткий ответ: Проблему dual write: коммит в БД и publish в брокер — две разные системы, атомарности между ними нет. Упади сервис между ними — событие потеряно (или наоборот: событие улетело, а записи нет). Outbox: событие пишется в таблицу аутбокса в той же локальной транзакции, что и бизнес-данные, а отдельный relay публикует его в брокер.

Подробно:

┌──── одна локальная транзакция ────┐
│ INSERT INTO orders …              │
│ INSERT INTO outbox (event) …      │
└───────────────────────────────────┘
   outbox ──► relay (поллер или CDC/Debezium) ──► брокер

1. Атомарность бесплатно — обе записи в одной БД: либо есть и заказ, и событие, либо ничего.
2. Relay — поллер (SELECT … FOR UPDATE SKIP LOCKED) или CDC: Debezium читает WAL — события уезжают без нагрузки поллинга.
3. Следствие: at-least-once — relay может упасть после publish, но до отметки «отправлено» → событие уедет дважды. Значит, на другой стороне обязан стоять идемпотентный консюмер с дедупликацией.

⚠️ Частая ошибка: «опубликуем до коммита — тогда точно не потеряем». Это лишь переворачивает сбой: коммит упал, а событие уже улетело — фантомное событие о заказе, которого не существует.

Короткий ответ: Консюмер держит таблицу обработанных message id с UNIQUE-ограничением и вставляет id в одной локальной транзакции с бизнес-эффектом. Повторная доставка упирается в constraint — сообщение просто пропускается, эффект не задваивается. Два ключевых условия: id стабилен между ретраями, а дедупликация атомарна с эффектом.

Подробно:

BEGIN;
INSERT INTO processed_messages (message_id) VALUES ($1);
-- дубль → unique_violation → ROLLBACK, сообщение ack'аем
UPDATE accounts SET balance = balance - 100 WHERE id = $2;
COMMIT;

1. Одна транзакция — если проверять «обработано?» отдельно от эффекта, между проверкой и записью влезает гонка двух консюмеров или ретраев.
2. Стабильный id — его генерирует продюсер (id события из аутбокса), а не брокер при доставке: ретрай обязан прийти с тем же id.
3. TTL/чистка — таблица растёт: чистим по времени, но окно хранения должно перекрывать максимальную задержку редоставки (ретраи, DLQ).
4. Эффект вне БД — HTTP-вызов этим паттерном не защищается: нужен ключ идемпотентности уже на стороне вызываемого API.

⚠️ Частая ошибка: дедуплицировать в Redis или в памяти рядом с транзакцией в Postgres — «отметка» и эффект снова расходятся; это тот же dual write в профиль.

Срок дедупликации должен учитывать исторический replay и ручной DLQ redrive. Если они выходят за окно, сохраняйте долговечный бизнес-идентификатор/constraint или задайте политику replay без повторного эффекта.

Короткий ответ: Координатор рассылает prepare (каждый участник голосует и держит локи), затем commit. Протокол блокирующий: упади координатор между фазами — участники зависают in-doubt с удержанными локами и не могут ни закоммитить, ни откатиться. Плюс латентность по самому медленному участнику и нетерпимость к партишенам — поэтому в микросервисах вместо 2PC живут сага и Outbox.

Подробно:

координатор:  prepare? ──► A: yes   B: yes
              💥 crash до рассылки commit
A, B:         in-doubt — локи держатся, строки заблокированы;
              сами решить не могут: вдруг координатор уже
              успел записать commit

1. Фаза 1 (prepare) — участники пишут redo/undo, голосуют и держат локи до развязки.
2. Решение — NO или timeout на prepare позволяют координатору выбрать ABORT до долговечного решения COMMIT. Уже prepared-участник не может безопасно откатиться лишь по своему таймеру: нужно восстановить итоговое решение.
3. Цена — синхронное ожидание всех участников: латентность = самый медленный; блокировка при отказе координатора; при сетевом партишене протокол просто стоит.
4. Где встречается — XA-транзакции внутри одного JVM/СУБД-мира существуют, но между сервисами с разными БД и брокерами — почти никогда.

⚠️ Частая ошибка: предлагать 2PC как «честную» альтернативу саге. 2PC покупает атомарность ценой доступности и живучести — в распределённой системе эта цена обычно неприемлема.

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

• At-most-once допускает потерю и избегает повторной доставки в своих границах.
• At-least-once допускает повторы; итоговая доставка зависит от долговечного хранения, успешных ретраев и модели сбоев.
• Exactly-once effects объединяют replay с атомарной дедупликацией либо транзакцией, охватывающей прогресс и результат.

Kafka-транзакция атомарно фиксирует выходные записи и consumed offsets. Read_committed скрывает отменённый результат. После сбоя код обработки может выполняться снова, хотя зафиксированный Kafka-результат виден один раз.

Эффект в PostgreSQL требует inbox-идентичности и своей транзакции; HTTP-эффект — контракта идемпотентности принимающего API. Pub/Sub также документирует exactly-once delivery для определённых подписок и условий, поэтому «exactly-once доставки никогда не бывает» слишком категорично.

⚠️ Ловушка: гарантия заканчивается на своей границе. Kafka-транзакция не откатит списание, письмо или commit другой БД.

Короткий ответ: Три классики: TTL истёк, пока держатель ещё работает (GC-пауза, медленный I/O) — лок берёт второй, и держателей уже двое; release удаляет чужой лок; failover Redis теряет лок из-за асинхронной репликации. Поэтому value — уникальный токен держателя, release — только атомарный check-and-delete на Lua, а для строгой корректности одного Redis-лока мало.

Подробно:

t=0   A: SET lock tokenA NX PX 10000 → OK, работает
t=10  TTL истёк (A завис в GC / ждёт диск) — A не знает
t=11  B: SET lock tokenB NX → OK — держателей ДВОЕ
t=12  A очнулся и дописал в общий ресурс → конфликт
t=13  A: DEL lock → снёс уже ЧУЖОЙ лок B (DEL без проверки)

1. Уникальный токен — value = случайный uuid держателя; release сравнивает и удаляет атомарно (Lua: if GET == token then DEL), иначе A сносит лок B.
2. TTL — всегда компромисс — короткий: истекает под живым держателем; длинный: после падения держателя все ждут впустую.
3. Failover — репликация асинхронна: мастер упал до реплицирования SET — новый мастер про лок не знает, его возьмут второй раз.

⚠️ Частая ошибка: «взять лок» и считать взаимное исключение гарантированным. Redis-лок с TTL — это lease: он может истечь под тобой, и без fencing token защищаемый ресурс этого даже не заметит.

Короткий ответ: Безопасность Redlock опирается на тайминговые допущения — ограниченный дрейф часов и ограниченные паузы процессов, — которые реальные системы нарушают (stop-the-world GC, page fault, сетевые задержки). Зависший держатель с «истёкшим» локом всё равно пишет в ресурс. Лечит fencing token: монотонно растущий номер, который проверяет сам ресурс и отбрасывает записи устаревших держателей.

Подробно:

A берёт лок (token 33) ──► GC stop-the-world 15 c
        TTL истёк; B берёт лок (token 34) и пишет
A очнулся, «всё ещё держит лок», пишет
  без fencing:  запись A затирает запись B  💥
  с fencing:    хранилище видит 33 < 34 → reject A

1. Суть критики — лок «по таймеру» без общего источника порядка не может быть безопасным: длительность паузы процесса и дрейф часов ничем не ограничены, а изнутри пауза невидима.
2. Fencing token — ресурс атомарно помнит наибольший принятый токен. Например: UPDATE resource SET value=$1, last_token=$2 WHERE id=$3 AND last_token <= $2, где last_token инициализирован и NOT NULL. Меньший входящий токен отклоняется после принятия нового. Равные токены допускают несколько записей одной аренды; дубли бизнес-операций всё ещё требуют идемпотентности.
3. Что выбрать — корректность критична: лок на консенсусе вместе с fencing на защищаемом ресурсе (например, revision ключа лока etcd атомарно проверяется хранилищем). Сам сервис локов не остановит запись устаревшего процесса во внешний ресурс. Лок «для эффективности» (не делать работу дважды, дубль не страшен) — одиночный Redis ок.

⚠️ Частая ошибка: тюнить TTL Redlock «с запасом» вместо fencing. Никакой TTL не спасает от паузы неизвестной длины — без проверки на стороне ресурса гарантии нет.

Короткий ответ: PostgreSQL advisory locks подходят согласованно работающим клиентам одной БД. Transaction-level lock живёт до завершения транзакции; клиентский TTL аренды не нужен.

BEGIN;
SELECT pg_advisory_xact_lock(42);
-- Читать и менять защищаемые данные в ЭТОЙ транзакции/соединении.
COMMIT;

Все участники должны одинаково вычислять ключ и брать lock: advisory lock не запрещает посторонний SQL автоматически. Если ждать нельзя, используйте pg_try_advisory_xact_lock. Transaction-scoped lock совместим с transaction pooling; session locks нельзя оставлять между клиентами пула.

При сбое соединения PostgreSQL отменяет транзакцию и освобождает locks после обнаружения сбоя. Partition обнаруживается не мгновенно: нужны подходящие таймауты соединений/deadlines; избегайте долгих открытых транзакций со старыми snapshots.

⚠️ Ловушка: защита относится к сотрудничающей работе в одной DB-транзакции, а не произвольным HTTP-эффектам или независимым кластерам. После потери DB-соединения процесс может продолжать внешний вызов; ему всё ещё нужна собственная идемпотентность или fencing.

Короткий ответ: Линеаризуемость: каждая операция как будто атомарно происходит в некоторый момент между её началом и концом — все видят единую временную шкалу. Нужна для балансов, проверок уникальности, лидер-элекшена. Eventual: реплики сойдутся «когда-нибудь». Read-your-writes поверх реплик: читать данные автора с праймари (session stickiness) либо отслеживать LSN/логический таймстемп записи и ждать, пока реплика его догонит.

Подробно:

1. Чтение primary — после записи направляйте сессию к действующему primary. Фиксированные N секунд — эвристика без предела replica lag; для read-your-writes переключайтесь после проверенного catch-up.
2. Позиция прогресса — после успешного commit сохраните WAL-позицию primary не раньше этого commit. Читайте на совместимом standby после достижения её pg_last_wal_replay_lsn, с deadline/fallback к primary. pg_current_wal_lsn до commit недостаточно; failover и смена timeline требуют отдельного контроля.
3. Кворум — R + W > N даёт пересечение при допущениях, но само не доказывает линеаризуемость. Используйте документированный протокол линеаризуемого чтения, а не вывод из числа голосов.

⚠️ Частая ошибка: смешивать модели консистентности с уровнями изоляции БД. Изоляция (read committed, serializable) — про конкурентные транзакции на одном узле; консистентность (линеаризуемость, eventual) — про реплики и распределённость. Это разные оси.

Короткий ответ: Event sourcing: первичен журнал событий; текущее состояние выводится как state = fold(events). CQRS: модель записи и модели чтения разделены. Дают полный аудит, temporal queries («как выглядел заказ вчера»), пересборку проекций с нуля. Цена высокая: версионирование событий, снапшоты, возможное отставание read-проекций, дорогой тулинг. Это не архитектура по умолчанию.

Подробно:

events:  OrderCreated → ItemAdded → ItemAdded → OrderPaid
state  = fold(events)   — всегда выводимо заново
проекции: «заказы за день», «топ товаров» — свои read-модели,
          можно пересобрать из журнала с нуля

1. Когда оправдано — движение денег, леджеры, домены с жёстким аудитом и комплаенсом; «почему баланс стал таким» — вопрос бизнеса, а не логов.
2. Цена №1: версионирование — событие живёт вечно; изменилась схема — читать все старые версии (upcasters) или мигрировать журнал целиком.
3. Цена №2: чтение — при асинхронном обновлении read-моделей проекция может отставать после команды; UI, тесты и саппорт должны учитывать такую модель согласованности.
4. CQRS без ES — легитимен и сильно дешевле: обычная БД записи + денормализованные проекции для чтения.

⚠️ Частая ошибка: предлагать event sourcing для CRUD-приложения «на вырост». Если аудит — не бизнес-требование, вы платите всю цену ES и не получаете ничего, что не дала бы таблица плюс журнал изменений.

Журнал первичен, но реализации могут хранить snapshots и материализованное состояние. CQRS разделяет модели чтения и записи: отдельные БД не обязательны, а отставание асинхронных проекций — выбор реализации, не требование любого CQRS.

Короткий ответ: Часы машин расходятся несмотря на NTP — дрейф, leap smearing, паузы VM дают от миллисекунд до секунд, — поэтому «больший таймстемп» ≠ «случилось позже». Last-write-wins по таким часам молча выбрасывает конкурентные записи: классический lost update между репликами, причём без единой ошибки в логах.

Подробно:

часы A отстают на 2 с
реально t=10.0  A: UPDATE profile   (свой ts = 8.0)
реально t=9.5   B: UPDATE profile   (свой ts = 9.5)
LWW: 9.5 > 8.0 → «побеждает» B,
хотя запись A физически была ПОЗЖЕ — и молча исчезла

1. Wall clock vs monotonic — wall clock прыгает (NTP умеет корректировать назад); интервалы меряют monotonic clock, но он не сравним между машинами. Общего «сейчас» нет.
2. Чем чинить — версии + optimistic locking (UPDATE … WHERE version = $1); монотонный sequence или fencing token от единственного писателя; vector clocks — концептуально, чтобы отличать конкурентность от порядка; проектировать операции коммутативными (increment вместо set, CRDT-мышление).
3. Где LWW терпим — телеметрия, кэши, поля, где «последний прав» — честная бизнес-семантика, а потеря записи не страшна.

⚠️ Частая ошибка: «настроим NTP поточнее — и норм». NTP уменьшает дрейф, но не ограничивает его гарантированно: без bounded-clock-инфраструктуры уровня TrueTime корректность на таймстемпах не строится.

Короткий ответ: Топик — набор партиций; партиция — append-only лог, порядок гарантирован только внутри неё. У каждой партиции есть лидер (обслуживает чтение и запись) и фолловеры-реплики; ISR — реплики, не отстающие от лидера. Стандарт долговечности: acks=all + min.insync.replicas=2 при replication.factor=3.

Подробно:

topic orders (RF=3)
p0: [0|1|2|3|4] ──► leader: broker1, ISR: {1,2,3}
p1: [0|1|2]     ──► leader: broker2, ISR: {2,3}
p2: [0|1|2|3]   ──► leader: broker3, ISR: {1,3}

1. acks=all — лидер отвечает продюсеру только после репликации записи на все реплики из ISR.
2. min.insync.replicas=2 — если живых ISR меньше двух, продюсер получает NotEnoughReplicas вместо тихой записи в единственную копию.
3. RF=3 — если все три реплики синхронны, потеря одной оставляет две для записи после выборов/восстановления. Краткие ошибки возможны; если ISR уже состоял из двух, ещё один отказ может остановить запись. Durability зависит и от election policy, сохранности реплик/диска, настроек ретраев продюсера.

⚠️ Частая ошибка: «Kafka гарантирует порядок сообщений». Только внутри одной партиции; глобального порядка в топике нет.

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

Подробно:

topic orders: p0  p1  p2  p3
group A (3 консюмера):
  c1 ◄─ p0, p1    c2 ◄─ p2    c3 ◄─ p3
group A (6 консюмеров):
  c1◄p0  c2◄p1  c3◄p2  c4◄p3   c5, c6 — idle
group B: читает те же партиции независимо (свои оффсеты)

1. Внутри группы — у назначенной партиции один consumer-владелец. Порядок обработки сохраняется лишь без переупорядочивания работы и commit за незавершённые записи.
2. Между группами — независимое чтение: каждая группа коммитит свои оффсеты в __consumer_offsets, одни и те же данные обслуживают и биллинг, и аналитику.
3. Планирование — число партиций задаёт потолок масштабирования группы; закладывайте его с запасом при создании топика.

⚠️ Частая ошибка: «добавим консюмеров — станет быстрее». После числа партиций добавленные консюмеры просто простаивают.

Здесь описаны обычные consumer groups Kafka; share groups имеют другие assignment/ack semantics. Один владелец партиции сохраняет порядок чтения лога, но worker pool приложения всё ещё может переупорядочить завершение и эффекты.

Короткий ответ: Ребалансировка — перераспределение партиций внутри группы. Триггеры: консюмер вошёл/вышел/упал, истёк session.timeout.ms, превышен max.poll.interval.ms (медленная обработка в poll-цикле — классический самострел), изменилась подписка или число партиций. Опасна тем, что eager-протокол останавливает всю группу.

Подробно:

1. Eager (классика) — stop-the-world: все консюмеры отзывают все партиции, обработка группы замирает до конца ребаланса.
2. Cooperative / incremental (KIP-429) — CooperativeStickyAssignor: отзываются только перемещаемые партиции, остальные продолжают работать.
3. Static membership — group.instance.id может избежать лишнего перераспределения, если тот же участник вернулся до истечения сессии с совместимым assignment. Все rebalance не исчезают. Classic eager/cooperative assignors и новый consumer group protocol Kafka настраиваются по-разному.
4. Шторм ребалансов — тяжёлая работа внутри poll-цикла: превысили max.poll.interval.ms → консюмер «объявлен мёртвым» → ребаланс → партиции переехали → новый консюмер тоже не успевает → цикл повторяется.

session.timeout.ms=45000
max.poll.interval.ms=300000
group.instance.id=payments-1
partition.assignment.strategy=CooperativeStickyAssignor

⚠️ Частая ошибка: лечить «умирающий» консюмер бесконечным увеличением таймаутов вместо выноса тяжёлой обработки из poll-цикла.

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

Подробно:

1. Перекос — партиция с горячим ключом упирается в единственный консюмер: лаг растёт только на ней, а масштабирование группы не помогает.
2. Смена числа партиций — hash(key) % partitions меняется: старые и новые сообщения одного ключа оказываются в разных партициях, порядок по ключу ломается. Число партиций закладывайте заранее.
3. null-ключ — годится для событий без сущности-владельца, где порядок не важен.

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

Короткий ответ: Коммитьте следующий offset после последней безопасно завершённой непрерывной последовательности в каждой партиции. Commit до эффекта рискует пропуском после crash; после эффекта допускает повтор и требует идемпотентности.

В Java consumer auto-commit способен дать at-least-once, если все записи poll полностью обработаны до следующего poll или close. Опасность возникает при передаче работы асинхронным workers, пока polling/commit движется дальше.

При ручных commit:

1. Poll и обработка с enable.auto.commit=false.
2. Учитывайте завершение по партициям; не коммитьте за незавершённую раннюю запись, даже если поздние готовы.
3. Обрабатывайте ошибки commitAsync. Финальный commitSync полезен при корректном shutdown/revocation, но может упасть или истечь по таймауту: это не гарантия доставки.
4. Безопасно останавливайте/отзывайте работу при rebalance. Повторы должны быть идемпотентны.

⚠️ Ловушка: commit offset 42 означает продолжить с 42: записи до 41 уже должны быть безопасны. Синхронный commit не делает внешний бизнес-эффект атомарным с Kafka offset.

Короткий ответ: если эффект завершился, но следующий offset не закоммичен, после переназначения запись может прийти снова и повторить эффект. Это ожидаемое окно дубля process-then-commit at-least-once; гарантию определяют настройки Kafka и порядок приложения, а не универсальный default.

Подробно:

c1: poll ──► обработал (записал в БД) ──► 💥 crash
                    оффсет НЕ закоммичен
ребаланс ──► c2 читает с последнего коммита
         ──► то же сообщение доставлено снова

1. Это контракт, а не баг — брокер не знает, что обработка завершилась; единственный сигнал — закоммиченный оффсет.
2. Защита — идемпотентный консюмер: сохранять стабильный message id в inbox-таблицу с UNIQUE-ограничением в одной транзакции с бизнес-эффектом. Повторная доставка упирается в constraint и не применяет эффект второй раз.
3. Обратный порядок хуже — коммит до обработки превращает тот же сбой в потерю сообщения, а не в дубль.

⚠️ Частая ошибка: считать дубли аномалией и не писать дедупликацию — «у нас же Kafka, там всё надёжно».

Короткий ответ: Сначала измерить per-partition лаг (kafka-consumer-groups.sh или экспортер в метрики) и понять, что изменилось: вырос входной поток или замедлилась обработка. Дальше чинить по ранжиру: консюмеры до числа партиций, вынести тяжёлую работу из poll-цикла, батчинг, и только потом — увеличение партиций и backpressure.

Подробно:

$ kafka-consumer-groups.sh --describe --group billing
TOPIC   PART  CURRENT   LOG-END   LAG
orders  0     91400     91420     20
orders  1     52100     98700     46600  ◄ одна партиция
orders  2     97800     97810     10

1. Лаг на одной партиции — горячий ключ или «застрявшее» сообщение: масштабирование не поможет, чинить ключ или обработку.
2. Лаг равномерный — скейлить консюмеры до числа партиций; дальше — бессмысленно.
3. Медленная обработка — вынести I/O из poll-цикла в пул воркеров (аккуратно: порядок по ключу), батчить записи в БД.
4. Системно — увеличить число партиций (планово: ремапит ключи) или договориться с продюсерами о backpressure.
5. Пока чините — следите за max.poll.interval.ms: медленный цикл спровоцирует ребаланс и удвоит лаг.

⚠️ Частая ошибка: первым делом добавить консюмеров сверх числа партиций — новые просто простаивают.

Worker pool должен быть ограничен и сохранять нужный порядок по ключу. Обращайтесь к KafkaConsumer из владеющего потока, при нагрузке pause партиции с своевременным polling и коммитьте только непрерывно завершённые offsets. Один вынос работы из poll без этих правил способен потерять записи.

Короткий ответ: Нужны ограниченные ретраи с долговечной передачей и явной политикой порядка. Retry topics и DLQ — один вариант; Kafka не задерживает запись автоматически из-за имени топика 5m.

1. При retryable-сбое атомарно публикуйте retry и коммитьте входной offset одной Kafka-транзакцией. Иначе publish-then-commit допускает дубль, а commit-then-publish — потерю.
2. Храните attempt count, исходную идентичность, время следующей попытки и безопасное описание ошибки. Retry consumer проверяет срок без блокировки polling дольше max.poll.interval.ms; pause/resume и ограниченный scheduler требуют корректной работы с offsets.
3. После бюджета попыток/возраста долговечно передайте запись в мониторируемую DLQ. Нужен ответственный процесс разбора/redrive с сохранением исходного id.
4. Retry topics позволяют обогнать неуспешную запись. Для упорядоченных команд или дельт блокируйте/буферизуйте сущность до разрешения пропущенной sequence. Старое событие можно отбросить лишь когда поздний полный snapshot действительно его заменяет.

⚠️ Ловушка: in-place ретраи допустимы для сохранения порядка, если ограничены и поддерживают group liveness. Ни бесконечный retry, ни тихое удаление старой платёжной дельты не являются правильным default.

Короткий ответ: enable.idempotence=true: продюсер получает producer id, каждое сообщение — sequence number, и брокер отбрасывает дубли ретраев — в пределах партиции и сессии продюсера. Транзакции (transactional.id + read_committed) добавляют атомарный consume-transform-produce между топиками Kafka. Ни то ни другое не дедуплицирует бизнес-дубли и не покрывает эффекты вне Kafka.

Подробно:

1. Идемпотентность — защита от сетевых ретраев самого клиента; повторный send() из кода приложения — это новое сообщение.
2. Транзакции — оффсеты коммитятся в той же транзакции (sendOffsetsToTransaction): цикл read-process-write целиком или никак.
3. Границы — приложение отправило одно бизнес-событие дважды → для Kafka это два разных сообщения; запись в Postgres или HTTP-вызов транзакцией Kafka не покрыты.

⚠️ Ловушка: внутри корректной Kafka-транзакции выход и offsets могут иметь exactly-once без отдельного inbox. Бизнес-дубли и внешние эффекты всё ещё требуют собственной идентичности, транзакций или идемпотентности получателя.

Короткий ответ: Сравнивайте модель сообщений и нагрузку, а не фиксированный рейтинг throughput. Kafka — партиционированный лог с retention. RabbitMQ имеет classic/quorum task queues и retained streams.

Kafka подходит replayable event pipelines и независимым группам обработки. Task queues RabbitMQ удобны для распределения отдельных задач и routing; для логовой нагрузки рассмотрите также RabbitMQ streams.

⚠️ Ловушка: измеряйте с вашими durability, размером сообщений, batching и топологией. Ни один продукт не обещает универсального преимущества messages/sec или latency.

Короткий ответ: Порядок сохраняют продюсер, лог, scheduler workers и retry policy. Общий ключ лишь размещает записи вместе; сам он не задаёт бизнес-порядок.

1. Присваивайте sequence/version атомарно с изменением сущности, часто в DB/outbox. Публикуйте в этом порядке со стабильным partition key и совместимым partitioner; конкурентным продюсерам нужна координация.
2. Изменение числа партиций и миграции не должны разделять нужную область порядка. Kafka сохраняет append order внутри партиции, а не общий порядок топиков.
3. Обрабатывайте сущность последовательно; worker pool не должен позволять поздней операции обогнать незавершённую. Commit — только за непрерывно завершённые offsets.
4. Для команд/дельт требуйте следующую ожидаемую sequence. Уже применённое дедуплицируйте; будущее буферизуйте/ретрайте, пропуски и poison events разрешайте явно.
5. Поздний полный snapshot иногда заменяет ранний snapshot. Поздняя платёжная дельта не заменяет предыдущую. Retry topics требуют этого различия.

⚠️ Ловушка: бизнес-координация между топиками возможна через state machine/sequence, но Kafka не даёт такой порядок автоматически. Проверяйте дубли, пропуски, ретраи и rebalance, не только happy path.

Короткий ответ: Очередь развязывает сервисы во времени: консюмер может лежать, а продюсер продолжает работать; пики сглаживаются буфером; одно событие фан-аутится многим потребителям; историю можно перечитать. HTTP с ретраями оставляет временнУю связанность: получатель обязан быть жив прямо сейчас.

Подробно:

1. Очередь — события, фоновые задачи, пиковые нагрузки, несколько независимых потребителей одного события.
2. HTTP — подходит, если вызывающему нужен немедленный результат. Синхронный транспорт сам не даёт более сильной изоляции транзакций или consistency реплик.
3. Цена очереди — eventual consistency, обязательная обработка дублей (at-least-once), мониторинг лага, request-response через correlation — сложнее и дороже в отладке.

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

Короткий ответ: Cache-aside — приложение читает кэш, на промахе идёт в БД и кладёт результат; на запись пишет в БД и инвалидирует ключ. Write-through — запись синхронно в кэш и в хранилище. Write-behind — ack от кэша, в хранилище сбрасывается асинхронно. Дефолт — cache-aside; остальные две — под конкретные профили нагрузки.

Подробно:

1. Cache-aside — кэш не стоит на критическом пути записи и его падение переживается (просто больше промахов); цена — свой протокол инвалидации на каждую запись.
2. Write-through — успех подтверждается после долговечной записи в источник по его контракту. Раздельным DB/cache-записям нужны правила частичного сбоя, гонок и обходных путей; consistency не возникает автоматически.
3. Write-behind — буфер для шквала записей (счётчики, лайки, метрики); без durable-буфера (очередь, AOF) падение узла = потерянные записи.

⚠️ Частая ошибка: выбирать write-behind «для скорости», не ответив, что случится с несброшенными записями при падении процесса.