Модуль 22 ⏱ ~319 мин чтения 📐 3 Mermaid диаграмм

03. Типы данных, slice, map, string

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

Архитектура данных: структуры в памяти и Mechanical Sympathy

В языке Go фундаментальные структуры данных — срезы (slice), ассоциативные массивы (map) и строки (string) — спроектированы с предельной заботой о процессорном кэше (Mechanical Sympathy). Они скрывают за лаконичным синтаксисом компактные заголовки фиксированного размера, которые идеально ложатся в 64-байтные кэш-линии процессора и минимизируют косвенную адресацию.

flowchart LR
    classDef header fill:#1e3a5f,stroke:#38bdf8,stroke-width:2px,color:#f8fafc
    classDef field  fill:#1e293b,stroke:#38bdf8,stroke-width:1px,color:#f8fafc
    classDef buffer fill:#132d29,stroke:#2dd4bf,stroke-width:1px,color:#f8fafc
    classDef cap    fill:#334155,stroke:#64748b,stroke-width:1px,color:#f8fafc

    subgraph SliceHeader["Slice Header (24 байта на x86-64)"]
        Ptr["Data Pointer (8B)"]:::field
        Len["Length = 3 (8B)"]:::field
        Cap["Capacity = 5 (8B)"]:::field
    end

    subgraph UnderlyingArray["Базовый массив в памяти"]
        E0["Elem 0"]:::buffer
        E1["Elem 1"]:::buffer
        E2["Elem 2"]:::buffer
        E3["Резерв (cap)"]:::cap
        E4["Резерв (cap)"]:::cap
    end

    Ptr --> E0

flowchart TD
    classDef old    fill:#1e293b,stroke:#38bdf8,stroke-width:1px,color:#f8fafc
    classDef swiss  fill:#1e1b4b,stroke:#818cf8,stroke-width:2px,color:#f8fafc
    classDef detail fill:#132d29,stroke:#2dd4bf,stroke-width:1px,color:#f8fafc

    subgraph ClassicMap["Классическая карта Go (до 1.23)"]
        H1["hmap (бакеты по 8 пар)"]:::old --> B1["Bucket 0 (tophash + 8 keys + 8 values)"]:::old
        B1 -->|"Коллизия"| O1["Overflow Bucket (указатель)"]:::old
    end

    subgraph SwissMap["Swiss Tables в Go 1.24+"]
        SH["Table (открытая адресация)"]:::swiss
        Ctrl["Группа Control Bytes (8 байт / 8 слотов)"]:::detail
        Slots["Массив слотов (Key + Value)"]:::detail
        SH --> Ctrl
        SH --> Slots
        Ctrl -->|"SWAR/SIMD parallel match"| Match["Параллельный поиск группы слотов"]:::swiss
    end

flowchart LR
    classDef str   fill:#1e3a5f,stroke:#38bdf8,stroke-width:2px,color:#f8fafc
    classDef field fill:#1e293b,stroke:#38bdf8,stroke-width:1px,color:#f8fafc
    classDef raw   fill:#132d29,stroke:#2dd4bf,stroke-width:1px,color:#f8fafc

    subgraph StringHeader["String Header (16 байт на x86-64)"]
        SPtr["Data Pointer (8B)"]:::field
        SLen["Length = 5 (8B)"]:::field
    end

    subgraph ReadOnlyData["Неизменяемый массив байт (.rodata)"]
        B0["'H' (0x48)"]:::raw
        B1["'e' (0x65)"]:::raw
        B2["'l' (0x6c)"]:::raw
        B3["'l' (0x6c)"]:::raw
        B4["'o' (0x6f)"]:::raw
    end

    SPtr --> B0

TEXT

+---------------------------------------------------------------------------------+
|                         Cache Line процессора (64 байта)                        |
| [ Data Pointer (8B) | Len (8B) | Cap (8B) ] [ Дополнительные поля/данные (40B) ]|
+---------------------------------------------------------------------------------+

Навигатор по вопросам главы

Что такое массив (array)?
Чем массив отличается от среза (slice)?
Что такое срез (slice)?
Как устроен срез (ptr, len, cap)?
Что такое len у среза?
Что такое capacity у среза?
Как работает append?
Когда происходит реаллокация (realloc) при append?
Как растет capacity среза?
Что происходит при копировании среза?
Как работает функция copy?
Что такое nil срез (nil slice)?
Чем nil срез отличается от empty среза?
Что такое карта (map)?
Как устроена карта (hmap)?
Что такое бакет (bucket) в карте?
Что такое overflow bucket?
Почему порядок обхода карты не гарантирован?
Что происходит при расширении (resize) карты?
Что такое коллизия хешей (hash collision)?
Что такое load factor?
Почему карта не потокобезопасна (not thread-safe)?
Что будет при конкурентной записи (concurrent write) в карту?
Что такое строка (string)?
Как устроена строка?
Почему строка неизменяема (immutable)?
Что происходит при конкатенации строк?
Что такое []byte и как его преобразовать в string?
Что такое срез рун ([]rune)?
Как правильно работать с unicode в строках?
Что такое range для строки?
В чем разница между len(str) и utf8.RuneCountInString(str)?
Как устроена многомерная карта и какие есть альтернативы?
Как реализован sync.Map и в каких случаях его применять?
Что такое struct?
Как сравниваются структуры (==)?
Что такое make и new?
Чем make отличается от new?
Почему copy работает только со срезами, но не с массивами?
Что такое «глубокое копирование» среза и как его реализовать?
Как работает «срезание среза» и что происходит с базовым массивом?
Как работает итерация по карте во время её изменения?
Почему нельзя взять адрес элемента карты?
Что такое unsafe.Sizeof для строк и срезов?
Что такое comparable интерфейс и для каких типов он реализован?
Какие типы данных нельзя использовать в качестве ключей карты?
В чем отличие string.Builder от конкатенации строк?
Как работает strings.Builder внутри и почему он эффективен?
Что такое type alias и чем отличается от определения типа?
Как реализовать потокобезопасный слайс без sync.Mutex?
Что такое пакет unique в Go 1.23?
Что такое Swiss Tables и как они улучшили map в Go 1.24?

Что такое массив (`array`)?

Краткий ответ (30–60 секунд)

Массив в Go — это нумерованная последовательность элементов фиксированной длины, принадлежащих одному типу. Размер массива является частью его типа, поэтому [3]int и [4]int — разные, несовместимые типы. Массив размещается в памяти как непрерывный блок из N элементов, его длина определяется во время компиляции. Значение массива — это сам массив, а не указатель на данные, поэтому при присваивании или передаче в функцию происходит полное копирование всех элементов.

Развёрнутый ответ

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

Фиксированная длина задаётся при объявлении и не может быть изменена.
Тип включает длину: [5]int и [10]int — это разные типы, не приводимые друг к другу.
Значение, а не ссылка: переменная массива хранит непосредственно данные. При присваивании b := a происходит копирование всех элементов.
Нулевое значение — массив, заполненный нулевыми значениями его элементов (например, [3]int{} — [0,0,0]).

var a [3]int
a[0] = 10
b := a     // полная копия, изменение b не влияет на a

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

Под капотом (internals)

В рантайме Go массив — просто последовательность элементов в памяти без какой-либо метаинформации. Компилятор знает размер массива, поэтому операции индексации a[i] превращаются в прямое вычисление смещения: base + i * sizeof(element) с обязательной проверкой границ (bounds check elimination может убрать проверки, если компилятор докажет безопасность). Массив располагается на стеке, если его размер известен и он не утекает в кучу (escape analysis). Передача [1<<20]byte в функцию вызовет копирование мегабайта, что крайне неэффективно — поэтому используют срезы.

Типичные ошибки кандидатов

Ожидание ссылочного поведения: передача массива в функцию и попытка изменить его элементы внутри. Изменения останутся в копии, оригинал не затронут.
Почему неправильно: Массив — value type, функция получает свой экземпляр. Чтобы изменения отразились на оригинале, нужно передавать указатель *[N]T (но размерность остаётся фиксированной в типе), либо использовать срез.
Исправление: передавать *arr или переписать на срез.
Использование [...] для создания массива переменной длины на лету: arr := [...]int{1,2,3} создаёт массив, длина которого зафиксирована на этапе компиляции по количеству инициализаторов; это не динамический массив.
Почему неправильно: Часто путают со срезом. arr будет [3]int, его нельзя передать в функцию, ожидающую []int.
Исправление: использовать []int{1,2,3} (срез), если нужна изменяемая длина.
Сравнение массивов разной длины через ==: [3]int{} == [4]int{} не скомпилируется, так как это разные типы.
Исправление: сравнивать только массивы одного типа, либо срезы через reflect.DeepEqual.

Возможные дополнительные вопросы интервьюера

Как получить указатель на массив, совместимый с указателем на его первый элемент?
Делать &arr[0] — это даёт *T. Сам массив и его первый элемент имеют один и тот же адрес, но типы разные. Указатель на массив *[N]T можно преобразовать в указатель на первый элемент, но для среза обычно делают arr[:].

Как использовать массивы для оптимизации аллокаций в критичном коде?
Можно выделить массив на стеке (например, var buf [64]byte), а затем получить из него срез buf[:] для интерфейсов ввода-вывода, избегая ухода в кучу при ограниченных размерах.

Чем массив отличается от среза (`slice`)?

Краткий ответ (30–60 секунд)

Массив — это значение фиксированной длины, где размер является частью типа; он хранит данные непосредственно. Срез — это динамическое окно над массивом, представленное тройкой (указатель на элемент массива, длина, ёмкость). Срез не владеет данными, а ссылается на нижележащий массив; его длина может изменяться, но в пределах ёмкости. При передаче в функцию копируется сам заголовок среза (24 байта на 64-битной системе), но не данные.

Развёрнутый ответ

Ключевые различия:

Изменяемость длины: размер массива фиксирован, срез поддерживает append (с возможной реаллокацией новой памяти).
Владение данными: массив содержит свои элементы; несколько срезов могут разделять один и тот же базовый массив.
Передача в функции: массив копируется целиком, срез — копируется только заголовок (3 слова), что дёшево и позволяет модифицировать элементы оригинального массива.
Нулевое значение: у массива — заполненный нулями массив, у среза — nil (указатель, длина и ёмкость равны нулю).
Тип: [N]T vs []T.

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

arr := [3]int{1,2,3}
s := arr[:]   // срез, ссылается на arr

Под капотом (internals)

Срез описывается структурой reflect.SliceHeader (в рантайме — runtime.slice):

type slice struct {
    array unsafe.Pointer
    len   int
    cap   int
}

При передаче среза копируются именно эти три поля. Указатель array указывает на некоторый элемент базового массива (не обязательно на начало), что позволяет делать подсрезы типа s[1:]. Массив же — просто последовательность байтов с размером, известным компилятору; для [3]int в стеке выделяется 24 байта на 64-битной платформе.

Типичные ошибки кандидатов

Смешивание синтаксиса: var s = [...]int{1,2} создаёт массив, а var s = []int{1,2} — срез. Ошибка приводит к несоответствиям типов при вызовах функций.
Исправление: явно использовать [] для среза, [...] — только для массива с выводом длины.
Попытка использовать cap у массива: cap(arr) компилируется только для срезов и массивов? На самом деле cap применима к массивам, возвращая его длину (массив фикс.). Это путаница, но не ошибка; проблема в том, что cap у массива не даёт дополнительной информации. Ошибкой является полагать, что массив можно расширить через append — будет ошибка компиляции: первый аргумент должен быть срезом.
Копирование огромного массива при передаче в функцию: забывают, что массив — value type, и не используют указатель или срез.
Исправление: принимать *[N]T или срез.

Возможные дополнительные вопросы интервьюера

Можно ли объявить массив, длина которого задаётся константой, вычисленной на этапе компиляции?
Да, const size = 4; var arr [size]int — константы допустимы.

Чем отличается *[4]int от []int в параметрах функции?
Первый — указатель на массив из 4 элементов, вызывающая сторона должна передать именно &arr типа *[4]int. Второй принимает любой срез []int. Указатель на массив даёт возможность изменить длину? Нет, длина массива фиксирована, но можно изменить элементы. Срез же может переаллоцироваться, но вызывающая сторона не увидит новую память, если не вернуть срез.

Что такое срез (`slice`)?

Краткий ответ (30–60 секунд)

Срез — это абстракция над массивом, предоставляющая гибкое и динамическое представление последовательности элементов одного типа. Он состоит из указателя на элемент массива (начало), целочисленной длины (len) и ёмкости (cap). Срез не хранит данные, а ссылается на непрерывный сегмент нижележащего массива. Это делает его легковесным (24 байта на 64-разрядных системах) и позволяет эффективно передавать большие объёмы данных без копирования.

Развёрнутый ответ

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

Объявление: var s []int, s := make([]int, 5, 10).
Инициализация из массива или другого среза: s := arr[low:high], создаёт заголовок среза, указывающий на тот же базовый массив.
Нулевой срез: nil — пригоден для использования (len=0, cap=0), его можно ранжировать и аппендить.
Длина — количество элементов, доступных по индексу от 0 до len-1.
Ёмкость — максимальная длина, которую может иметь срез без выделения нового массива (количество элементов от указателя до конца базового массива).

Под капотом (internals)

В рантайме срез представлен структурой slice в runtime/slice.go:

type slice struct {
    array unsafe.Pointer
    len   int
    cap   int
}

Операции со срезом (например, s[1:3]) создают новый заголовок, но не копируют данные. Указатель нового среза может смещаться вглубь базового массива. Благодаря этому эффективно реализуются очереди (pop front через s = s[1:]), но надо помнить про удержание памяти: пока хотя бы один срез ссылается на массив, он не будет собран.

Типичные ошибки кандидатов

Забывают, что срезы ссылаются на один массив: изменение элемента в подсрезе меняет исходный массив/срез. Это приводит к неожиданным сайд-эффектам.
Исправление: если нужна независимая копия, использовать copy в новый срез.
Создание среза с помощью make([]T, 0, cap) и последующее обращение по индексу до append: у среза длина 0, s[0] вызовет панику (index out of range).
Исправление: задать ненулевую длину или добавлять элементы только через append.
Путаница с nil-срезом: var s []int — nil-срез, но s = []int{} — не-nil, пустой. JSON-сериализация выдаёт null для nil, [] для empty. Это важно для API.
Исправление: инициализировать как var s []int, если nil важен; иначе make([]int, 0).

Возможные дополнительные вопросы интервьюера

Может ли срез быть nil, но иметь ненулевую ёмкость?
Нет, nil-срез всегда имеет len=0, cap=0, и указатель массива nil. Срез с cap>0 обязательно указывает на какой-либо выделенный массив.

Чем срез в Go отличается от вектора в C++?
Вектор владеет своей памятью и всегда уникален, копирование вектора глубокое (если не move). Срез – это ссылочный тип, копирование заголовка не аллоцирует новый массив. Управление памятью разное: вектор расширяется отдельно, срезы могут указывать на один буфер.

Как устроен срез (ptr, len, cap)?

Краткий ответ (30–60 секунд)

Срез внутренне представлен структурой reflect.SliceHeader, которая содержит три поля: Data unsafe.Pointer (указатель на первый элемент среза в нижележащем массиве), Len int (количество элементов, доступных через срез) и Cap int (общее количество элементов от указателя до конца базового массива). Заголовок среза копируется при присваивании, но данные нет. Таким образом, несколько срезов могут разделять одну и ту же область памяти с разными длинами и смещениями.

Развёрнутый ответ

Структура заголовка (runtime.slice):

type slice struct {
    array unsafe.Pointer
    len   int
    cap   int
}

array — указатель на элемент массива, с которого начинается видимый фрагмент. Не обязательно на начало выделенного блока: при s[2:] он смещается на 2 элемента.
len — граница допустимой индексации. Обращение s[i] разрешено при 0 <= i < len.
cap — вычисляется как cap(s) = capBaseArray - offset, где offset — смещение в элементах от начала базового массива до array. cap определяет, до какого размера можно расширить срез с помощью append без реаллокации.

Пример:

arr := [5]int{1,2,3,4,5}
s := arr[1:4] // len=3 (2,3,4), cap=4 (элементы с индексами 1..4 базового массива)

s.array указывает на arr[1].

Под капотом (internals)

В исходниках runtime/slice.go макросы и функции используют эту структуру. makeslice выделяет массив и возвращает срез с нужными параметрами. При s = s[low:high] новый заголовок собирается с проверкой границ: len = high-low, cap = cap(s)-low, array = s.array + low*sizeof(element). Это дешёвая операция без аллокаций. Работа append читает cap и определяет, достаточно ли места; если нет — вызывает growslice, который выделяет новый массив и копирует элементы.

Типичные ошибки кандидатов

Изменение данных через подсрез, когда ожидается независимость: например, sub := data[2:5]; sub[0] = 100 — data[2] тоже изменится. Это фундаментально для понимания разделяемой памяти.
Исправление: перед модификацией делать sub := make([]T, 3); copy(sub, data[2:5]), если нужна изоляция.
Утечка памяти из-за удержания большого массива через маленький срез: tiny := huge[0:1] сохраняет ссылку на весь огромный массив, GC не соберёт его.
Исправление: скопировать нужные данные в новый срез: tiny := make([]T, 1); copy(tiny, huge[0:1]).
Недооценка влияния смещения на cap: s := make([]int, 5, 10); s2 := s[2:]; cap(s2) == 8 (10-2). При последующем s2 = append(s2, ...) до длины 8 изменяются элементы исходного s[2:]. После превышения cap — реаллокация и отвязка.

Возможные дополнительные вопросы интервьюера

Как быстро поменять местами два элемента среза без временной переменной?
a, b = b, a — работает в Go, но требует, чтобы a и b были адресуемыми элементами. Можно slice[i], slice[j] = slice[j], slice[i].

Если взять срез от nil-среза: nilSlice[:], что произойдёт?
Вернётся nil-срез (len=0, cap=0), паники не будет, потому что операция s[0:0] допустима даже для nil (low=high=0). При low>0 — panic: index out of range.

Что такое `len` у среза?

Краткий ответ (30–60 секунд)

len(slice) — встроенная функция, возвращающая текущее количество элементов, которое хранится в срезе. Она показывает, сколько элементов доступно для чтения и записи по индексам от 0 до len-1. Для nil-среза len возвращает 0, для только что созданного через make([]T, length, capacity) — length. Длина — это один из трёх компонентов заголовка среза, она не отражает физический размер выделенной памяти.

Развёрнутый ответ

Длина среза определяет границы допустимой индексации. При итерации for i := 0; i < len(s); i++ или for i, v := range s обходится ровно len элементов. len — это поле в структуре заголовка, поэтому вызов len(s) — это O(1), простое чтение значения из памяти (или регистра). Изменить длину можно только через специальные операции: присваивание подсреза (s = s[:newLen]), append, copy и явное изменение поля через reflect.SliceHeader (но это небезопасно без пакета unsafe).

s := make([]int, 3, 5)
fmt.Println(len(s)) // 3
s = s[:cap(s)]      // len становится 5

Под капотом (internals)

В скомпилированном коде len(s) компилятор генерирует доступ к полю len структуры runtime.slice. В рантайме функция len не имеет собственной реализации, это встроенная операция. В runtime/slice.go операции типа s = s[low:high] вычисляют новую длину как high - low и записывают её в заголовок. Никакой дополнительной метаинформации о длине не хранится.

Типичные ошибки кандидатов

Путаница len и cap: пишут if len(s) < cap(s) { s = s[:cap(s)] } и ожидают, что появятся новые инициализированные элементы. Они появляются, но с нулевыми значениями, что может нарушить логику.
Исправление: чётко осознавать, что при расширении через срезание вы получаете элементы базового массива с их текущими значениями (нули или мусор от предыдущих операций). Использовать append или предварительно заполнить.
Проверка len(s) == 0 как индикатор nil: пустой срез []int{} тоже даёт len=0, но не nil. Это важно для JSON, как упоминалось.
Исправление: для различия nil и empty проверять s == nil.

Возможные дополнительные вопросы интервьюера

Можно ли изменить len среза без создания нового среза?
Да, если переприсвоить срез с новыми границами: s = s[:newLen], но newLen не может превышать cap. Это изменяет локальный заголовок.

Что быстрее: len(s) или сохранение длины в отдельную переменную при обходе?
len(s) — это чтение из регистра/стека, накладные расходы пренебрежимо малы. Компилятор может подставить значение, если срез не меняется. Сохранение в переменную имеет смысл только если длина изменяется в цикле (уменьшается) и вы хотите зафиксировать исходную.

Что такое `capacity` у среза?

Краткий ответ (30–60 секунд)

cap(slice) — встроенная функция, возвращающая ёмкость среза: максимальное количество элементов, которое он может вместить без выделения нового массива. Ёмкость вычисляется как количество элементов от текущего указателя среза до конца базового массива. При вызове append, если новая длина превышает cap, происходит реаллокация. В противном случае элементы добавляются в неиспользуемое «хвостовое» пространство без аллокаций.

Развёрнутый ответ

Ёмкость задаётся при создании через make([]T, len, cap) или определяется базовым массивом. Если cap не указана, она равна len. При срезании s[low:high] ёмкость нового среза равна cap(s) - low. Это позволяет эффективно наращивать длину, не затрагивая первичный буфер.

s := make([]int, 0, 10) // len=0, cap=10
s = append(s, 1, 2)     // len=2, cap=10, аллокации нет

Понимание ёмкости критично для производительности: предустановка ожидаемой cap при make или make([]T, 0, estimatedSize) минимизирует количество реаллокаций.

Под капотом (internals)

Структура заголовка хранит cap как int. При росте через growslice (в runtime/slice.go) новое значение cap рассчитывается по формуле роста (удвоение до 1024, затем 1.25x с округлением, учитывая alignment). После копирования старых данных в новый массив, срез обновляет array, cap и сохраняет len. При срезании s2 := s[:m] проверяется, что m <= cap(s), иначе паника.

Типичные ошибки кандидатов

Путаница с cap у подсреза: b := a[2:3]; cap(b) может быть большим (равен cap(a) - 2). Последующий append(b, ...) может изменить элементы a правее исходного окончания, потому что append пишет в разделяемый массив.
Исправление: для изоляции использовать b := a[2:3:3] (третий индекс ограничивает cap), тогда append приведёт к реаллокации сразу.
Игнорирование cap при преобразовании []byte в string с помощью unsafe: *(*string)(unsafe.Pointer(&b)) создаст строку, длина которой равна len(b), но может выйти за границы, если не учесть, что строка должна быть только до len, но внутренне GC ожидает корректности. Однако это уже тема unsafe.
Создание среза с make([]T, length) и ожидание, что cap автоматически больше длины: cap равна length, если не указана отдельно. Последующий append сразу вызовет реаллокацию.
Исправление: make([]T, length, capacity).

Возможные дополнительные вопросы интервьюера

Как принудительно ограничить ёмкость подсреза, чтобы избежать случайной модификации родительского массива?
Использовать полное выражение среза a[low:high:max], где max задаёт cap = max - low. Тогда append, доходя до max, переключится на новый массив, оставив родительский нетронутым.

Какова алгоритмическая сложность cap(s)?
O(1), чтение поля.

Как работает `append`?

Краткий ответ (30–60 секунд)

append(slice, elem...) добавляет элементы в срез. Если после добавления длина не превышает ёмкость среза, новые элементы записываются в существующую свободную область базового массива, и возвращается тот же самый срез с увеличенной длиной. Если ёмкость недостаточна, append выделяет новый, больший массив, копирует в него старые элементы и добавляет новые. Возвращаемое значение обязательно нужно присваивать (обычно той же переменной), так как может измениться заголовок среза (длина, указатель на массив, ёмкость).

Развёрнутый ответ

append — ключевая функция, делающая срезы динамическими. Её сигнатура: func append(slice []T, elems ...T) []T. Важно:

Если len(slice) + len(elems) <= cap(slice), расширяет длину и копирует элементы в хвост. Указатель array остаётся прежним.
Иначе вызывает growslice для получения нового массива, копирует старые элементы и дописывает новые. Возвращает новый срез с обновлёнными array, len и cap.
Результирующий срез может ссылаться на совершенно другой базовый массив. Поэтому всегда используйте s = append(s, ...). Забыв присвоить результат, вы продолжите работать со старым (возможно, уже неполным или переполненным) заголовком.

Пример:

s := make([]int, 0, 3)
s = append(s, 1, 2) // len=2, cap=3
s = append(s, 3, 4) // превышает cap, новый массив длиной 6 (рост 3 -> 6)

Под капотом (internals)

Реализация в runtime/slice.go и runtime/stubs.go (asm на некоторых платформах). Компилятор встраивает код append. Внутри:

Вычисляется новая длина.
Если newLen > cap, вызывается growslice(oldPtr, oldLen, oldCap, newLen, elemType). growslice рассчитывает новый cap по формуле роста и выделяет память через mallocgc.
Затем memmove копирует старые элементы в новое место (в начало) и дописывает добавляемые элементы.
Если места достаточно, memmove пишет новые элементы сразу за старыми, и обновляется поле len.

Особый случай: append(s, s...) должен корректно обрабатывать перекрытие — в случае реаллокации сначала копируются старые, затем добавляются; если места хватает, но источник и приёмник перекрываются, используется временный буфер.

Типичные ошибки кандидатов

Присваивание результата append другой переменной, но продолжение использования исходной: s2 := append(s, 1); ... s[0] = 5. Если аллокации не было, s и s2 разделяют массив, изменение s[0] повлияет на s2, и наоборот. Если была реаллокация, s остался со старой длиной, но может по-прежнему указывать на старый массив (если были другие ссылки), и тогда модификация s не затронет s2, но возникает путаница.
Исправление: всегда обновлять исходную переменную s = append(s, ...) и не сохранять старые заголовки без нужды.
Использование append в цикле без резервирования cap: приводит к множественным реаллокациям и копированиям, снижая производительность.
Исправление: s := make([]T, 0, expectedSize).
Неучёт, что append может вернуть срез с другой cap и тем же len: при s = append(s[:0], 1,2) после сброса длины старая ёмкость сохраняется, если её достаточно.

Возможные дополнительные вопросы интервьюера

Может ли append привести к гонке данных при конкурентном доступе?
Да, если несколько горутин пишут в один срез через append без синхронизации. Даже при реаллокации возникают состояния гонки на чтении len, cap и доступ к указателю массива. Срезы не потокобезопасны, нужна синхронизация.

Что такое "capacity doubling" и когда перестаёт действовать?
До Go 1.22: при cap < 1024 ёмкость удваивается; затем рост идёт на ~25% за шаг. Это эвристика, реализованная в nextslicecap (раньше в growslice). С версии 1.22 формула немного подкорректирована для снижения фрагментации, но суть та же: экспоненциальный рост для малых срезов, линейный для больших.

Когда происходит реаллокация (realloc) при `append`?

Краткий ответ (30–60 секунд)

Реаллокация происходит, когда суммарная длина после добавления элементов превышает текущую ёмкость среза: len(s) + len(elems) > cap(s). В этом случае append выделяет новый, более вместительный массив, копирует в него старые элементы и размещает добавляемые. Если ёмкость достаточна, используется имеющееся место без выделения нового массива.

Развёрнутый ответ

Реаллокация — это выделение совершенно нового непрерывного блока памяти для базового массива. Старый массив может стать недостижимым (если на него нет других ссылок) и будет собран сборщиком мусора. Реаллокация дорога: выделение памяти, копирование данных. Именно поэтому желательно заранее оценивать необходимую ёмкость.
Условие реаллокации проверяется на каждом append. Даже если cap(s) >= newLen, но append вызывается с s равным nil, реаллокация происходит? Нет, если s nil и len=0, cap=0, а elems > 0, то новое len > 0, cap нужна, и тут условие newLen > cap истинно (0 > 0 — false?), стоп: nil срез: len=0, cap=0. Добавляем 3 элемента, newLen=3, cap=0, условие 3 > 0 => true, реаллокация. Так что для nil тоже реаллокация.

Особый случай: append(s, s...) при достаточной ёмкости может затереть читаемые элементы, если область памяти пересекается. Рантайм обрабатывает это, при необходимости создавая временный буфер, но не реаллоцируя основной массив (ё косты внутри runtime·appendslice). Это не полноценная реаллокация нового массива для среза.

Под капотом (internals)

В ассемблерной реализации append (см. src/runtime/asm_amd64.s и slice.go), после проверки newLen <= cap переход к быстрому пути копирования; иначе growslice. growslice вызывает nextslicecap для расчёта новой ёмкости, затем mallocgc для аллокации, затем memmove для перемещения старых данных и обновления заголовка. Указатель на старый массив теряется (если не сохранён в другом срезе). GC может освободить старый блок.

Типичные ошибки кандидатов

Ожидание, что старый срез будет указывать на новый массив: сохранили old := s, потом s = append(s, ...) с реаллокацией, и полагают, что old тоже обновился. old остался со старым указателем, его изменения не видны в s (если была реаллокация), и наоборот.
Исправление: не хранить «алиасы» после append без чёткого понимания; либо синхронизировать результаты.
Сравнение указателей на срезы для детекта реаллокации: &s[0] до и после append — разные адреса, если реаллокация. Но это ненадёжно, лучше сравнивать cap или отслеживать длину.
Исправление: использовать cap(s) до и после.
Использование указателей на элементы среза, которые могут инвалидироваться после append: p := &s[2]; s = append(s, ...) — если произошла реаллокация, p указывает в старую память, висячий указатель.
Исправление: не сохранять указатели на элементы среза, который будет расширяться, или пересохранять после каждого append.

Возможные дополнительные вопросы интервьюера

Может ли реаллокация произойти при append(s, []T{}...), т.е. добавлении пустого среза?
Нет, newLen == len(s), условие не превышает cap, реаллокации не будет, append просто вернёт исходный срез.

Как growslice выбирает размер нового массива с учётом alignment?
Используется roundupsize, который для больших объектов выравнивает размер по страницам памяти, для маленьких — по классам размеров (size classes), чтобы уменьшить фрагментацию. Формула nextslicecap учитывает et.size, текущий cap, и требования к выравниванию.

Как растет `capacity` среза?

Краткий ответ (30–60 секунд)

При расширении среза через append используется эмпирическая формула роста, обеспечивающая амортизированное O(1) на добавление. До Go 1.22: если старая ёмкость (oldcap) меньше 1024, новая ёмкость удваивается; иначе увеличивается на 25% (умножается на 1.25). Начиная с Go 1.22, алгоритм стал чуть сложнее: при малых oldcap (до 256) рост более агрессивный (удвоение), затем плавнее, чтобы уменьшить перерасход памяти. В обоих случаях итоговая ёмкость округляется вверх с учётом выравнивания элемента.

Развёрнутый ответ

Алгоритм роста реализован в функции nextslicecap (раньше был частью growslice) в runtime/slice.go. Формула призвана балансировать между частотой аллокаций и перерасходом памяти.

Пример для Go 1.22 (упрощённо):

newcap := oldCap
doublecap := oldCap + oldCap
if newLen > doublecap {
    newcap = newLen
} else {
    const threshold = 256
    if oldCap < threshold {
        newcap = doublecap
    } else {
        for 0 < newcap && newcap < newLen {
            newcap += (newcap + 3*threshold) / 4
        }
        if newcap <= 0 {
            newcap = newLen
        }
    }
}

Суть: быстрый рост на малых размерах, замедленный — на больших. Далее roundupsize корректирует до подходящего класса размера (size class), что может немного увеличить итоговую ёмкость.

Под капотом (internals)

Функция nextslicecap (или старая логика в growslice) получает oldCap, newLen и тип элемента. Вычисляет doublecap, сравнивает. Важный момент: новая ёмкость не может быть меньше требуемой newLen. После расчёта вызов mallocgc выделяет память. В итоге реальная cap может быть больше запрошенной из-за выравнивания, что позволяет нескольким последующим append происходить без реаллокаций.

При очень больших срезах (близко к maxInt) рост может прекратиться, и append запаникует при невозможности выделить память.

Типичные ошибки кандидатов

Предположение, что cap всегда удваивается: на больших срезах рост меньше, это приводит к неверным оценкам числа последующих безреаллокационных добавлений.
Исправление: изучить реальную кривую роста для конкретного типа и размеров, не полагаться на удвоение навсегда.
Создание среза с большим запасом по cap через make([]T, 0, huge) в надежде, что рост не понадобится, но забывают, что это сразу выделяет память под huge элементов. Иногда лучше динамический рост.
Исправление: профилировать и выбирать адекватный первоначальный capacity.
Игнорирование округления вверх: запросив make([]byte, 0, 10), вы можете получить фактическую cap > 10 из-за size classes. Это может сломать логику, если вы полагаетесь на точное значение cap.
Исправление: не полагаться на точное равенство cap после make.

Возможные дополнительные вопросы интервьюера

Почему выбрано именно 1024 как порог для замедления роста?
Это компромисс, найденный эмпирически: для малых срезов цена копирования невелика, и удвоение быстро достигает нужного размера. Для больших — удвоение приводило бы к гигантским скачкам и wasted memory, рост на 25% сглаживает. В Go 1.22 порог изменился на 256 для более плавной кривой.

Как узнать, сколько именно элементов можно добавить без реаллокации в текущий момент?
cap(s) - len(s) — это свободное место.

Что происходит при копировании среза?

Краткий ответ (30–60 секунд)

Под «копированием среза» обычно понимают присваивание переменной заголовка среза (s2 := s1), что копирует три поля (ptr, len, cap). Данные базового массива не копируются, поэтому оба среза ссылаются на одну и ту же область памяти. Изменение элементов через один срез немедленно отражается на другом. Если нужна независимая копия данных, используют встроенную функцию copy(dst, src), которая копирует элементы из одного среза в другой.

Развёрнутый ответ

Присваивание срезов — это мелкое копирование заголовка, оно чрезвычайно дёшево и не вызывает аллокаций. Это позволяет передавать большие объёмы данных в функции практически бесплатно. Однако совместное использование базового массива — источник ошибок, особенно при append. Когда один из срезов вызывает append, он может изменить длину (и, возможно, переключиться на новый массив), в то время как другой сохраняет старый указатель и длину, что ведёт к рассинхронизации.

Пример:

a := []int{1,2,3}
b := a       // копия заголовка
b[0] = 100   // a[0] тоже становится 100

Под капотом (internals)

Присваивание b := a для среза компилируется в копирование трёх машинных слов: указателя Data, Len, Cap. В рантайме нет дополнительных действий. Функция copy реализована в runtime/memmove (или специфичная typedslicecopy), копирует min(len(dst), len(src)) элементов побайтово из источника в назначение. Важно, что copy работает с элементами, а не заголовками; срезы при этом должны иметь один тип элементов.

Типичные ошибки кандидатов

Попытка скопировать срез через b := make([]T, len(a)); b = a — вместо копирования данных перезаписывает b заголовком от a, теряя выделенный массив и всё равно ссылаясь на данные a.
Исправление: copy(b, a).
Неправильный порядок аргументов copy(dst, src): перепутали местами — данные пишутся не туда, или паника не происходит, но результат не тот.
Исправление: всегда copy(куда, откуда).
Забывают, что copy копирует не более len(dst) элементов: если src длиннее, лишние элементы игнорируются.
Исправление: при необходимости полного копирования делать dst := make([]T, len(src)); copy(dst, src).

Возможные дополнительные вопросы интервьюера

Каков результат copy(nilSlice, someSlice)?
Копирование в nil-срез: len(nilSlice)=0, поэтому скопируется 0 элементов, возвращается 0, паники нет.

Чем плох b := append([]T(nil), a...) для копирования?
Это идиоматический способ создать полную копию среза. Но он неэффективен, если a пустой или нужно часто копировать, так как append может выделить память с запасом (cap > len). Лучше использовать b := make([]T, len(a)); copy(b, a) для точного контроля памяти.

Как работает функция `copy`?

Краткий ответ (30–60 секунд)

Встроенная функция copy(dst, src []T) копирует элементы из среза-источника src в срез-приёмник dst. Количество копируемых элементов равно min(len(dst), len(src)). Функция возвращает это количество. Копирование выполняется побайтово, с учётом того, что dst и src могут перекрываться (в пределах одного среза — поведение корректно, как у memmove). Типы элементов должны быть идентичными (не просто приводимыми). copy работает только со срезами, не с массивами напрямую.

Развёрнутый ответ

copy — единственный безопасный способ получить независимую копию содержимого среза без привлечения unsafe. Сигнатура: func copy(dst, src []Type) int. Ключевые особенности:

Размер копирования: n = len(dst), если len(src) > len(dst), иначе len(src). Лишние элементы не копируются.
Перекрытие: разрешено, copy ведёт себя как memmove, корректно обрабатывая наложение.
Производительность: реализована через runtime.memmove с оптимизациями под размер элемента (если есть дублирующая специализация в компиляторе).
Если dst или src — nil, len = 0, копируется 0 элементов.

Пример:

a := []int{1,2,3,4}
b := make([]int, 2)
n := copy(b, a)   // n=2, b = [1,2]
n = copy(a[1:], a[0:3]) // корректно, хотя перекрываются; n=3, a = [1,1,2,3]

Под капотом (internals)

Компилятор заменяет вызов copy на специальную runtime-функцию: typedslicecopy (для типов с указателями) или memmove (для типов без указателей). Для маленьких копий может быть встроена inline-реализация с разворачиванием цикла. В runtime/slice.go есть slicecopy(to, fm, from, len), которая вычисляет количество байт и вызывает memmove. Проверка перекрытия: если to в пределах from, используется обратный порядок копирования.

Типичные ошибки кандидатов

Копирование в срез с нулевой длиной: dst := make([]int, 0); copy(dst, src) — скопируется 0.
Исправление: dst := make([]int, len(src)).
Использование copy с массивом: copy(arr, slice) не компилируется, нужно copy(arr[:], slice).
Исправление: срезировать массив.
Путаница с возвращаемым значением: полагают, что copy возвращает количество несжатых элементов; это число скопированных, которое может быть меньше len(src). Для надёжности полного копирования используйте copy(dst, src); if len(src) > len(dst) { ... }.

Возможные дополнительные вопросы интервьюера

Что быстрее: copy в цикле или append с предварительным выделением?
copy обычно быстрее для копирования больших блоков, так как это один вызов memmove. append в цикле с ростом делает много аллокаций и копирований. Для конкатенации многих срезов эффективнее использовать copy в заранее выделенный буфер.

Можно ли copy использовать для клонирования карт или структур со срезами?
Нет, copy только для срезов. Для карт — цикл; для структур со срезами — поверхностная копия, нужно глубокое копирование вручную.

Что такое nil срез (`nil slice`)?

Краткий ответ (30–60 секунд)

Nil-срез — это срез, объявленный без инициализации (var s []int). Его заголовок содержит нулевые значения всех полей: array = nil, len = 0, cap = 0. Он имеет нулевую длину и нулевую ёмкость, не ссылается ни на какой массив. Несмотря на nil, к нему можно применять len, cap, append, range (не итерирует), он может быть использован как argument. JSON сериализует его как null, в отличие от пустого среза.

Развёрнутый ответ

Nil-срез — это идиоматический способ представить «отсутствие коллекции». В Go он семантически отличается от пустого среза, но функционально во многих случаях взаимозаменяем. Например, for _, v := range nilSlice {} не выполнит ни одной итерации. append(nilSlice, 1) вернёт новый срез. Однако при проверке s == nil вы получите true. Это используется для различения «не инициализирован» и «пуст, но готов к использованию» (например, в ответах API).

var nilS []int
emptyS := []int{}
fmt.Println(nilS == nil)  // true
fmt.Println(emptyS == nil) // false

Под капотом (internals)

В рантайме nil-срез представляется как slice{array: nil, len: 0, cap: 0}. Так как array == nil, операция взятия подсреза nilS[:] допустима для low=high=0, но любой выход за 0 вызывает панику. При вызове append, рантайм через growslice определяет, что нужен новый массив, выделяет его. Память для заголовка размещается на стеке вызывающей функции.

Типичные ошибки кандидатов

Возврат nil-среза, когда API ожидает пустой JSON-массив: return nil, err медленно сериализуется в null, а фронтенд ждёт []. Ломает контракты.
Исправление: возвращать []T{} или make([]T,0).
Проверка длины вместо nil при различении состояний: if len(s) == 0 не отличает nil от пустого; если это важно (например, флаг «данные не загружены»), нужна проверка if s == nil.
Попытка доступа по индексу к nil-срезу: s[0] — паника index out of range [0] with length 0.
Исправление: перед индексацией убедиться, что len(s) > 0.

Возможные дополнительные вопросы интервьюера

Как проверить, что срез именно nil, а не просто пустой?
s == nil. Или reflect.ValueOf(s).IsNil() (но это медленно).

Можно ли передать nil-срез в функцию, ожидающую []T, и изменить его внутри, чтобы он стал не-nil у вызывающей стороны?
Только если вернуть новый срез, либо передать указатель на срез *[]T. Потому что копия заголовка по значению не даёт модифицировать оригинальный указатель. Внутри функции можно сделать *s = append(*s, 1).

Чем nil срез отличается от empty среза?

Краткий ответ (30–60 секунд)

Nil-срез объявлен как var s []int и имеет array = nil, len = 0, cap = 0. Пустой срез инициализирован как s := []int{} или make([]int,0); его array указывает на валидный адрес (обычно на глобальную переменную zerobase), но len=0, cap=0. Оба имеют длину 0 и ведут себя одинаково в операциях len, range, append. Основное различие — в результате сравнения с nil и в JSON-сериализации: nil -> null, empty -> [].

Развёрнутый ответ

Пустой срез, как правило, создаётся, чтобы явно показать: «здесь есть инициализированная, но пустая коллекция». Это может быть важно для API, где null и [] семантически разные. В большинстве внутренних операций разница несущественна, но есть нюансы:

Сравнение с nil: emptySlice == nil — ложь.
Вместимость: cap обоих = 0.
Итерация: циклы не выполняются.
Внутренний указатель: пустой срез часто указывает на runtime.zerobase — специальный адрес, на который ссылаются все нулевые аллокации. Это позволяет избежать разыменования nil-указателя в некоторых ситуациях (например, при взятии адреса элемента пустого среза через &s[0] — паника в любом случае, но с указателем на zerobase это не nullptr в машинном смысле).

Пример:

var a []int
b := []int{}
c := make([]int, 0)
fmt.Println(a == nil) // true
fmt.Println(b == nil) // false
fmt.Println(c == nil) // false

Под капотом (internals)

При создании []int{} компилятор генерирует код, который устанавливает array на runtime.zerobase. zerobase — это глобальная переменная, адрес которой используется для представления не-nil, но нулевого указателя базового массива (например, для пустых срезов). Это видно в дизассемблере: LEAQ runtime.zerobase(SB), AX. Для var a []int array остаётся нулевым (0). Оба заголовка могут размещаться на стеке.

Типичные ошибки кандидатов

Сравнение s == []int{}: не компилируется, так как срезы нельзя сравнивать с помощью == (кроме nil). Используйте len(s) == 0 или s == nil, в зависимости от нужд.
Исправление: для проверки на пустоту len(s) == 0.
Возврат nil-среза из функции, когда код дальше делает s = append(s, ...) и ожидает, что срез не nil для проверок. Это безопасно, так как append работает с nil, но последующая проверка if s == nil будет ложно положительной. Если это важно, лучше возвращать пустой срез.
Путаница при использовании reflect.DeepEqual: DeepEqual(nilSlice, emptySlice) возвращает false, потому что nil и не-nil — разные значения.
Исправление: при сравнении содержимого приводить оба к пустым срезам или сравнивать длины.

Возможные дополнительные вопросы интервьюера

Что будет, если сделать s := make([]int, 0); s = s[:0]?
Получится пустой срез с тем же указателем на zerobase (или выделенный массив, если cap > 0). Если cap > 0, то array не nil и не zerobase, а указывает на реальный массив; len=0. Это всё ещё не nil.

Можно ли сериализовать nil-срез как [] в JSON?
Только если определить кастомный маршалинг или использовать omitempty в структуре? Нет, encoding/json сериализует nil-срез как null. Чтобы получить [], нужно инициализировать поле как пустой срез []T{}. Важно помнить об этом при проектировании API.

Что такое карта (`map`)?

Краткий ответ (30–60 секунд)

Карта (map) в Go — это встроенная хеш-таблица, отображающая ключи одного типа в значения другого типа. Она реализована как неупорядоченная коллекция пар ключ-значение с доступом по ключу за амортизированное O(1). Карта является ссылочным типом: при присваивании или передаче в функцию копируется указатель на внутреннюю структуру hmap, поэтому изменения видны всем ссылкам. Нулевое значение карты — nil, попытка записи в nil-карту вызывает панику, чтение — возвращает нулевое значение типа значения и false во второй переменной.

Развёрнутый ответ

Карты в Go — это мощный инструмент, используемый повсеместно. Объявление: var m map[K]V (nil-карта), m := make(map[K]V), m := map[K]V{key: val}. Ключи должны быть сравнимыми (== и !=), значения — любого типа. Карта обеспечивает быстрый доступ, добавление, удаление, проверку наличия.

m := map[string]int{"a": 1}
v, ok := m["a"]
delete(m, "a")

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

Под капотом (internals)

Внутреннее представление — структура hmap (см. src/runtime/map.go). Карта содержит указатели на массив «бакетов» (buckets). Каждый бакет хранит до 8 пар ключ-значение. При коллизиях используются цепочки бакетов (overflow buckets). Доступ: хеш ключа разбивается на старшие и младшие биты; старшие биты (top hash) используются для быстрого поиска внутри бакета, младшие — для выбора бакета. Рост происходит при превышении loadFactor (6.5) или переполнении overflow buckets. Эвакуация данных выполняется инкрементально при операциях с картой, чтобы избежать длительных пауз.

Типичные ошибки кандидатов

Запись в nil-карту: var m map[string]int; m["key"] = 1 → panic: assignment to entry in nil map.
Исправление: инициализировать карту через make или литерал.
Использование несравнимых типов как ключей: срезы, функции, карты, структуры, содержащие эти типы — не могут быть ключами, компилятор запретит.
Исправление: преобразовывать к строке (например, через fmt.Sprint или хеш), или использовать структуру из сравнимых полей.
Итерация с ожиданием порядка: код, полагающийся на порядок обхода (например, при сериализации), будет нестабилен.
Исправление: собрать ключи в срез, отсортировать и итерироваться по ним.
Гонка при конкурентном доступе: чтение и запись из нескольких горутин без синхронизации — гонка данных, детектируемая race detector, и может привести к повреждению карты.
Исправление: использовать sync.RWMutex или sync.Map для специфических сценариев.

Возможные дополнительные вопросы интервьюера

Можно ли использовать указатели в качестве ключей?
Да, если тип указателя сравним (все указатели сравнимы). Сравниваются значения самих указателей (адреса), а не данные, на которые они указывают.

Что вернёт len(m) для nil-карты?
0. Длина nil-карты определена как 0.

Как устроена карта (`hmap`)?

Краткий ответ (30–60 секунд)

Карта в Go внутри представлена структурой runtime.hmap (объявлена в runtime/map.go). Основные поля: count (количество элементов), flags (флаги, например, итерации или записи), B (логарифм числа бакетов, всего 2^B бакетов), buckets (указатель на массив бакетов), oldbuckets (старый массив при эвакуации), nevacuate (прогресс эвакуации). Каждый бакет (bmap) содержит до 8 ключей и 8 значений, а также массив tophash (старшие байты хеша для быстрой фильтрации) и указатель на overflow bucket. Карта автоматически расширяется, когда количество элементов превышает loadFactor * 2^B или когда цепочки overflow становятся слишком длинными.

Развёрнутый ответ

Структура hmap инициализируется при вызове make (рантайм-функция makemap). Поля:

type hmap struct {
    count     int // # live cells == size of map
    flags     uint8 // iterator, writing, etc.
    B         uint8  // log_2 of # of buckets (может быть до 63)
    noverflow uint16 // примерное количество overflow buckets
    hash0     uint32 // hash seed (рандомизируется при старте)
    buckets    unsafe.Pointer // массив из 2^B Buckets
    oldbuckets unsafe.Pointer // предыдущий массив при эвакуации
    nevacuate  uintptr        // счётчик прогресса эвакуации
    extra *mapextra // указатели на overflow и старые overflow
}

Бакет bmap:

type bmap struct {
    tophash [bucketCnt]uint8 // bucketCnt = 8
    // потом идут ключи и значения, без имён, доступ через указатели
    // overflow указатель
}

Ключи и значения хранятся раздельно: сначала все 8 ключей подряд, потом все 8 значений, что улучшает выравнивание (padding) и производительность памяти.

Под капотом (internals)

Функция mapaccess (чтение) вычисляет хеш ключа (с seed hash0), определяет номер бакета bucket = hash & bucketMask(h.B). Внутри бакета используется tophash (старший байт хеша) для быстрой отбраковки несовпадающих ключей (byte compare), затем проверка полным равенством ключа. При эвакуации возможно обращение к oldbuckets. Запись (mapassign) аналогична, но при заполненном бакете создаётся overflow бакет и связывается с основным. Удаление (mapdelete) помечает tophash как emptyRest и сдвигает элементы для линеаризации цепочки (чтобы избежать ухудшения поиска).

Типичные ошибки кандидатов

Предположение о простом хранении ключей и значений в одном бакете без overflow: это приводит к недооценке сложности при большом числе коллизий.
Исправление: понимать, что каждая цепочка overflow может расти, и время доступа может деградировать до O(n) в худшем случае (но сбалансировано ростом).
Игнорирование того, что hmap содержит seed hash0, рандомизируемый при старте программы. Это делает невозможным предсказание порядка, но также защищает от DoS-атак через подбор коллизий.
Исправление: принять рандомизированный порядок, не полагаться на него.
Незнание инкрементальной эвакуации: полагать, что карта сразу после расширения не использует старые бакеты — на самом деле старые данные могут всё ещё быть в oldbuckets, и доступ обрабатывает оба массива, пока эвакуация не завершена.

Возможные дополнительные вопросы интервьюера

Что такое flags в hmap и как они помогают обнаружить конкурентную запись?
Флаг hashWriting устанавливается при начале записи и сбрасывается в конце. Если горутина видит этот флаг при операции, происходит фатальная ошибка: concurrent map writes (или concurrent map read and map write). Это механизм детектирования на уровне рантайма без синхронизации.

Как вычисляется B при make(map[K]V, hint)?
makemap вызывает overLoadFactor для подбора минимального B, при котором hint <= loadFactor * 2^B и нет слишком большого числа overflow. Это позволяет выделить адекватный массив бакетов.

Что такое бакет (`bucket`) в карте?

Краткий ответ (30–60 секунд)

Бакет — это фундаментальная единица хранения данных в Go-карте. Каждый бакет вмещает до 8 пар ключ-значение и содержит массив tophash (старшие байты хешей) для быстрой фильтрации, а также указатель на следующий overflow-бакет для разрешения коллизий. Вся карта состоит из массива из 2^B бакетов. Индекс бакета определяется младшими битами хеша ключа, а tophash используется для поиска внутри бакета без сравнения полных ключей для всех элементов.

Развёрнутый ответ

Внутренняя структура bmap оптимизирована для компактности и кеш-локальности. Фактическое расположение полей в памяти после tophash таково (не экспортируется, но определено в runtime/map.go):

tophash [8]uint8 — хранит старший байт хеша каждого элемента; специальные значения emptyOne, emptyRest для отметки удалённых слотов.
keys [8]K — блок из 8 ключей.
values [8]V — блок из 8 значений.
overflow *bmap — указатель на следующий бакет.

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

Под капотом (internals)

Для бакета используется тип bmap, но только первое поле (tophash) определено статически; остальные поля компилятор вычисляет через типы ключа и значения (используется unsafe.Pointer арифметика). В функции mapaccess примерно так:

Вычислить хеш.
b := hash & bucketMask(h.B), чтобы получить указатель на бакет buckets[b].
top := tophash(hash) — старший байт.
Идём по цепочке бакетов: для каждого бакета b итерируем tophash[i]. Если совпадает и ключ равен, возвращаем значение.
Если нашли emptyRest, дальше искать нет смысла.

Типичные ошибки кандидатов

Представление, что бакет содержит ровно один ключ-значение: на самом деле до восьми, и это ключевая оптимизация.
Исправление: знать про bucketCnt = 8 и уметь объяснить, почему это ускоряет поиск (меньше промахов кеша, один cache line).
Незнание про tophash и его роль в быстром отсеве: без tophash пришлось бы сравнивать полный ключ для каждого слота, что медленно для больших ключей.
Исправление: рассказать, что tophash — это 1 байт, и сравнение целых байтов дёшево.
Заблуждение, что overflow buckets используются только при коллизиях полных хешей: на самом деле overflow возникает, когда в основном бакете нет свободных слотов, даже если хеши разные (т.е. при заполнении бакета). Это тоже коллизия на уровне индекса бакета.

Возможные дополнительные вопросы интервьюера

Сколько памяти занимает бакет для map[int64]int64?
tophash — 8 байт, ключи 88=64 байта, значения 88=64 байта, указатель overflow — 8 байт; итого 144 байта на бакет. Плюс служебные выравнивания.

Почему максимальное количество элементов в бакете выбрано 8?
Это компромисс, определённый разработчиками: соответствует размеру cache line (64 байта), что позволяет загрузить tophash и части ключей/значений за одно обращение к памяти. Экспериментально показано хорошее поведение для большинства нагрузок.

Что такое overflow bucket?

Краткий ответ (30–60 секунд)

Overflow bucket — это дополнительный бакет, присоединённый к основному бакету через указатель overflow, когда основной бакет полностью заполнен (8 элементов). Они образуют цепочку (linked list) в пределах одного индекса бакета карты. Overflow buckets используются для разрешения коллизий и переполнения, позволяя хранить более 8 элементов с одним и тем же индексом бакета. Однако длинные цепочки деградируют производительность, поэтому карта инициирует расширение, когда среднее количество overflow buckets становится велико (обычно при count > 2^B и слишком много overflow).

Развёрнутый ответ

Overflow бакеты аллоцируются динамически при необходимости. При инициализации карты может быть предварительно выделено небольшое количество overflow бакетов (если указан размер через make с hint). Каждый бакет хранит указатель на следующий overflow бакет; обход выполняется последовательно. Поиск в цепочке overflow — линейный, поэтому их стараются минимизировать. При расширении карты overflow бакеты могут быть присоединены к новым основным бакетам и эвакуированы позже.

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

Под капотом (internals)

В hmap.extra *mapextra хранятся:

type mapextra struct {
    overflow    *[]*bmap
    oldoverflow *[]*bmap
    nextOverflow *bmap
}

Когда бакет заполняется, mapassign проверяет nextOverflow; если есть предварительно аллоцированные overflow бакеты, берёт оттуда, иначе вызывает newobject для создания нового бакета и добавляет в срез overflow. При эвакуации старые overflow бакеты могут быть перемещены в новые основные бакеты, и их указатели обновляются.

Типичные ошибки кандидатов

Думать, что overflow buckets возникают только при хеш-коллизиях полных ключей: на самом деле они возникают просто при заполнении слота индекса; множество разных хешей могут попасть в один бакет.
Исправление: четко разделять коллизию (совпадение хеша) и переполнение бакета (совпадение младших бит).
Недооценка стоимости длинных цепочек overflow: при большом количестве записей в один бакет поиск становится O(n) по цепочке. Карта растёт не только по load factor, но и по «слишком много overflow» (проверка tooManyOverflowBuckets).
Исправление: понимать, что карта сама мониторит overflow и инициирует рост при необходимости.

Возможные дополнительные вопросы интервьюера

Что произойдёт, если карта заполнится до такой степени, что все бакеты и их overflow будут использованы?
Дальнейшие вставки будут добавлять новые overflow бакеты, пока не будет достигнут порог роста. Рост увеличит число основных бакетов, элементы из overflow распределятся по новым бакетам, и цепочки станут короче.

Можно ли вручную управлять overflow бакетами?
Нет, это деталь реализации, программист не имеет к ним доступа. Управление полностью внутри рантайма.

Почему порядок обхода карты не гарантирован?

Краткий ответ (30–60 секунд)

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

Развёрнутый ответ

Карта в Go — это хеш-таблица, и её порядок зависит от хеш-функции, seed которой генерируется случайно при старте программы. Более того, итератор использует случайный стартовый индекс: startBucket = fastrand() & bucketMask(h.B), а также случайное смещение offset внутри бакета. Это делает порядок обхода непредсказуемым даже на одной и той же карте в рамках одного запуска (при повторном range порядок будет другим). При эвакуации старые бакеты и новые перемешаются, что дополнительно меняет порядок. Таким образом, полагаться на порядок — значит закладывать хрупкость и нестабильность.

for k, v := range m {
    // порядок случаен
}

Под капотом (internals)

Итератор реализован структурой hiter в runtime/map.go. При вызове mapiterinit определяются стартовый бакет и offset через fastrand(). Обход идёт по бакетам от стартового, по кольцу, внутри каждого бакета элементы перебираются от offset до конца, затем с начала до offset. Это обеспечивает полный обход без повторений. During iteration, если карта изменяется (добавление/удаление), поведение специфицировано: можно удалять существующие элементы без проблем, но добавление может быть невидимым или вызвать панику, если количество бакетов изменилось (рост). Однако гарантий стабильного порядка нет.

Типичные ошибки кандидатов

Сортировка ключей и вставка в порядке сортировки для «стабильного» обхода: это не гарантирует порядок при итерации, потому что итератор игнорирует порядок вставки.
Исправление: собрать ключи, отсортировать, итерироваться по срезу ключей.
Зависимость от порядка при тестировании: тесты, сравнивающие вывод fmt.Println(m) ломаются из-за рандомизации.
Исправление: использовать cmp.Diff с сортировкой или проверять наличие элементов без учёта порядка.
Попытка предсказать порядок, меняя seed: seed задаётся при старте программы (или через GORACE), но это всё равно меняется между запусками.

Возможные дополнительные вопросы интервьюера

Можно ли реализовать упорядоченную карту на основе встроенной?
Только поверхностно: поддерживать срез ключей (insertion order) и синхронизировать при добавлении/удалении, либо использовать сторонние библиотеки (например, github.com/elliotchance/orderedmap). Встроенной нет.

Почему при итерации во время эвакуации порядок особенно непредсказуем?
Потому что итератор должен обходить как старые, так и новые бакеты, при этом эвакуация может ещё не завершиться, что приводит к перемешанным элементам и дополнительным изменениям на лету.

Что происходит при расширении (`resize`) карты?

Краткий ответ (30–60 секунд)

Карта расширяется, когда среднее количество элементов на бакет превышает loadFactor (6.5), или когда образовалось слишком много overflow-бакетов. При расширении создаётся новый массив бакетов в два раза большего размера (B увеличивается на 1) либо того же размера (при “same-size” росте для устранения overflow). Старый массив становится oldbuckets. Эвакуация данных происходит инкрементально — при последующих операциях доступа к карте (запись, чтение) по одному-двум бакетам за раз, что позволяет избежать длительных пауз. Процесс продолжается до полного переноса всех данных, после чего oldbuckets освобождается.

Развёрнутый ответ

Условия роста проверяются в mapassign и mapdelete. Два типа расширения:

Рост из-за load factor: count > loadFactor * 2^B и B < 63. Удваиваем количество бакетов (B += 1). Новый массив в два раза больше; каждый старый бакет расщепляется на два новых (по одному дополнительному биту хеша).
Same-size рост: когда количество overflow бакетов слишком велико (noverflow >= 2^B для маленьких карт или >= 2^15 для B > 15). Размер остаётся тем же, но элементы перераспределяются по существующим бакетам, чтобы ликвидировать длинные цепочки overflow. Это более редкий случай.

И в том, и в другом случае создаётся newbuckets, oldbuckets = h.buckets. Флаг h.flags не меняется (не используется специальный флаг эвакуации, просто проверяется h.oldbuckets != nil). Эвакуация одного бакета выполняется функцией evacuate. Прогресс отслеживается в nevacuate.

Под капотом (internals)

Функция hashGrow выделяет новый массив и устанавливает его как buckets, а oldbuckets указывает на старый. Затем в методах mapassign и mapaccess перед основной работой вызывается evacuate для бакетов nevacuate и nevacuate+1 (если расщепление). Для same-size роста эвакуируется только один бакет за раз. В процессе эвакуации данные из старого бакета (и его overflow) переносятся в соответствующие новые бакеты; после завершения старый бакет помечается как эвакуированный (tophash[0] = evacuatedX или evacuatedY). После того как все старые бакеты эвакуированы, oldbuckets освобождается.

Типичные ошибки кандидатов

Мнение, что карта растёт только при достижении load factor: забывают про same-size рост, который может произойти при множестве коллизий и небольшом количестве элементов.
Исправление: помнить про tooManyOverflowBuckets.
Предположение, что эвакуация происходит в отдельной горутине или фоново: эвакуация встроена в операции с картой; это означает, что единичная операция может стать дороже из-за копирования целого бакета, но без задержек GC.
Исправление: понимать инкрементальный характер.
Игнорирование того, что итерация во время эвакуации должна обрабатывать оба массива: итератор проверяет oldbuckets и при необходимости обходит старые бакеты, которые ещё не эвакуированы, что может повлиять на производительность.

Возможные дополнительные вопросы интервьюера

Может ли случиться так, что карта постоянно растёт, но количество элементов не меняется?
При постоянном добавлении и удалении и при определённых условиях (например, нагрузка с коллизиями) может происходить same-size рост. Бесконечного роста не будет, потому что рост происходит по триггерам, которые сбрасываются.

Как карта определяет, в какой из двух новых бакетов поместить элемент при удвоении?
Использует дополнительный бит хеша (обычно hash & (1 << B)) — если бит 0, элемент идёт в нижний бакет (x), если 1 — в верхний (y). Это стандартный подход consistent hashing.

Что такое коллизия хешей (`hash collision`)?

Краткий ответ (30–60 секунд)

Коллизия хешей в карте Go — это ситуация, когда два разных ключа дают одинаковый хеш-код (значение хеш-функции). Поскольку хеш-функция сжимает бесконечное множество ключей в 64-битное (или 32-битное на 32-разрядных системах) значение, коллизии неизбежны. При коллизии оба ключа попадают в один бакет (и даже в один и тот же слот tophash может совпасть). Карта разрешает коллизии методом цепочек overflow бакетов и проверкой полного ключа на равенство. Коллизии замедляют поиск, так как приходится сравнивать больше ключей в цепочке, но не нарушают корректность.

Развёрнутый ответ

Go использует хеш-функции, реализованные в рантайме для каждого типа ключа (например, memhash для строк, f64hash для float64). Хеш-функция даёт 64-битное значение (на 64-битных платформах). Младшие биты определяют индекс бакета, старший байт — tophash. Даже если два ключа имеют одинаковый полный хеш, они могут отличаться; карта сравнивает сами ключи. Таким образом, коллизия разрешается корректно, но производительность деградирует:

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

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

Под капотом (internals)

Функции хеширования для строк: runtime.memhash с seed hash0. Для интерфейсов и сложных типов генерируется специфический хеш. Внутри бакета после проверки tophash идёт сравнение полного ключа вызовом t.key.equal(key, k). Для указателей равенство простое. Таким образом, стоимость коллизии — дополнительные сравнения.

Типичные ошибки кандидатов

Неправильное представление, что карта хранит только хеш, а не ключ, и при коллизии может потерять данные. Это не так; ключи хранятся и сравниваются.
Исправление: помнить про полное сравнение ключей.
Создание типа с плохой хеш-функцией (например, структура без экспорта полей для хеширования): Go предоставляет приличные хеш-функции, но для пользовательских типов (если они не comparable, их нельзя в ключ). Для comparable типов используется встроенная.
Попытка использовать unsafe для создания коллизий: сложно, т.к. seed рандомен.

Возможные дополнительные вопросы интервьюера

Может ли карта с ключами float64 страдать от коллизий NaN?
Да, NaN != NaN, поэтому NaN как ключ не найдётся после вставки, но может быть вставлен каждый новый NaN как уникальный ключ из-за разного битового представления? В Go карта нормально обрабатывает NaN как любой другой float64, полное сравнение использует машинное сравнение; но из-за особенностей NaN (не равен самому себе) поиск может не найти ранее вставленный NaN. Это известная проблема, лучше избегать NaN в ключах.

Как в Go обеспечивается, что два разных ключа с одинаковым tophash всё равно корректно различаются?
После совпадения tophash вызывается t.key.equal(key, k) для полного бинарного сравнения.

Что такое `load factor`?

Краткий ответ (30–60 секунд)

Load factor (коэффициент заполнения) карты определяется как отношение количества хранимых элементов (count) к количеству бакетов (2^B), умноженное на коэффициент загрузки бакета (по сути, среднее число элементов на бакет). В Go пороговое значение load factor, при котором инициируется расширение карты, равно 6.5. Это значит, что в среднем на бакет приходится 6.5 элементов (при максимуме 8). Когда count > 6.5 * 2^B, запускается удвоение числа бакетов.

Развёрнутый ответ

Константа loadFactorNum и loadFactorDen определены в рантайме как 13 и 2, что даёт 6.5. Это значение выбрано эмпирически для баланса между использованием памяти и производительностью доступа. Порог в 6.5 элементов на бакет означает, что многие бакеты почти полны, и вероятность overflow возрастает. При превышении порога карта увеличивает вместимость вдвое, чтобы снизить среднюю заполненность и уменьшить длину цепочек overflow, тем самым сохраняя амортизированное O(1) время операций.

Формула проверки: if count > loadFactorNum*(bucketShift(B)/loadFactorDen) — упрощённо. Load factor влияет только на рост с удвоением; same-size рост вызывается отдельно.

Под капотом (internals)

В runtime/map.go функция overLoadFactor(hmap) bool вычисляет:

return h.count > bucketCnt*loadFactorNum/h.loadFactorDen* (1<<B) / bucketCnt ...

Но точная реализация: h.count > loadFactorNum*((1<<B)/loadFactorDen). (с округлением). Константа loadFactorNum=13, loadFactorDen=2.

Типичные ошибки кандидатов

Путать load factor с коэффициентом заполнения конкретного бакета: load factor — глобальный, учитывает все бакеты, а не отдельные.
Исправление: разделять метрики.
Считать, что карта растёт только при заполнении всех бакетов полностью (8 элементов): на самом деле рост происходит раньше, при 6.5 в среднем, чтобы предотвратить лавину overflow.
*Пренебрежение формулой и предположение, что карта с 10 элементами обязательно имеет 2 бакета (B=1, 2^1=2, 6.52=13 > 10), поэтому она не растёт. Действительно, рост произойдёт при >13 элементах. Это надо учитывать при оценке аллокаций.

Возможные дополнительные вопросы интервьюера

Почему load factor не равен 1?
Потому что при 1 будет много коллизий и overflow. 6.5 даёт хороший компромисс между памятью и скоростью, учитывая, что бакет вмещает 8 элементов.

Можно ли изменить load factor?
Нет, он вшит в рантайм. Но можно вручную создать карту с большим B через make(map[K]V, hugeHint), чтобы уменьшить load factor.

Почему карта не потокобезопасна (not thread-safe)?

Краткий ответ (30–60 секунд)

Карта в Go спроектирована без внутренних блокировок ради максимальной производительности в однопоточной среде (или при явной внешней синхронизации). Добавление мьютекса на каждую операцию карты привело бы к значительным накладным расходам даже для программ, не использующих конкурентность. Вместо этого Go предоставляет примитивы синхронизации (sync.Mutex, sync.RWMutex) и специализированную sync.Map для определённых сценариев. При конкурентных операциях без внешней защиты возникает гонка данных — неопределённое поведение, которое может привести к повреждению внутренних структур карты и краху программы.

Развёрнутый ответ

Дизайн карты оптимизирован для fast path без блокировок. Внутренняя структура hmap модифицируется при вставке, удалении, эвакуации. Одновременные запись и чтение или запись и запись без синхронизации нарушают инварианты (например, указатели на overflow бакеты могут быть изменены во время чтения). Рантайм Go включает простой детектор: при старте операции записи устанавливается флаг hashWriting, и если другая горутина обнаруживает этот флаг при операции, происходит фатальная ошибка «concurrent map writes» (или read + write). Однако это только детектор, не гарантирующий полную безопасность: гонка может произойти и не быть поймана сразу, но может вызвать порчу данных.

m := make(map[int]int)
go func() { for i:=0; i<1000; i++ { m[i]=i } }()
go func() { for i:=0; i<1000; i++ { _ = m[i] } }() // race

Запуск с -race покажет гонку.

Под капотом (internals)

Флаг hashWriting находится в h.flags. При вызове mapassign (запись) или mapdelete:

Если флаг уже установлен, паника: concurrent map writes.
Устанавливается флаг.
Выполняется операция.
Сбрасывается флаг.
При mapaccess (чтение) проверяется флаг; если установлен, также паника concurrent map read and map write. Однако эта проверка делается не атомарно? Она делается обычной операцией, поэтому гонка возможна на уровне процессора, но рантайм гарантирует, что при пересекающихся операциях паника почти всегда сработает. Тем не менее, отсутствие паники не означает отсутствие гонки данных, просто повезло.

Типичные ошибки кандидатов

Использование sync.Mutex только для записи, но не для чтения: считают, что чтение безопасно. Из-за эвакуации и изменения внутренних указателей чтение во время записи может дать мусор.
Исправление: защищать мьютексом и чтение, и запись, либо sync.RWMutex (RLock для чтения).
Надежда на встроенную защиту: «я использую только чтение, и запись редкая, может проскочить» — недопустимо.
Исправление: всегда синхронизировать.
Использование sync.Map без разбора: он имеет узкую нишу (кеши с преобладанием чтения, ключи стабильны). В других случаях он медленнее обычной карты с мьютексом.
Исправление: бенчмаркать и выбирать подходящий механизм.

Возможные дополнительные вопросы интервьюера

Что произойдёт, если одна горутина читает, а другая в этот момент удаляет элементы?
Без синхронизации — состояние гонки, может быть прочитано частично обновлённое значение или произойти паника из-за флага записи (delete устанавливает флаг). С синхронизацией — безопасно.

Почему sync.RWMutex на чтение всё равно требует атомарности при росте карты?
Потому что RLock не защищает от деградации указателей, если пишущая горутина изменяет buckets. Нужно брать full lock при модификации. RLock допустим, только когда нет пишущих.

Что будет при конкурентной записи (concurrent write) в карту?

Краткий ответ (30–60 секунд)

Несинхронизированная конкурентная запись в одну карту из нескольких горутин вызывает гонку данных. Рантайм Go обнаруживает такую ситуацию с высокой вероятностью и немедленно вызывает фатальную ошибку fatal error: concurrent map writes (или concurrent map read and map write). Программа аварийно завершается. Без детектора возможны повреждение структуры карты, потеря данных или некорректные результаты чтений.

Развёрнутый ответ

Механизм детектирования основан на флаге hashWriting в структуре hmap. При старте операции записи (mapassign, mapdelete) флаг проверяется: если уже установлен — throw("concurrent map writes"). Флаг сбрасывается после завершения операции. Однако между проверкой и установкой флага возможны гонки на низком уровне, но они тоже приводят к панике. Если горутина делает чтение, а другая в этот момент пишет, чтение может увидеть установленный флаг и тоже паниковать с сообщением concurrent map read and map write. Важно: это детектирование не является гарантированным (особенно при агрессивной оптимизации), но на практике очень надёжно. Главное — такая ситуация недопустима.

Пример:

m := map[int]int{}
go func() { for i := 0; ; i++ { m[i] = i } }()
go func() { for i := 0; ; i++ { m[i] = i } }()
time.Sleep(time.Second) // fatal error

Под капотом (internals)

Флаг hashWriting — это бит 4 (или другой) в h.flags. Операции:

if h.flags&hashWriting != 0 {
    throw("concurrent map writes")
}
h.flags ^= hashWriting
...
h.flags ^= hashWriting

Для чтения: if h.flags&hashWriting != 0 { throw(...) }. Так как доступ к h.flags не атомарный, возможны пропуски, но из-за того, что операции короткие, и флаг устанавливается на всё время критической секции, пересечения ловятся.

Типичные ошибки кандидатов

Полагаться на то, что конкурентная запись «иногда работает»: программа может случайно не падать при малом количестве операций, что создаёт ложное чувство безопасности.
Исправление: всегда использовать синхронизацию, тестировать с -race.
Использовать recover для обработки паники карты: fatal error не является обычной паникой, её нельзя перехватить; программа завершается.
Исправление: не допускать гонок.
Считать, что если запись защищена мьютексом, то чтение можно делать без блокировки: из-за эвакуации и изменения внутренних указателей чтение без блокировки может привести к прочтению неконсистентных данных или панике при обращении к эвакуируемым бакетам.
Исправление: RLock для чтения при использовании sync.RWMutex.

Возможные дополнительные вопросы интервьюера

Какова вероятность пропуска детектирования конкурентной записи?
Крайне мала на практике; рантайм специально делает установку флага одной из первых операций. Однако в теории при очень быстрых последовательных операциях без перекрытия по времени гонки данных всё равно присутствуют, но детектор не сработает. Это UB.

Можно ли сделать карту безопасной для конкурентных операций без внешнего мьютекса, если каждая горутина пишет в свой непересекающийся набор ключей?
Нет, потому что внутренняя структура (бакеты, overflow) модифицируется глобально. Даже вставка разных ключей может затронуть общие структуры (рост, добавление overflow). Без синхронизации нельзя.

Что такое строка (`string`)?

Краткий ответ (30–60 секунд)

В Go строка — это неизменяемая последовательность байтов. Она представляет собой структуру из двух полей: указатель на базовый массив байт и длина (количество байт). Строки иммутабельны: после создания их содержимое нельзя изменить. Длина строки возвращает число байт, но для корректной работы с Unicode-символами нужно использовать пакет unicode/utf8 и цикл range. Нулевое значение строки — "" (пустая строка). Строки можно сравнивать операторами ==, !=, а также конкатенировать (+).

Развёрнутый ответ

Строки в Go — это встроенный тип, основа для текстовой обработки. Они не являются срезами байт, хотя внутренне похожи (указатель + длина, но без ёмкости). Тип string поддерживает индексацию по байтам: s[i] даёт byte. Строки могут содержать произвольные байты, включая \x00. Иммутабельность гарантирует безопасность при совместном использовании и упрощает многопоточность (str безопасна для чтения без синхронизации).

s := "Hello"
fmt.Println(len(s)) // 5
b := s[1]          // 'e' (byte)
// s[1] = 'x'      // ошибка компиляции

Под капотом (internals)

Внутреннее представление string в рантайме: reflect.StringHeader:

type StringHeader struct {
    Data uintptr // указатель на байты
    Len  int
}

При компиляции строковые литералы размещаются в сегменте данных только для чтения. При создании подстроки (через s[i:j]) создаётся новая строковая структура с тем же указателем (смещённым) и новой длиной, данные не копируются. Это эффективно, но может привести к утечке памяти (удержанию большого блока памяти маленькой подстрокой).

Типичные ошибки кандидатов

Обращение по байтовому индексу в многобайтовых строках: s[i] возвращает байт, а не руну; может разорвать символ юникода.
Исправление: использовать []rune(s) или range.
Попытка изменить строку через приведение к []byte и обратно: bs := []byte(s); bs[0] = 'X'; s = string(bs) — это создаёт новую строку, а не модифицирует исходную. Потокобезопасность соблюдается, но неоптимально при частых изменениях.
Исправление: использовать strings.Builder для построения строк.
Сравнение строк с помощью > и <: допустимо, но порядок лексикографический побайтовый, не по Unicode codepoint. Для локализованного сравнения нужен collate.
Исправление: для естественного порядка используйте golang.org/x/text/collate.

Возможные дополнительные вопросы интервьюера

Что произойдёт, если взять подстроку из очень большой строки и освободить основную?
Подстрока сохраняет ссылку на весь исходный массив байт, поэтому большой блок памяти не будет собран GC. Чтобы избежать, можно скопировать подстроку в новую строку через string([]byte(substr)) (или strings.Clone в Go 1.20+).

Является ли строка в Go нуль-терминированной, как в C?
Нет, она хранит длину явно и может содержать нулевые байты в середине.

Как устроена строка?

Краткий ответ (30–60 секунд)

Строка в Go — это бинарный объект, состоящий из двух слов: указатель на непрерывный массив байт в памяти и целое число (длина в байтах). Это значение, а не срез; структура StringHeader имеет поля Data uintptr и Len int. Строки неизменяемы, поэтому базовый массив данных размещается в read-only сегменте памяти (для литералов) или в куче, но без возможности изменения. Благодаря этому заголовок строки может безопасно копироваться и передаваться по значению.

Развёрнутый ответ

Строка не имеет отдельного поля cap, потому что её нельзя расширить. При создании подстроки s2 := s[1:3] получается новый заголовок, где Data = s.Data + 1, Len = 2. Данные не копируются, пока подстрока существует. Это приводит к экономии памяти и времени, но может удерживать большие участки памяти, как описано ранее.

s := "hello"
hdr := (*reflect.StringHeader)(unsafe.Pointer(&s))
fmt.Printf("Data: %x, Len: %d\n", hdr.Data, hdr.Len)

Под капотом (internals)

В исходниках runtime/string.go определены функции concatstrings, slicebytetostring, stringtoslicebyte и т.д. Конвертация []byte в string (и обратно) обычно приводит к копированию данных, за исключением некоторых оптимизаций компилятора, когда можно безопасно использовать ту же память. С версии Go 1.22 некоторые преобразования стали бесплатными благодаря аллокации на стеке и escape analysis. Тем не менее, общее правило: string <-> []byte требует копирования.

Типичные ошибки кандидатов

Прямое изменение строки через unsafe: изменение read-only памяти через unsafe приведёт к фатальной ошибке (segmentation fault) или неопределённому поведению.
Исправление: никогда не модифицировать строку через unsafe, если не уверены, что память доступна для записи.
Забывать, что len возвращает байты, а не символы: len("Привет") == 12 (2 байта на русскую букву в UTF-8).
Исправление: использовать utf8.RuneCountInString.
Неверное преобразование []rune в строку: string(rs) работает, но создаёт новую строку из рун, перекодируя в UTF-8, что ОК. Однако часто забывают, что []rune может изменить длину.

Возможные дополнительные вопросы интервьюера

Как пустая строка представлена в памяти?
Указатель Data может быть nil или указывать на zerobase; Len = 0. Обычно обходится без аллокаций.

Можно ли сравнить строки через == быстрее, чем через strings.Compare?
Да, == для строк — встроенная операция, оптимизированная компилятором (использует memequal по длине и байтам). strings.Compare введён для реализации интерфейсов сравнения.

Почему строка неизменяема (immutable)?

Краткий ответ (30–60 секунд)

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

Развёрнутый ответ

Если бы строки были изменяемыми, то:

При передаче строки в функцию или горутину пришлось бы синхронизировать доступ.
Подстрока не могла бы безопасно ссылаться на оригинальный массив.
Карты с строковыми ключами потребовали бы перехеширования при каждой мутации строки.
Литералы могли бы быть случайно изменены, разрушив стабильность программы.
Благодаря иммутабельности строки могут размещаться в read-only памяти, что повышает безопасность и производительность.

Под капотом (internals)

Строковые литералы компилятор помещает в секцию .rodata исполняемого файла. При создании строки во время выполнения (например, string(bytes)) данные копируются в кучу. Рантайм не предоставляет API для изменения этих байтов. Конвертация []byte в string посредством unsafe может дать изменяемую строку (если базовый массив — срез), но это нарушает гарантии и опасно.

Типичные ошибки кандидатов

Использование unsafe для получения изменяемой строки из среза и модификация её: формально строка должна быть неизменяемой, и код, полагающийся на это (например, карты, использующие эту строку как ключ), может сломаться.
Исправление: не делать так; если нужна изменяемая последовательность, использовать []byte.
Создание новой строки путём многократной конкатенации + в цикле: приводит к множественным аллокациям и копиям, так как каждая конкатенация создаёт новую строку.
Исправление: применять strings.Builder.

Возможные дополнительные вопросы интервьюера

Можно ли реализовать изменяемую строку через структуру с полем []byte?
Да, именно так и делают: оборачивают []byte в тип и предоставляют методы. Но это уже не встроенная string. Встроенная строка неизменяема.

Почему в стандартной библиотеке нет метода для замены символа в строке?
Потому что это потребовало бы аллокации новой строки, что неэффективно; разработчик сам должен решить, как построить новую строку (через strings.Builder, strings.Replace и т.д.).

Что происходит при конкатенации строк?

Краткий ответ (30–60 секунд)

Конкатенация строк оператором + (или через +=) в Go приводит к созданию новой строки, в которую копируются байты всех операндов. Исходные строки не изменяются. При множественных конкатенациях (особенно в цикле) это ведёт к квадратичной сложности по памяти и времени из-за большого числа аллокаций и копирований. Рекомендуется использовать strings.Builder для эффективного построения строки, который минимизирует аллокации и копирования.

Развёрнутый ответ

Выражение s := s1 + s2 + s3 компилятор преобразует в вызов runtime-функции concatstring2 или concatstrings, которая выделяет буфер нужного размера (сумма длин) и копирует туда все части, затем возвращает строку, указывающую на этот буфер. Память выделяется в куче, если строка не уходит в стек через escape analysis (маловероятно для динамических строк). При += в цикле:

s := ""
for i := 0; i < n; i++ {
    s += str
}

Каждая итерация создаёт новую строку, содержащую накопленные данные плюс str, что ведёт к O(n^2) копий. Для n=1000 это может быть терпимо, но для больших n — катастрофа.

Под капотом (internals)

Функция concatstrings (в runtime/string.go) принимает срез строк и возвращает строку. Она считает суммарную длину, выделяет буфер через rawbyteslice (с учётом выравнивания), копирует содержимое, затем вызывает slicebytetostring для преобразования буфера в строку. Буфер не сохраняется, и после создания строки GC может его освободить? На самом деле результат — это строка, которая владеет памятью (указатель на буфер). Память выделена mallocgc, и строка будет удерживать её до тех пор, пока достижима.

Типичные ошибки кандидатов

Конкатенация в цикле без Builder: типичная проблема производительности.
Исправление: var b strings.Builder; b.WriteString(s); ...; return b.String().
Использование fmt.Sprintf для простой конкатенации: оно медленнее из-за разбора форматной строки, лучше использовать + для пары строк или Builder.
Исправление: выбирать инструмент по ситуации; + для 2-3 строк приемлемо.
Забывать про strings.Builder.Grow для предварительного резервирования памяти: снижает аллокации.
Исправление: b.Grow(totalLen).

Возможные дополнительные вопросы интервьюера

Что эффективнее для склеивания массива строк: strings.Join или цикл с Builder?
strings.Join внутри использует Builder с предварительным подсчётом общей длины и одним выделением, так что он оптимален.

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

Что такое `[]byte` и как его преобразовать в `string`?

Краткий ответ (30–60 секунд)

[]byte — это срез байт, изменяемый тип данных, представляющий последовательность байтов. Преобразование []byte в string выполняется простым приведением типа: str := string(b). При этом создаётся новая строка, в которую копируются все байты из среза (глубокое копирование). Полученная строка неизменяема и не связана с исходным срезом. Обратное преобразование []byte(str) также создаёт копию, возвращая изменяемый срез байт. Исключения могут быть при оптимизациях компилятора для локальных временных срезов, но полагаться на отсутствие копирования не следует.

Развёрнутый ответ

Это базовый механизм для взаимодействия строк и бинарных данных. Приведение string(b) выделяет новую память (кроме случаев, где компилятор может доказать, что это безопасно: например, string(b) где b — результат []byte("literal"), но не всегда). Преобразование требует времени и памяти, поэтому в критичных к производительности местах стоит избегать лишних конвертаций.

b := []byte("hello")
s := string(b)  // копия, изменения b не повлияют на s

Под капотом (internals)

Функция slicebytetostring в рантайме: выделяет буфер размером len(b), копирует в него содержимое среза, затем конструирует строку с этим буфером. В некоторых случаях (например, string(bytestr), где срез создаётся из строкового литерала и не утекает) компилятор может выполнить преобразование без копирования, размещая строку в read-only памяти? В Go 1.22 есть оптимизация для string(b) когда b — это временный срез, полученный из константной строки? Всё сложно, но общее правило — копирование. Обратное преобразование stringtoslicebyte также делает копирование, чтобы гарантировать изменяемость.

Типичные ошибки кандидатов

Изменение среза после преобразования в строку в надежде, что строка обновится: строка уже независима.
Исправление: воспринимать приведение как конструктор копии.
Частые преобразования в цикле: string(b) на каждой итерации, когда можно работать напрямую с []byte или сохранить строку.
Исправление: по возможности избегать множественных конвертаций.
Использование unsafe для избежания копирования: *(*string)(unsafe.Pointer(&b)) — полученная строка ссылается на тот же массив, что и срез, но если срез будет изменён, содержимое строки изменится, нарушая иммутабельность.
Исправление: использовать safe преобразование, если строка должна быть стабильной.

Возможные дополнительные вопросы интервьюера

При каких условиях string(b) не аллоцирует память?
Если компилятор может доказать, что срез b не будет изменяться после преобразования и его базовый массив неизменен, он может избежать копирования (например, для временных срезов на стеке). Но это детали реализации Go, не гарантировано семантикой.

Как преобразовать строку в []byte без копирования?
Только через unsafe: *(*[]byte)(unsafe.Pointer(&s)), но тогда вы получите изменяемый срез, указывающий на иммутабельную память строки; изменение приведёт к segfault, если память не в куче.

Что такое срез рун (`[]rune`)?

Краткий ответ (30–60 секунд)

[]rune — это срез Unicode кодовых точек (runes), каждая из которых представляет собой значение типа rune (псевдоним int32). В отличие от []byte, который хранит UTF-8 кодированную последовательность байт, []rune хранит символы как 32-битные целые, что позволяет индексировать и обрабатывать символы напрямую без декодирования. Преобразование []rune(s) из строки создаёт новый срез, декодируя UTF-8 строку в последовательность рун, что приводит к аллокации и копированию.

Развёрнутый ответ

Unicode строка в Go в памяти — это UTF-8. Для корректной работы с отдельными «символами» (рунами) удобно преобразовать строку в []rune. Это гарантирует, что каждый элемент среза — ровно одна рунa, и индексация r[0] даёт первый символ. Однако []rune потребляет больше памяти (4 байта на символ даже для ASCII). Используется для операций, где нужен произвольный доступ по позиции символа, подсчёт рун, модификация символов.

s := "Hello, 世界"
rs := []rune(s) // [72 101 108 108 111 44 32 19990 30028]
fmt.Println(len(rs)) // 9

Под капотом (internals)

Функция stringtoslicerune (в runtime/string.go) сначала подсчитывает количество рун (через utf8.RuneCountInString), выделяет срез []rune нужного размера и затем заполняет его с помощью decoderune. При обратном преобразовании string(rs) происходит перекодирование в UTF-8 с выделением нового буфера.

Типичные ошибки кандидатов

Сравнение длины []rune и исходной строки для определения количества символов и дальнейшая итерация по байтам: после преобразования работают с рунами, но забывают, что модификация среза рун не меняет исходную строку.
Исправление: понимать, что []rune — копия.
Частое преобразование больших строк в []rune ради единичного доступа к символу: это дорого.
Исправление: использовать utf8.DecodeRuneInString для итерации, если не нужен весь срез.
Использование rangе по строке напрямую: он уже итерирует по рунам без материализации всего среза. Многие новички дублируют работу.

Возможные дополнительные вопросы интервьюера

Как быстро получить N-ую руну строки без полного преобразования в []rune?
При помощи цикла с utf8.DecodeRuneInString или range, пропуская N-1 рун. Либо использовать strings.SplitAfter? Лучше utf8.DecodeRuneInString с подсчётом.

Чем отличается len([]rune(s)) от utf8.RuneCountInString(s)?
Оба возвращают количество рун, но []rune(s) аллоцирует полный срез, а utf8.RuneCountInString просто считает без аллокаций.

Как правильно работать с unicode в строках?

Краткий ответ (30–60 секунд)

Для корректной обработки Unicode в Go необходимо помнить, что строки — это UTF-8 байты. Следует использовать:

Цикл for _, r := range s для итерации по рунам.
utf8.RuneCountInString для подсчёта символов.
[]rune(s) только при необходимости произвольного доступа и модификации.
Пакет strings (содержит функции, безопасные для Unicode: ToUpperSpecial, Contains работает с рунами).
unicode/utf8 для декодирования и валидации UTF-8.
Никогда не обращайтесь к символам по байтовому индексу без учёта многобайтовости.

Развёрнутый ответ

Классические ошибки: slicing по байтовому индексу посередине руны, что порождает невалидный UTF-8. Корректный способ:

for pos, r := range s { // pos — байтовый индекс начала руны
    // обработка r
}

Для извлечения подстроки по символам используйте []rune или string([]rune(s)[start:end]), но это дорого. Можно использовать utf8string или segment.Index. Go 1.21+ представил strings.CutSuffix и т.п., но они работают на байтовом уровне. Чтобы получить первые N рун эффективно, пишут обход с подсчётом.

Под капотом (internals)

Встроенная функция rangе для строк компилируется в вызов runtime.decoderune, которая считывает следующие байты и возвращает руну и её размер. Это эффективнее, чем конвертация в []rune. Пакет utf8 предоставляет такие же низкоуровневые функции.

Типичные ошибки кандидатов

Использование len(s) как количество символов: возвращается число байт, что неверно.
Исправление: использовать utf8.RuneCountInString(s).
Срез по байтам без проверки границ рун: s[:5] может обрезать многобайтовый символ, сломав кодировку.
Исправление: если нужно обрезать с сохранением валидности UTF-8, использовать strings.Clone(s[:5]) после проверки, либо применить utf8.ValidString и функции из golang.org/x/text/unicode/norm.
Неинициализированные строки с невалидным UTF-8: Go допускает string([]byte{0xff,0xfe}), но операции типа range будут выдавать RuneError. Надо быть готовым к replacement character.
Исправление: валидировать входные строки через utf8.ValidString, если требуется гарантия.

Возможные дополнительные вопросы интервьюера

Как перевернуть строку, содержащую Unicode?
Преобразовать в []rune, перевернуть срез, затем обратно в строку. Или использовать unicode/utf8 для обратного хода с конца, но это сложнее.

Как определить, что строка в UTF-8 действительно корректна?
utf8.ValidString(s) bool.

Что такое `range` для строки?

Краткий ответ (30–60 секунд)

range при итерации по строке декодирует UTF-8 и перебирает руны (Unicode кодовые точки), возвращая на каждой итерации индекс (в байтах) начала текущей руны и саму руну. Если последовательность байт некорректна, возвращается utf8.RuneError (65533) с размером в 1 байт. Это безопасный способ посимвольного обхода без предварительного преобразования в []rune.

Развёрнутый ответ

Использование:

for index, runeValue := range s {
    fmt.Printf("%d: %c\n", index, runeValue)
}

index — это байтовое смещение, не индекс символа. Это позволяет легко манипулировать подстроками: s[index:] будет начинаться с начала данной руны. Если нужно просто количество символов, можно использовать for range s { count++ } — пустой идентификатор.

Под капотом (internals)

Компилятор при генерации кода для range строки вставляет вызов runtime.decoderune (или аналог) последовательно. Внутренний цикл читает байты по одному, определяет длину кодовой точки и выдаёт результат. Это происходит без дополнительных аллокаций, в отличие от []rune.

Типичные ошибки кандидатов

Игнорирование индекса и предполагание, что он соответствует порядковому номеру символа: индекс — байтовый.
Исправление: использовать отдельный счётчик, если нужен номер символа.
Изменение строки во время итерации: строка неизменяема, но если идёт обработка с параллельной горутиной, это не проблема; однако мутация через unsafe может нарушить итерацию. Обычно неактуально.
Использование range для обхода ASCII строк: всё равно будет декодирование UTF-8, но накладные расходы незначительны.

Возможные дополнительные вопросы интервьюера

Что вернёт range для пустой строки?
Ни одной итерации, цикл не выполнится.

Чем range отличается от ручного вызова utf8.DecodeRuneInString?
range делает то же самое, но автоматически, чуть медленнее из-за вызовов, но гораздо читаемее.

В чем разница между `len(str)` и `utf8.RuneCountInString(str)`?

Краткий ответ (30–60 секунд)

len(str) возвращает количество байт в строке (длину в байтах). utf8.RuneCountInString(str) возвращает количество Unicode кодовых точек (рун), т.е. «символов» с точки зрения пользователя. Для ASCII строк они равны, но для многобайтовых (например, русские буквы занимают 2 байта) разница существенна: len("Привет") == 12, а utf8.RuneCountInString("Привет") == 6. Выбор функции зависит от задачи: для выделения памяти, работы с сетью — длина в байтах; для обработки текста, подсчёта символов — руны.

Развёрнутый ответ

len — O(1), просто читает поле длины из заголовка строки. utf8.RuneCountInString — O(n), проходит по всей строке, подсчитывая количество рун (путём анализа leading байтов). Необдуманное применение utf8.RuneCountInString на больших строках может снизить производительность, если это не требуется.

s := "hello"
fmt.Println(len(s)) // 5
fmt.Println(utf8.RuneCountInString(s)) // 5
s = "こんにちは" // каждое кана — 3 байта
fmt.Println(len(s)) // 15
fmt.Println(utf8.RuneCountInString(s)) // 5

Под капотом (internals)

len реализован как встроенная операция, доступ к полю Len структуры StringHeader. utf8.RuneCountInString использует utf8.RuneCount([]byte(s)), которая внутри делает цикл с DecodeRune или использует оптимизированный подсчёт по таблице первых байтов (leading byte за один проход). В ассемблере это быстрый проход, но всё равно O(n).

Типичные ошибки кандидатов

Использование len для выделения буфера под посимвольную обработку с руной: буфер будет слишком маленьким для многобайтовых строк.
Исправление: если нужен буфер под руны, выделять make([]rune, utf8.RuneCountInString(s)).
Сравнение длин строк через len в контексте ограничения на количество символов на UI: вы не учтёте, что пользователь может ввести многобайтовые символы, и лимит символов нарушится.
Исправление: использовать utf8.RuneCountInString.
Предположение, что len == utf8.RuneCountInString для всех языков: очевидно ложно.

Возможные дополнительные вопросы интервьюера

Как быстро подсчитать количество байт, занимаемых первыми N рунами?
Используя utf8.RuneCountInString не получится; надо просканировать строку, суммируя размеры рун до N. Можно через utf8.DecodeRuneInString или range.

Что дешевле: for range s { count++ } или utf8.RuneCountInString?
Примерно одинаково, но utf8.RuneCountInString оптимизирован. Лучше использовать его.

Как устроена многомерная карта и какие есть альтернативы?

Краткий ответ (30–60 секунд)

Go не поддерживает многомерные карты напрямую как map[K1]map[K2]V. Вместо этого обычно используют карту верхнего уровня, значениями которой являются другие карты: map[K1]map[K2]V. Однако такой подход требует инициализации каждой вложенной карты перед вставкой, создаёт много отдельных аллокаций и усложняет код. Альтернативы: использовать составной ключ (например, структуру) map[struct{K1, K2}]V, что даёт единую хеш-таблицу и упрощает вставку и поиск, либо плоскую карту с ключом-строкой fmt.Sprintf("%v_%v", k1, k2). Композитный ключ обычно эффективнее и идиоматичнее.

Развёрнутый ответ

Паттерн «map of maps»:

m := make(map[string]map[string]int)
if m["a"] == nil {
    m["a"] = make(map[string]int)
}
m["a"]["b"] = 1

Недостатки: две аллокации на ключ, фрагментация памяти, необходимость проверки nil.

Структурный ключ:

type Key struct { A, B string }
m := make(map[Key]int)
m[Key{"a", "b"}] = 1

Это одна карта, доступ атомарен (один lookup). Структуры сравнимы, если все поля сравнимы; это отлично подходит. Ещё вариант — строковый ключ с конкатенацией; менее типобезопасно, но для простых случаев приемлемо.

Под капотом (internals)

При использовании структурного ключа компилятор генерирует хеш-функцию для структуры, которая комбинирует хеши полей. Это эффективно, так как хеш выполняется быстро. При конкатенации строк для ключа происходит выделение памяти и копирование; структурный ключ обычно быстрее и не создаёт мусора, если передаётся по значению (небольшой). При map of maps фрагментация может ухудшить локальность кеша.

Типичные ошибки кандидатов

Ленивая инициализация вложенных карт без проверки nil: m["outer"]["inner"] = 1 паникует, если m["outer"] nil.
Исправление: использовать вспомогательную функцию или перейти на структурный ключ.
Преждевременная замена на sync.Map или кастомный хеш: структурный ключ решает большинство задач.
Исправление: сначала попробовать структурный ключ.
Строковый ключ через fmt.Sprintf: создаёт мусор и имеет риск коллизий, если разделитель может появиться в ключах. Лучше структура.
Исправление: выбирать структуру.

Возможные дополнительные вопросы интервьюера

Можно ли использовать interface{} как ключ для разнотипных ключей?
Да, если interface{} содержит сравнимый динамический тип; тогда Go будет сравнивать по динамическому типу и значению. Однако это дороже из-за динамического диспетча, и есть риск паники при не сравнимом значении.

Как дебажить производительность map of maps?
Профилировать аллокации (pprof) и количество операций; в большинстве случаев замена на структурный ключ даёт выигрыш.

Как реализован `sync.Map` и в каких случаях его применять?

Краткий ответ (30–60 секунд)

sync.Map — это конкурентно-безопасная обёртка над картой, оптимизированная для двух сценариев: (1) когда ключ однажды записывается и многократно читается (cache с преобладанием чтения); (2) когда несколько горутин читают, пишут и удаляют, но ключи не пересекаются. Внутри она реализована как две отдельные карты: read-only (без блокировок) и dirty (защищённая мьютексом), с механизмом продвижения элементов из dirty в read при частом чтении. Для обычных конкурентных нагрузок лучше использовать обычную карту с sync.RWMutex.

Развёрнутый ответ

sync.Map не является универсальной заменой map + mutex. Её API: Load, Store, Delete, Range. Внутренняя структура (приблизительно):

type Map struct {
    mu     sync.Mutex
    read   atomic.Value // readOnly структура
    dirty  map[any]any
    misses int
}

read хранит readOnly карту (неизменяемую, доступную без блокировки). При Load сначала ищем в read; если промах, увеличивается счётчик misses, и при превышении порога (misses > len(dirty)) dirty копируется в read (read становится dirty, dirty очищается). Store всегда проверяет read, если ключ там, пытается обновить через атомарный CAS (если значение не удалено); иначе блокирует mu и пишет в dirty. Таким образом, при стабильных ключах почти все чтения без блокировок.

Когда применять:

Кеши с редкой записью, частым чтением.
Когда ключи не меняются часто.
Когда горутины работают с непересекающимися наборами ключей (меньше конкуренции за мьютекс).

Под капотом (internals)

Исходники в src/sync/map.go. Структура readOnly хранит m map[any]any и флаг amended (были ли добавлены ключи в dirty, которых нет в read). Алгоритм: Load — read map; если нет и amended true, блокировка и поиск в dirty; увеличение misses; если misses превышает длину dirty, происходит промоушн: dirty становится новым read, старая read выбрасывается. Store — если ключ в read и не удалён, пытается атомарно обновить; иначе блокировка, запись в dirty (и копирование read в dirty, если dirty была nil). Удаление — помечает ключ в read как удалённый (expunged) или удаляет из dirty.

Типичные ошибки кандидатов

Использование sync.Map для общих высококонкурентных обновлений (много Store): приведёт к частым блокировкам и копированиям всей карты, производительность упадёт.
Исправление: обычный map + sync.Mutex или sync.RWMutex.
Применение Range без учёта, что он может видеть несогласованное состояние при одновременных записях: Range обходит read-карту (без блокировки), но если в это время происходит промоушн, может не увидеть недавно добавленные ключи. Это допустимо для «snapshot» семантики.
Исправление: смириться с ослабленной семантикой.
Игнорирование типа ключей: sync.Map использует any, что теряет типобезопасность и может привести к паникам при неверном приведении типов.
Исправление: обернуть в типобезопасный фасад с дженериками (Go 1.18+) либо тщательно контролировать типы.

Возможные дополнительные вопросы интервьюера

Чем отличается sync.Map от concurrent-map из сторонних библиотек?
Сторонние библиотеки часто используют шардирование (сегментированные мьютексы), что даёт лучшую параллельную запись за счёт большего объёма памяти. sync.Map хорош для специфических сценариев с доминированием чтений.

Можно ли использовать sync.Map как обычную карту с дженериками?
Начиная с Go 1.18, можно написать обёртку с методами, принимающими параметры типов, но сама sync.Map остаётся нетипизированной.

Что такое `struct`?

Краткий ответ (30–60 секунд)

Структура (struct) в Go — это композитный тип, объединяющий набор именованных полей (полей могут быть неименованными — встраивание), каждое из которых имеет свой тип. Она позволяет моделировать объекты с состоянием. Структуры являются значениями: присваивание копирует все поля. Поля можно делать экспортируемыми (с большой буквы) или неэкспортируемыми. Структура поддерживает методы (с value или pointer receiver), что даёт возможность инкапсуляции и интерфейсов.

Развёрнутый ответ

Объявление:

type Person struct {
    Name string
    Age  int
}

Доступ через точку: p := Person{"Alice", 30}. Структуры можно сравнивать (если все поля сравнимы), встраивать (анонимные поля) для композиции. Пустая структура struct{} занимает 0 байт, используется как сигнальный тип. Структура — это основа объектно-ориентированного программирования в Go.

Под капотом (internals)

Память структуры — это последовательность полей с учётом выравнивания (alignment). Компилятор вставляет padding для соблюдения требований выравнивания. Размер структуры можно узнать через unsafe.Sizeof. Порядок полей влияет на размер: сгруппировав поля по размеру, можно минимизировать паддинг.

Типичные ошибки кандидатов

Создание структуры с неэкспортируемыми полями без конструктора: приводит к невозможности инициализировать из других пакетов.
Исправление: экспортировать поля или предоставить New-функцию.
Передача большой структуры по значению в горячих циклах: дорогое копирование.
Исправление: передавать указатель.
Встраивание интерфейсов в структуру для «наследования» поведения без инициализации: поле равно nil, вызов метода паникует.
Исправление: инициализировать встроенное поле в конструкторе.

Возможные дополнительные вопросы интервьюера

Как реализовать неизменяемую структуру?
Сделать поля неэкспортируемыми, предоставить только геттеры, но Go не даёт полей readonly на уровне компиляции.

Может ли структура иметь нулевой размер?
Да, struct{} имеет размер 0, используется для map map[key]struct{} для экономии памяти.

Как сравниваются структуры (`==`)?

Краткий ответ (30–60 секунд)

Две структуры можно сравнить операторами == и !=, только если все их поля являются сравнимыми типами (т.е. не содержат срезов, карт, функций, или структур с такими полями). Сравнение происходит побайтово по содержимому всей структуры (включая возможные padding байты, но они одинаковы для одинаковых полей). Структуры сравнимы, только если они одного типа. В случае наличия несравнимых полей компилятор запретит сравнение.

Развёрнутый ответ

type A struct { x int; y string }
a1 := A{1, "hi"}
a2 := A{1, "hi"}
fmt.Println(a1 == a2) // true

Если поле — срез, карта или функция, struct становится несравнимым. Попытка сравнения вызовет ошибку компиляции. Можно сравнивать структуры через reflect.DeepEqual, которая рекурсивно обходит поля, но это дороже и небезопасно для циклических ссылок (хотя DeepEqual их обнаруживает). Порядок полей важен для сравнения, так как структуры разных типов не сравнимы (даже если поля одинаковые).

Под капотом (internals)

Компилятор генерирует для сравнения либо прямой memcmp для простых структур (без указателей), либо посерийное сравнение полей с учётом выравнивания, чтобы избежать сравнения padding (но для identical padding это детерминировано). Сравнение указателей полей сравнивает адреса, а не данные.

Типичные ошибки кандидатов

Сравнение структур с несравнимыми полями через ==: ошибка компиляции.
Исправление: реализовать свой метод Equal, либо использовать reflect.DeepEqual.
Использование reflect.DeepEqual для больших структур в горячем коде: неэффективно из-за рефлексии и возможных аллокаций.
Исправление: написать кастомный Equal.
Попытка сравнить структуры с плавающей точкой и ожидать точного равенства: float64 сравнимы, но NaN != NaN, и погрешности могут нарушить логику.
Исправление: сравнивать float с эпсилон.

Возможные дополнительные вопросы интервьюера

Как поведут себя встроенные поля при сравнении?
Если встроенное поле — структура или указатель на структуру, оно участвует в сравнении рекурсивно. Сравнение по правилам сравнимости типов полей.

Можно ли сравнивать структуры с полями-массивами?
Да, массивы сравнимы (если их элементы сравнимы), поэтому структура сравнится корректно.

Что такое `make` и `new`?

Краткий ответ (30–60 секунд)

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

Развёрнутый ответ

new — это эквивалент var t T; return &t, но удобнее в одну строку. Память обнуляется. Для срезов new([]int) вернёт указатель на nil-срез? Нет, new([]int) возвращает указатель на заголовок среза, который будет nil (array=nil, len=0, cap=0). Это не то же самое, что make([]int, 0, 0), который возвращает срез (не указатель), инициализированный (array указывает на zerobase). new никогда не используется для создания срезов/карт/каналов, потому что они требуют внутренней инициализации, которую даёт make.

Под капотом (internals)

new транслируется в выделение памяти через runtime.newobject (для типов не на стеке) или просто размещение на стеке. make для срезов вызывает makeslice, для карт — makemap, для каналов — makechan. Эти функции аллоцируют базовые структуры и устанавливают поля.

Типичные ошибки кандидатов

Использование new для создания среза или карты: s := new([]int); *s = append(*s, 1) работает, но создаёт ненужный уровень косвенности и сбивает с толку.
Исправление: s := make([]int, 0).
Попытка использовать make для пользовательского типа: make(MyStruct) не компилируется.
Исправление: make только для трёх встроенных типов.
Путаница с инициализацией карты через new: m := new(map[string]int) даёт указатель на nil-карту, запись (*m)["key"] = 1 паникует.
Исправление: m := make(map[string]int).

Возможные дополнительные вопросы интервьюера

Зачем нужен new, если можно просто &T{}?
new создаёт нулевое значение, а композитный литерал может инициализировать поля. Для простых типов new(int) vs i := 0; p := &i — разница только в удобстве.

Можно ли make использовать для создания указателя на срез?
Нет, make([]int, 0) возвращает срез. Чтобы получить указатель на срез, нужно s := make([]int,0); p := &s, но обычно это не нужно.

Чем `make` отличается от `new`?

Краткий ответ (30–60 секунд)

new(T) возвращает указатель на обнулённую память для значения типа T, работает с любым типом.
make(T, ...) применяется только к срезам, картам и каналам, возвращает инициализированное значение (не указатель), готовое к использованию. make выполняет не только выделение памяти, но и сложную инициализацию внутренних структур (например, выделение бакетов для карт, задание длины и ёмкости для срезов).

Развёрнутый ответ

Главные отличия:

Типы: new — любой тип; make — только slice, map, chan.
Возврат: new — указатель *T; make — значение T.
Инициализация: new — просто обнуление; make — полноценная настройка, включая присвоение начальной длины, ёмкости, выделение внутренних массивов.
Использование: new иногда применяется для выделения структур под мьютексы (mu := new(sync.Mutex)), но чаще используют литералы; make — обязателен для карт и срезов с заданной ёмкостью.

Под капотом (internals)

Разные кодовые пути в компиляторе: new(T) превращается в runtime.newobject (если тип уходит в кучу). make для срезов обрабатывается специальными runtime-функциями (makeslice), которые аллоцируют массив и возвращают срез- struct. Аналогично для карт/каналов. new можно думать как синтаксический сахар для var t T; return &t.

Типичные ошибки кандидатов

Замена make на new для карты: m := new(map[K]V) — получится указатель на nil-карту, запись в него уронит программу.
Исправление: m := make(map[K]V).
Попытка сделать make(MyStruct): компилятор скажет, что MyStruct не поддерживается.
Исправление: new(MyStruct) или MyStruct{}.
**Использование make([]int, 5) без понимания, что это создаёт срез с 5 нулевыми элементами и cap=5, в отличие от make([]int, 0, 5) — только ёмкость.

Возможные дополнительные вопросы интервьюера

Можно ли использовать make для создания канала с буфером, где размер буфера задаётся переменной?
Да, make(chan int, n) — стандартно.

Что будет, если make передать отрицательную длину?
Паника во время выполнения.

Почему `copy` работает только со срезами, но не с массивами?

Краткий ответ (30–60 секунд)

Встроенная функция copy определена с аргументами типа []T, то есть требует срезы. Массивы, хотя и лежат в основе срезов, имеют другой тип (длина — часть типа), и copy не принимает аргументы-массивы напрямую. Однако, срез массива arr[:] превращает массив в срез, и тогда copy работает. Причина — дизайн языка: массивы фиксированного размера — value types, обычно их не копируют через copy; для копирования массивов достаточно присваивания newArr := oldArr (глубокое копирование). copy же предназначен для гибкого копирования между срезами разной длины.

Развёрнутый ответ

copy(dst, src) ожидает два среза, чтобы копировать элементы между динамически определяемыми областями памяти, с проверкой длины приёмника. Массивы не обладают гибкостью длины и ёмкости, поэтому для них copy не нужен: простое присваивание копирует все элементы. Тем не менее, если нужно скопировать часть массива, его можно срезировать и передать в copy.

Пример копирования массива:

arr := [5]int{1,2,3,4,5}
var arr2 [5]int
arr2 = arr // копирование
// или copy(arr2[:], arr[:])

Под капотом (internals)

Сигнатура copy строго проверяется компилятором: func copy(dst, src []Type) int. Тип [N]T не удовлетворяет []T. Рантайм-код копирования ожидает заголовок среза (ptr, len), для массива же нет len поля во время выполнения? На самом деле, len массива известен компилятору, но передаётся неявно; для унификации проще требовать срез.

Типичные ошибки кандидатов

Попытка copy(arr1, arr2): не компилируется.
Исправление: использовать присваивание или срезировать.
Использование copy(&arr1, &arr2): тоже ошибка.
Предположение, что copy не работает с массивами из-за производительности: дизайн связан с семантикой, а не с перформансом.

Возможные дополнительные вопросы интервьюера

Что будет, если сделать copy(arr[:], src)?
Всё работает, потому что arr[:] возвращает срез, ссылающийся на массив. Копирование произойдёт в этот массив до его длины.

Можно ли копировать из среза в массив?
Только через срез массива: copy(arr[:], src). Нельзя напрямую.

Что такое «глубокое копирование» среза и как его реализовать?

Краткий ответ (30–60 секунд)

Глубокое копирование среза означает создание новой независимой копии всех элементов, включая рекурсивное копирование данных, на которые указывают элементы (например, если элементы — указатели или другие срезы). Для простого среза байт или чисел копия через make + copy уже «глубокая» (значения скопированы). Для срезов структур, содержащих указатели или вложенные срезы, необходимо реализовать рекурсивное копирование вручную (или использовать библиотеки типа deepcopy). Стандартная функция copy выполняет только поверхностное копирование.

Развёрнутый ответ

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

type T struct { Data []byte }
src := []*T{ ... }
dst := make([]*T, len(src))
for i, p := range src {
    cp := *p
    cp.Data = make([]byte, len(p.Data))
    copy(cp.Data, p.Data)
    dst[i] = &cp
}

Для произвольных типов можно использовать reflect.DeepCopy? Стандартной нет, есть gob или encoding/json round-trip, но это медленно. Лучше писать явные конструкторы.

Под капотом (internals)

copy просто вызывает memmove для поверхностного копирования элементов. Если элемент — структура со срезом, копируется только заголовок среза, и оба среза будут ссылаться на один базовый массив.

Типичные ошибки кандидатов

Использование copy для среза, содержащего указатели, и ожидание, что данные по указателям тоже скопируются: изменятся только сами указатели (адреса), но обе копии будут указывать на одни и те же объекты.
Исправление: пройти в цикле и скопировать содержимое.
Попытка сделать глубокую копию через append([]T(nil), src...): это создаёт поверхностную копию среза (заголовок разный, но элементы те же). Для срезов байт — глубокая, для срезов указателей — нет.
Исправление: различать типы элементов.
Сериализация в JSON и обратно: работает, но медленно и может потерять приватные поля, типы.

Возможные дополнительные вопросы интервьюера

Как реализовать универсальную функцию глубокого копирования в Go?
Использовать рефлексию: reflect.DeepCopy нет, но можно написать с помощью reflect или использовать github.com/mitchellh/copystructure. В стандартной библиотеке только gob и т.п.

Безопасно ли делать глубокое копирование через copy для []byte?
Да, []byte — это примитивный тип, copy полностью копирует содержимое.

Как работает «срезание среза» и что происходит с базовым массивом?

Краткий ответ (30–60 секунд)

Операция «срезания среза» s[i:j] (или s[i:j:k]) создаёт новый заголовок среза, который ссылается на тот же базовый массив, что и исходный, но с новыми значениями len и cap, вычисленными исходя из смещения. Исходный массив не изменяется и не копируется. Это означает, что изменение элементов в подсрезе изменяет соответствующие элементы исходного среза, и наоборот. При этом старый срез продолжает удерживать массив, пока существует хотя бы один срез, ссылающийся на него.

Развёрнутый ответ

Пример:

arr := [5]int{1,2,3,4,5}
s := arr[1:4] // len=3 (2,3,4), cap=4 (элементы 1..4)
sub := s[1:3] // len=2 (3,4), cap=3 (элементы 2..4, индексы внутри s)
sub[0] = 99    // arr[2] == 99

Базовый массив — arr. При срезании новый срез указывает в середину массива. Ёмкость подсреза sub считается от нового указателя до конца родительского массива (cap(sub) = cap(s) - offset). Использование третьего индекса s[i:j:k] ограничивает ёмкость, позволяя append новому срезу работать изолированно, не модифицируя родительский массив за пределами j.

Под капотом (internals)

Операция s[low:high] (и с третьим индексом) реализуется в компиляторе генерацией кода, который вычисляет новые поля заголовка: newPtr = s.array + low*sizeof(T), newLen = high - low, newCap = cap(s) - low (или max - low для трёхиндексной). Проверки: 0 <= low <= high <= cap(s), и опционально high <= max <= cap(s). Если проверки не пройдены, паника во время выполнения.

Типичные ошибки кандидатов

Модификация подсреза без осознания воздействия на родительский срез/массив: случайно портит данные.
Исправление: при необходимости изоляции делать sub := make([]T, length); copy(sub, origin[i:j]).
Создание подсреза с большой ёмкостью и последующий append, перезаписывающий родительские данные: sub = append(sub, 10) пишет за пределы len, но в пределах cap, меняя элементы массива.
Исправление: использовать трёхиндексную форму s[i:j:j] для ограничения ёмкости.
Забывание, что срезание nil-среза даёт nil-срез: nil[0:0] — это валидно, но nil[1:2] — паника.

Возможные дополнительные вопросы интервьюера

Что произойдёт, если сделать s[:0] и потом append?
s = s[:0] сбрасывает длину в 0, но ёмкость сохраняется. append начнёт перезаписывать старые данные в базовом массиве.

Как работает полное выражение среза a[low:high:max]?
Позволяет установить cap равной max - low. Это предотвращает нежелательные модификации базового массива при последующих append.

Как работает итерация по карте во время её изменения?

Краткий ответ (30–60 секунд)

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

Развёрнутый ответ

Спецификация Go говорит: «If map entries that have not yet been reached are removed during iteration, the corresponding iteration values will not be produced. If map entries are inserted during iteration, the behavior is implementation-dependent, but the entries may be produced during the iteration or may be skipped.» Таким образом, удаления безопасны, а добавления — недетерминированы. На практике, добавление может инициировать рост карты, который инкрементально эвакуирует бакеты, и итератор может попасть в состояние, где обходит как старые, так и новые, что создаёт непредсказуемые результаты.

Пример:

m := map[int]bool{}
for i := 0; i < 5; i++ { m[i] = true }
for k := range m {
    if k == 2 {
        m[10] = true // добавление
    }
    delete(m, k)
}

Код корректен, но поведение добавления — implementation-defined.

Под капотом (internals)

Итератор hiter хранит указатели на текущий бакет и прогресс. При удалении текущего элемента tophash помечается как удалённый, итератор продолжает. При добавлении (вставка) может расширить карту, инициировав эвакуацию. Итератор может продолжить обход; новые ключи могут попасть в ещё не посещённые бакеты и стать видимыми.

Типичные ошибки кандидатов

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

Возможные дополнительные вопросы интервьюера

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

Как итератор обрабатывает удаление всех элементов подряд?
Сработает корректно: посещённые элементы удаляются, оставшиеся продолжают итерироваться.

Почему нельзя взять адрес элемента карты?

Краткий ответ (30–60 секунд)

Взять адрес элемента карты (&m[key]) запрещено на уровне компиляции, потому что карта может динамически перераспределять память (рост, эвакуация бакетов), что сделает ранее взятые указатели висячими. Go гарантирует безопасность памяти, и допущение таких указателей привело бы к неопределённому поведению. Вместо этого, если нужно изменить значение в карте через указатель, используют обходные пути: извлечь значение во временную переменную, модифицировать, записать обратно; либо хранить в карте указатели на значения (например, map[K]*V).

Развёрнутый ответ

Элементы карты могут перемещаться в памяти при эвакуации (инкрементальное копирование бакетов в новые массивы). Если бы у нас был указатель на элемент, после эвакуации он бы указывал на старую память, которая может быть переиспользована, что нарушит безопасность. Компилятор предотвращает это, выдавая ошибку: cannot take the address of m[key].

Решение:

v := m[key]
v.field = newValue
m[key] = v

Если структура большая и копирование дорого, используйте map[K]*V. Тогда адрес можно взять у значения указателя, но надо быть аккуратным с разделяемостью данных.

Под капотом (internals)

Рантайм гарантирует, что во время вставки/удаления бакеты могут перемещаться. Функция mapassign может изменить указатель на бакет и скопировать ключи/значения в другое место. Поэтому любые указатели на элементы могут инвалидироваться. Компилятор просто запрещает это, не давая никаких иллюзий стабильности.

Типичные ошибки кандидатов

Попытка обойти запрет через unsafe: получение адреса через uintptr(unsafe.Pointer(&m)) и вычисление смещения элемента — чрезвычайно опасно, указатель висячий после любой записи.
Исправление: не делать так.
Использование карты значений для большого типа и частая модификация: копирование при каждом обновлении может быть накладным.
Исправление: использовать map[K]*V.
Забывание, что m[key] для несуществующего ключа возвращает нулевое значение, и попытка взять адрес тоже не имеет смысла: даже если бы было можно, это был бы адрес нулевого значения, а не слота в карте.

Возможные дополнительные вопросы интервьюера

Как получить указатель на элемент карты, если знать, что карта не будет расти после этого?
Никак, компилятор не разрешит. Даже если карта не растёт, гарантии нет.

Можно ли хранить в карте структуры, содержащие срезы, и модифицировать срезы, получая значение?
Да, т.к. v := m[key] копирует структуру (включая заголовок среза). Если вы измените элементы среза v.Slice[0], это изменит данные нижележащего массива, и изменения отразятся на копии в карте, так как срез внутри структуры копируется, но указывает на тот же массив. Чтобы обновить сам заголовок среза, нужно переприсвоить m[key] = v.

Что такое `unsafe.Sizeof` для строк и срезов?

Краткий ответ (30–60 секунд)

unsafe.Sizeof возвращает размер в байтах, занимаемый самим значением переменной, но не данными, на которые оно указывает. Для строки unsafe.Sizeof(s) всегда возвращает 16 (на 64-битной платформе): 8 байт указатель + 8 байт длина. Для среза — 24 (указатель, длина, ёмкость). Размер не зависит от длины строки или среза, так как это размер заголовка. Чтобы узнать размер лежащих данных, нужно использовать len для строк (количество байт) или cap/len с sizeof(element) для среза.

Развёрнутый ответ

Это фундаментальное различие между размером заголовка и размером данных. Понимание этого важно для оценки использования памяти. Пример:

s := "hello world" // достаточно длинная строка
fmt.Println(unsafe.Sizeof(s)) // 16
fmt.Println(len(s)) // 11 (байт)

Аналогично, для среза: заголовок 24 байта, независимо от того, ссылается ли он на 1000 элементов или пуст.

Под капотом (internals)

unsafe.Sizeof обрабатывается компилятором на этапе компиляции; он возвращает константу для данного типа. Для string это 2 * ptrSize (ptrSize=8 на 64-бит). Для slice это 3 * ptrSize. Для map — 1 * ptrSize, так как map — это указатель на hmap (8 байт).

Типичные ошибки кандидатов

Попытка вычислить полный объём памяти, занимаемый строкой, через unsafe.Sizeof(s): получается 16, а не фактические данные.
Исправление: использовать len(s) для байт данных плюс 16 для заголовка.
Сравнение размера среза и массива: unsafe.Sizeof(arr) для [100]int вернёт 800, тогда как для среза []int с 100 элементами — 24. Это разное.
Использование unsafe.Sizeof для определения размера элемента сложного типа и неправильная оценка: для string поля в структуре его размер 16 байт (заголовок), а не данные.

Возможные дополнительные вопросы интервьюера

Сколько памяти занимает пустая карта?
Карта m := make(map[K]V) имеет размер указателя (8 байт) на hmap. hmap уже содержит начальный массив бакетов (если не nil). Для nil-карты — 0 байт данных (указатель nil), но переменная всё равно где-то хранится.

Как узнать реальный объём памяти, занимаемый срезом и его данными?
Данные: len(s) * sizeof(element). Плюс 24 байта на заголовок. Однако если массив разделяемый, считать нужно аккуратно.

Что такое `comparable` интерфейс и для каких типов он реализован?

Краткий ответ (30–60 секунд)

comparable — это встроенный интерфейс в Go 1.18+, который представляет собой множество всех типов, допускающих сравнение операторами == и !=. Он не может быть использован как тип переменной (только как ограничение типа). Ему удовлетворяют все базовые типы (числа, строки, булевы), указатели, каналы, интерфейсы (если динамические типы сравнимы), структуры и массивы, составленные из сравнимых типов. Не удовлетворяют: срезы, карты, функции, структуры/массивы, содержащие эти типы.

Развёрнутый ответ

Интерфейс comparable введён для дженериков, чтобы позволить писать функции, требующие сравнения: func Equal[T comparable](a, b T) bool { return a == b }. Все сравнимые типы могут использоваться как ключи карт. Ошибка компиляции возникает, если передаваемый тип не comparable. comparable — это неестественный интерфейс в рантайме, он не имеет методов, он просто маркер для компилятора.

Перечень сравнимых типов чётко определён спецификацией. Важно: интерфейсы сравнимы, но их сравнение сравнивает динамический тип и значение. Если динамический тип сам несравним (содержит срез), сравнение вызовет панику во время выполнения. Поэтому интерфейсный тип формально comparable, но может паниковать.

Под капотом (internals)

В компиляторе при подстановке типа проверяется, удовлетворяет ли он comparable. Для интерфейсов генерируется код, вызывающий runtime.ifaceeq (или efaceeq), который может паниковать при несовпадении. comparable не добавляет никакого рантайм-трекинга.

Типичные ошибки кандидатов

Использование comparable как типа переменной: var c comparable — ошибка компиляции, так как comparable не является обычным интерфейсом.
Исправление: использовать в определении типа дженерика.
Предположение, что interface{} всегда безопасно сравнивать: если под ним лежит срез, сравнение упадёт.
Исправление: использовать reflect.DeepEqual для неопределённых типов или проверять типы.
Создание дженерика с ограничением comparable для типа, который на самом деле может паниковать при сравнении (интерфейсы): технически допустимо, но надо понимать риск.
Исправление: добавить дополнительную проверку или использовать cmp пакет.

Возможные дополнительные вопросы интервьюера

Можно ли реализовать comparable для пользовательского типа?
Нет, comparable — это предопределённый интерфейс, ему удовлетворяют только типы, перечисленные в спецификации. Пользовательский тип с методом Equal не становится comparable.

Как создать дженерик-функцию, которая принимает только типы, подходящие для ключей карт?
Использовать comparable ограничение: func keys[K comparable, V any](m map[K]V) []K. Это гарантирует, что тип K можно использовать как ключ.

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

Краткий ответ (30–60 секунд)

Нельзя использовать в качестве ключей карт типы, которые не являются сравнимыми (== и !=). К ним относятся: срезы ([]T), карты (map[K]V), функции (func), а также структуры или массивы, содержащие любые из этих типов (прямо или косвенно). Также нежелательно использовать float32/float64 из-за NaN, хотя формально они сравнимы. Интерфейсы можно использовать, но если динамическое значение станет несравнимым в рантайме, произойдёт паника.

Развёрнутый ответ

Спецификация языка чётко указывает: операторы сравнения == и != должны быть определены для типа ключа. Срезы, карты и функции не удовлетворяют этому требованию. Это проверяется компилятором. Пример ошибки:

var m map[[]int]string // compile error

Структуры, содержащие срезы, также несравнимы. Интерфейсные ключи: var m map[interface{}]string позволит, но если под interface{} окажется срез, то при вставке или поиске возникнет паника, так как runtime попытается сравнить несравнимые значения.

Под капотом (internals)

Реализация карт в рантайме вызывает функции сравнения ключей. Для интерфейсов вызывается runtime.ifaceeq или efaceeq, которые проверяют тип и, если он несравним, паникуют (throw). Поэтому ключи-интерфейсы опасны.

Типичные ошибки кандидатов

Использование map[interface{}]... для универсальности и вставка среза как ключа: паника при рантайме.
Исправление: преобразовать срез в строку (например, через fmt.Sprint) или использовать структуру с фиксированным набором полей.
Попытка превратить срез в ключ через *(*string)(unsafe.Pointer(&slice)): не только опасно, но и ключ будет меняться при изменении среза, что нарушает инварианты карты.
Исправление: не использовать unsafe для ключей.
Использование функций как ключей: бессмысленно и не компилируется.

Возможные дополнительные вопросы интервьюера

Можно ли использовать указатель на функцию в качестве ключа?
Да, указатели сравнимы; можно map[*func()]bool, но это странная практика.

Что такое "struct-ключи" и почему они предпочтительнее строковых?
Структуры из сравнимых полей позволяют сохранять типобезопасность и избегать конкатенаций. Компилятор генерирует быстрый хеш для структуры.

В чем отличие `string.Builder` от конкатенации строк?

Краткий ответ (30–60 секунд)

strings.Builder — это изменяемый буфер для эффективного построения строк, минимизирующий аллокации и копирования. Обычная конкатенация + каждый раз создаёт новую строку, копируя все операнды, что при многократном сложении в цикле даёт квадратичную сложность. Builder внутри использует срез байт, расширяемый умным образом, и возвращает строку только в конце (String()), выделяя память один раз (или логарифмическое число раз из-за роста). Использование Builder — лучшая практика для построения строк из множества частей.

Развёрнутый ответ

Пример:

var b strings.Builder
for i := 0; i < 1000; i++ {
    b.WriteString("a")
}
s := b.String()

В отличие от s += "a", где каждая итерация создаёт новую строку длиной на 1 больше, Builder выделяет буфер с запасом, дописывает в него, и только в конце создаёт результирующую строку. Можно предварительно задать ожидаемый размер через b.Grow(n), чтобы вовсе избежать переаллокаций.

Под капотом (internals)

strings.Builder содержит поле buf []byte. Метод WriteString добавляет строку в buf. Если недостаточно места, grow расширяет срез, используя make + copy. Стратегия роста: удвоение для малых буферов, плавный рост для больших (похоже на рост срезов). String() возвращает string(buf), что создаёт копию данных (или в некоторых случаях может оптимизироваться), но обычно безопасно копирует, чтобы итоговая строка не ссылалась на внутренний буфер builder'а, который может быть изменён позже. У builder'а есть метод Reset().

Типичные ошибки кандидатов

Забыть, что String() создаёт копию: если builder будет использоваться дальше, строка останется неизменной копией.
Исправление: не вызывать String(), пока не закончено построение.
Использовать Builder для одиночной конкатенации пары строк: накладные расходы builder'а могут быть выше простого +.
Исправление: для малого количества строк используйте + или fmt.Sprintf.
Не использовать Grow при известном размере: приводит к множественным внутренним переаллокациям, снижая эффективность.
Исправление: оценить размер и вызвать Grow.

Возможные дополнительные вопросы интервьюера

Безопасен ли strings.Builder для конкурентного использования?
Нет, он не потокобезопасен. Для параллельной сборки нужна синхронизация.

Чем bytes.Buffer отличается от strings.Builder?
Buffer имеет больше методов, может читать, поддерживает io.Reader/Writer. Builder оптимизирован исключительно для построения строк, легче и не имеет возможности чтения. В большинстве случаев для конструирования строк предпочтительнее Builder.

Как работает `strings.Builder` внутри и почему он эффективен?

Краткий ответ (30–60 секунд)

strings.Builder реализован как простая структура с полем buf []byte. Он использует внутренний срез байт, к которому дописываются данные через WriteString, WriteRune и т.д. Главная эффективность достигается за счёт того, что он работает с изменяемым байтовым буфером, избегая порождения множества временных неизменяемых строк. При необходимости буфер расширяется алгоритмом, аналогичным росту среза. Итоговый вызов String() выполняет копирование буфера в новую строку (или в некоторых случаях возвращает строку без копии, если гарантируется, что builder больше не будет изменяться, но текущая реализация копирует для безопасности), что даёт одну строку-результат без промежуточных аллокаций.

Под капотом (internals)

Структура:

type Builder struct {
    addr *Builder // для детекта копирования после первого использования
    buf  []byte
}

При первом действии (например, WriteString) addr запоминает адрес Builder'а. Если Builder копируется по значению после начала использования, последующие операции запаникуют, так как это небезопасно (копия совместно использует тот же буфер). Метод copyCheck реализует это.

Grow(n) использует growslice или встроенную логику для увеличения buf до нужной ёмкости. String() делает string(buf), что копирует данные, чтобы избежать того, что последующие модификации Builder изменят строку. Это безопасно.

Типичные ошибки кандидатов

Копирование Builder'а после начала записи: приводит к панике.
Исправление: передавать по указателю, если нужно передавать в функции после использования.
Использование String() в цикле, создавая множество строк: хоть и дёшево, но если нужна только конечная строка, копия делается один раз в конце; если же нужны промежуточные строки, Builder не даёт преимущества.
Исправление: вызывать String() один раз в конце.
Попытка использовать внутренний буфер через unsafe для избежания копирования при String(): опасно, так как Builder может измениться.

Возможные дополнительные вопросы интервьюера

Может ли Builder.String() возвращать строку без копирования в будущих версиях Go?
Возможно, если будет механизм заморозки буфера, но пока копирует.

Зачем нужна проверка копирования?
Чтобы предотвратить неопределённое поведение при случайном копировании значения Builder, когда два экземпляра используют один слайс.

Что такое `type alias` и чем отличается от определения типа?

Краткий ответ (30–60 секунд)

Определение типа (type MyInt int) создаёт новый именованный тип, отличный от исходного; требуется явное приведение для присваивания, и он может иметь свои методы. Алиас типа (type MyInt = int) вводит синоним для существующего типа: это один и тот же тип, взаимозаменяемый без приведения. Алиасы в основном нужны для рефакторинга и совместимости (например, byte — алиас uint8, rune — алиас int32).

Развёрнутый ответ

Пример:

type NewInt int     // новый тип
type AliasInt = int // алиас (синоним)

var a NewInt = 5
var b AliasInt = 5
var c int = 5

c = int(a)   // требуется приведение
b = c        // допустимо без приведения, потому что b — это int

Новый тип может иметь методы, алиас наследует методы исходного типа. Алиасы прозрачны во всех контекстах (включая рефлексию, где AliasInt показывается как int).

Под капотом (internals)

В компиляторе для алиаса сохраняется ссылка на идентификатор исходного типа. Алиас полностью идентичен исходному типу во время компиляции. Для нового типа создаётся отдельная запись в таблице типов, и его методы привязываются к нему.

Типичные ошибки кандидатов

Использование алиасов для «логического отделения» с целью безопасности: алиас не даёт защиты, так как типы совместимы.
Исправление: использовать определение типа.
Путаница с = в объявлении: часто забывают знак = для алиаса и создают новый тип, что меняет семантику API.
Исправление: внимательно читать объявления; алиас — это всегда = после имени.
Создание методов на алиасе: можно, но они фактически добавляются к исходному типу, что может быть неожиданно, если исходный тип определён в другом пакете.
Исправление: нельзя определять методы для алиаса типа из другого пакета (ошибка компиляции). Для своего пакета — можно, это будет метод на исходный тип.

Возможные дополнительные вопросы интервьюера

Для чего нужны алиасы типов в контексте refactoring?
Позволяют переименовывать типы в библиотеке без поломки обратной совместимости. Можно объявить алиас со старым именем, указывающим на новое.

Является ли string алиасом для чего-то?
Нет, string — это встроенный самостоятельный тип, не алиас.

Как реализовать потокобезопасный слайс без `sync.Mutex`?

Краткий ответ (30–60 секунд)

Потокобезопасный слайс без мьютекса можно реализовать с помощью атомарных операций и lock-free структур данных. Например, использовать atomic.Value для хранения указателя на snapshot слайса. Для чтения горутина захватывает текущий срез (snapshot) через Load, который всегда консистентен. Для модификации создаётся новая копия слайса (например, через append), и результат сохраняется в atomic.Value через Store. Это позволяет читателям не блокироваться, но ценой копирования при каждой модификации. Другой вариант — использовать lock-free кольцевой буфер или специализированные структуры, но это сложнее.

Развёрнутый ответ

Пример с atomic.Value:

type SafeSlice struct {
    v atomic.Value // хранит []int
}

func (s *SafeSlice) Append(val int) {
    for {
        old := s.Load()
        new := append(old, val)
        if s.v.CompareAndSwap(old, new) {
            break
        }
    }
}

Однако append создаёт новый срез каждый раз, что дорого. CAS цикл обеспечивает атомарность без мьютекса. Для многих приложений это неэффективно. Более практично: использовать sync.RWMutex для слайса, но если задача — избежать блокировок любой ценой, можно применить lock-free структуры: например, []atomic.Pointer[T] для каждого слота, но это меняет семантику (фиксированный размер). Или использовать сегментированный lock-free массив.

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

Под капотом (internals)

atomic.Value гарантирует, что Store происходит после всех Load, начатых до Store. Базовое внутреннее представление atomic.Value — это ifaceWords с атомарным доступом. CAS операции используют hardware-примитивы (LCPU).

Типичные ошибки кандидатов

Использование atomic.Value для прямого изменения элементов слайса: s.Load().([]int)[i] = val — не потокобезопасно, т.к. чтение слайса и запись элемента не атомарны.
Исправление: при необходимости изменять элементы нужно копировать весь слайс и заменять через Store.
Частые модификации с atomic.Value + копирование: производительность резко падает.
Исправление: в таких случаях лучше sync.Mutex.
Игнорирование необходимости копирования базового массива: если несколько горутин держат старый слайс, и одна начинает мутировать элементы через старый указатель, это гонка.
Исправление: гарантировать иммутабельность данных после публикации, либо использовать мьютекс.

Возможные дополнительные вопросы интервьюера

Можно ли реализовать потокобезопасный слайс без аллокаций на каждую операцию?
Да, с помощью техники Copy-On-Write с отслеживанием ссылок (например, через счетчик ссылок или garbage collector), но сложно. Проще использовать мьютекс с сегментированием.

Как в sync.Map решается проблема конкурентного слайса?
Никак, sync.Map не работает со слайсами; она хранит отдельные значения. Для слайсов в качестве значений нужно оборачивать в atomic.Value или мьютекс.

Что такое пакет unique в Go 1.23?

Краткий ответ (30–60 секунд)

Пакет unique предоставляет тип unique.Handle[T] — механизм интернирования (каноникализации) значений в памяти. Два равных значения любого сравнимого типа, переданные в unique.Make[T](v), возвращают один и тот же Handle[T]. Это позволяет сравнивать сложные составные структуры или длинные строки через обычный оператор == за O(1) (сравнение указателей), колоссально экономя оперативную память при наличии миллионов повторяющихся данных.

Развёрнутый ответ

Канонический пример использования:

import (
    "fmt"
    "unique"
)

func main() {
    h1 := unique.Make("https://example.com/api/v1")
    h2 := unique.Make("https://example.com/api/v1")

    // Сравнение O(1) вместо побайтового O(N):
    if h1 == h2 {
        fmt.Println("Хэндлы абсолютно идентичны!")
    }

    // Извлечение исходного значения:
    val := h1.Value()
    fmt.Println(val)
}

Типичные сценарии применения:

Дедупликация строк в сетевых шлюзах (IP-адреса, User-Agent, пути URL, заголовки).
Сложные составные ключи в кэшах и картах.
Символьные таблицы и AST-деревья в компиляторах и парсерах.

Под капотом (internals)

Внутри пакета unique работает глобальная шардированная хэш-таблица, использующая слабые ссылки (weak.Pointer). Если в программе больше нет активных ссылок на интернированный объект, сборщик мусора Go автоматически очищает ячейку таблицы. Это принципиально отличает Go unique от наивных самописных кэшей на sync.Map, которые страдают от вечных утечек памяти.

Типичные ошибки кандидатов

Попытка передать несравнимый тип: unique.Make принимает только типы, удовлетворяющие comparable (нельзя передать срез или map напрямую).
Ожидание, что объект защищён от GC: unique.Handle не держит сильную ссылку на исходный объект вечно — сборщик мусора может пересоздать представление, если все внешние хэндлы были отпущены.

Возможные дополнительные вопросы интервьюера

Какова стоимость unique.Make? — Хэширование и поиск в хэш-таблице (O(len) при первом создании, O(1) амортизированно). Сравнение же хэндлов — строго O(1) по 8-байтному указателю.

Что такое Swiss Tables и как они улучшили map в Go 1.24?

Краткий ответ (30–60 секунд)

В Go 1.24 классическая реализация ассоциативного массива map (хэш-цепочки бакетов по 8 элементов) была заменена на архитектуру Swiss Tables (разработка Google Abseil). Swiss Tables используют плоские массивы с открытой адресацией и массив контрольных байтов (control bytes). Поиск совпадений в группе слотов выполняется параллельно с помощью побитовых операций SWAR и векторных инструкций SIMD, что ускоряет lookup на 30–60% и снижает число промахов кэша процессора.

Развёрнутый ответ

Ключевые отличия Swiss Tables от классической hmap:

Разделение хэша на h1 и h2: 64-битный хэш ключа делится на:
- h1 (старшие 57 бит) — определяет индекс стартовой группы слотов;
- h2 (младшие 7 бит) — сохраняется в 1 контрольном байте соответствующего слота.
SWAR/SIMD-контроль: В Go группа состоит из 8 слотов (MapGroupSlots = 8). Процессор считывает 8 контрольных байтов (64-битное контрольное слово ctrlGroup) и через параллельные побитовые операции SWAR (или векторные инструкции) сравнивает их с искомым h2 за единичные инструкции без цикла.
Открытая адресация вместо overflow buckets: Нет связных списков и указателей на цепочки переполнения. Все данные лежат в последовательных блоках памяти, что даёт потрясающую кэш-локальность.
Высокий фактор загрузки (Load Factor): Таблица эффективно работает при заполнении до 87.5% (7/8), тогда как старая схема требовала реаллокации уже при ~6.5 элементов на бакет (~81%).

Под капотом (internals)

Старая hmap имела фиксированную структуру бакета:

// Старая схема (Go <= 1.23):
type bmap struct {
    tophash [8]uint8
    keys    [8]keytype
    elems   [8]elemtype
    overflow *bmap // разыменование указателя при коллизии -> L3 cache miss
}

При коллизиях процессор был вынужден «прыгать» по указателям overflow, вызывая Cache Miss. В Swiss Tables контрольные байты и плоские слоты гарантируют, что процессор считывает соседние байты из быстрейшего кэша L1/L2.

Типичные ошибки кандидатов

Заблуждение о детерминированности итерации: Итерация по map в Go 1.24+ по-прежнему намеренно рандомизирована с помощью случайного оффсета, чтобы код разработчиков не зависел от порядка обхода.
Попытка взятия адреса элемента: Взятие адреса &m[k] по-прежнему строго запрещено на уровне языка, так как при эвакуации элементов во время ресайза адреса ячеек памяти меняются.

Возможные дополнительные вопросы интервьюера

Как Swiss Tables облегчают работу Garbage Collector? — Отсутствие указателей на overflow-бакеты уменьшает размер указательного графа, который GC обязан сканировать в фазе маркировки.

Архитектура данных: структуры в памяти и Mechanical Sympathy

Навигатор по вопросам главы

Что такое массив (array)?

Краткий ответ (30–60 секунд)

Развёрнутый ответ

Под капотом (internals)

Типичные ошибки кандидатов

Возможные дополнительные вопросы интервьюера

Чем массив отличается от среза (slice)?

Краткий ответ (30–60 секунд)

Развёрнутый ответ

Под капотом (internals)

Типичные ошибки кандидатов

Возможные дополнительные вопросы интервьюера

Что такое срез (slice)?

Краткий ответ (30–60 секунд)

Развёрнутый ответ

Под капотом (internals)

Типичные ошибки кандидатов

Возможные дополнительные вопросы интервьюера

Как устроен срез (ptr, len, cap)?

Краткий ответ (30–60 секунд)

Развёрнутый ответ

Под капотом (internals)

Типичные ошибки кандидатов

Возможные дополнительные вопросы интервьюера

Что такое len у среза?

Краткий ответ (30–60 секунд)

Развёрнутый ответ

Под капотом (internals)

Типичные ошибки кандидатов

Возможные дополнительные вопросы интервьюера

Что такое capacity у среза?

Краткий ответ (30–60 секунд)

Развёрнутый ответ

Под капотом (internals)

Типичные ошибки кандидатов

Возможные дополнительные вопросы интервьюера

Как работает append?

Краткий ответ (30–60 секунд)

Развёрнутый ответ

Под капотом (internals)

Типичные ошибки кандидатов

Возможные дополнительные вопросы интервьюера

Когда происходит реаллокация (realloc) при append?

Краткий ответ (30–60 секунд)

Развёрнутый ответ

Под капотом (internals)

Типичные ошибки кандидатов

Возможные дополнительные вопросы интервьюера

Как растет capacity среза?

Краткий ответ (30–60 секунд)

Развёрнутый ответ

Под капотом (internals)

Типичные ошибки кандидатов

Возможные дополнительные вопросы интервьюера

Что происходит при копировании среза?

Краткий ответ (30–60 секунд)

Развёрнутый ответ

Под капотом (internals)

Типичные ошибки кандидатов

Возможные дополнительные вопросы интервьюера

Как работает функция copy?

Краткий ответ (30–60 секунд)

Развёрнутый ответ

Под капотом (internals)

Типичные ошибки кандидатов

Возможные дополнительные вопросы интервьюера

Что такое nil срез (nil slice)?

Краткий ответ (30–60 секунд)

Развёрнутый ответ

Под капотом (internals)

Типичные ошибки кандидатов

Возможные дополнительные вопросы интервьюера

Чем nil срез отличается от empty среза?

Краткий ответ (30–60 секунд)

Развёрнутый ответ

Под капотом (internals)

Типичные ошибки кандидатов

Возможные дополнительные вопросы интервьюера

Что такое массив (`array`)?

Чем массив отличается от среза (`slice`)?

Что такое срез (`slice`)?

Что такое `len` у среза?

Что такое `capacity` у среза?

Как работает `append`?

Когда происходит реаллокация (realloc) при `append`?

Как растет `capacity` среза?

Как работает функция `copy`?

Что такое nil срез (`nil slice`)?

Что такое карта (`map`)?

Как устроена карта (`hmap`)?

Что такое бакет (`bucket`) в карте?

Что происходит при расширении (`resize`) карты?

Что такое коллизия хешей (`hash collision`)?

Что такое `load factor`?

Что такое строка (`string`)?