❓ Почему большой int64 может исказиться при разборе JSON

JSON по спецификации не имеет строгих типов int32/int64 — там есть только number, а в Go при разборе encoding/json число сначала парсится в float64, если не указан конкретный тип.

Есть несколько решений:

Использовать строки для больших чисел:

{"id": "9223372036854775807"}

Использовать json.Decoder.UseNumber():

dec := json.NewDecoder(r)
dec.UseNumber()

Кастомный Unmarshal

Читать как json.Number и вручную конвертировать в int64

🐸 Библиотека Go для собеса

❓ Как объединить два отсортированных среза в один

Классическая операция из mergesort. Заводим три указателя: i для a, j для b, k для результата. Сравниваем текущие элементы обоих срезов и берём меньший. После того как один из срезов закончился, дописываем остаток другого.

func mergeSorted(a, b []int) []int {
    res := make([]int, 0, len(a)+len(b))
    i, j := 0, 0
    for i < len(a) && j < len(b) {
        if a[i] <= b[j] {
            res = append(res, a[i])
            i++
        } else {
            res = append(res, b[j])
            j++
        }
    }
    res = append(res, a[i:]...)
    res = append(res, b[j:]...)
    return res
}

a[i:]... добавляет хвост одной операцией без лишнего цикла. Сложность O(n + m) по времени, O(n + m) по памяти на результат.

🐸 Библиотека Go для собеса

❓ Какого типа результат len и можно ли индексировать срез значением int64

len и cap возвращают int, индексы тоже имеют тип int. Индексировать срез значением int64 напрямую нельзя, нужна конверсия к int. Из-за этого длина среза ограничена размером int на платформе.

🐸 Библиотека Go для собеса

❓ У вас есть map[int]Record. Несколько горутин читают и пишут в него одновременно. Что произойдёт

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

🐸 Библиотека Go для собеса

❓ Разработчик создаёт time.NewTicker внутри цикла и забывает вызвать ticker.Stop(). Что произойдёт

time.NewTicker регистрирует таймер в runtime heap таймеров. Раньше GC не собирал тикеры автоматически — они жили, пока не будет вызван Stop().

Начиная с Go 1.23 ситуация изменилась: garbage collector теперь может собирать неиспользуемые тикеры, если на них больше нет ссылок. То есть забытый Stop() больше не гарантирует утечку памяти.

⚠️ Важно

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

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

Как это поймать

go tool pprof с профилем goroutines покажет горутины, заблокированные на чтении из каналов тикеров. Heap-профиль может показать рост объектов, связанных с таймерами.

🐸 Библиотека Go для собеса

❓ Чем io.EOF отличается от io.ErrUnexpectedEOF? В каком случае Read должен возвращать EOF, а в каком — ErrUnexpectedEOF

io.EOF — сигнал о штатном конце данных. Read возвращает его когда источник исчерпан и больше нечего читать. Это не ошибка в смысле «что-то пошло не так» — это нормальное завершение потока.

По спецификации io.Reader, EOF может прийти либо вместе с последними байтами (n > 0, err == io.EOF), либо отдельным вызовом (n == 0, err == io.EOF). Оба варианта корректны — поэтому правильный код всегда сначала обрабатывает прочитанные байты, потом проверяет ошибку.

io.ErrUnexpectedEOF — сигнал о том, что поток закончился в неожиданном месте. Источник данных иссяк раньше, чем ожидалось по протоколу или по запросу.

Типичный пример — io.ReadFull. Функция просит ровно len(buf) байт. Если источник вернул EOF до того, как буфер заполнен, ReadFull транслирует это в ErrUnexpectedEOF.

🐸 Библиотека Go для собеса

❓ Вам нужно итерироваться по map[string]int и получать элементы всегда в одном и том же порядке. Какой подход использовать

Порядок итерации по map в Go намеренно рандомизирован с версии 1.0. Это сделано специально, чтобы разработчики не полагались на порядок как на гарантию.
 
Надёжный способ: keys := make([]string, 0, len(m)) → заполнить ключами → sort.Strings(keys) → итерироваться по слайсу, читая значения из map.
 
Отдельный вопрос со звёздочкой: если ключи — числа, а не строки, тип ключа влияет на аллокации при сортировке. []int с sort.Ints не аллоцирует лишнего, тогда как конвертация в []interface{} для универсальной сортировки создаёт нагрузку на GC при большом количестве элементов.

🐸 Библиотека Go для собеса

❓ Что возвращает append

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

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

🐸 Библиотека Go для собеса

❓ Что возвращает copy и сколько элементов он копирует

copy копирует элементы из исходного слайса в целевой и возвращает число скопированных элементов. Это число равно минимуму из len(dst) и len(src). Лишние элементы источника просто игнорируются, ошибки не будет.

src := []int{1, 2, 3, 4}
dst := make([]int, 2)
n := copy(dst, src)
fmt.Println(n, dst) // 2 [1 2]

🐸 Библиотека Go для собеса

❓ Как Go работает с комплексными числами

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

Два встроенных типа

Есть complex64 и complex128. У complex64 действительная и мнимая части это float32, у complex128 это float64. По умолчанию нетипизированная комплексная константа имеет тип complex128, поэтому в большинстве случаев работают именно с ним.

Как создать комплексное число

Двумя способами. Через литерал с суффиксом i для мнимой части:

z := 2 + 3i

Либо через встроенную функцию complex, которая собирает число из двух вещественных частей одного типа:

re := 2.0
im := 3.0
z := complex(re, im) // complex128

🐸 Библиотека Go для собеса

❓ Что будет, если тело функции в Go — пустые фигурные скобки

Функция с пустым телом компилируется без ошибок. Она ничего не делает, ничего не возвращает:

func doNothing() {}

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

🐸 Библиотека Go для собеса

❓ Как получить действительную и мнимую части обратно из комплексного числа

Встроенными функциями real и imag. Первая возвращает действительную часть, вторая мнимую. Тип результата совпадает с базовым типом числа, то есть float32 для complex64 и float64 для complex128:

n := complex(2.0, 3.0)
fmt.Println(real(n), imag(n)) // 2 3

🐸 Библиотека Go для собеса

❓ Какие основные отличия горутины от потока

➡️ Поток создаёт и планирует операционная система через своё ядро. Горутиной управляет рантайм Go. Его планировщик работает в пользовательском пространстве и не дёргает ядро на каждое переключение.

➡️ Поток получает фиксированный стек, обычно от 1 до 8 МБ. Горутина стартует со стеком примерно в 2 КБ, и этот стек растёт и сжимается по мере надобности. Поэтому горутин можно держать сотни тысяч, а потоков столько вы не создадите.
 
➡️ Создание потока дорогое, оно идёт через системный вызов. Горутина создаётся дёшево, это по сути структура в памяти рантайма. Отсюда и разница в количестве.

➡️ Переключение потоков делает ядро, это полноценный контекстный свич с заметными затратами. Переключение горутин происходит в пользовательском пространстве и стоит дешевле.

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

🐸 Библиотека Go для собеса

❓ В чём основная разница между new и make

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

make создаёт и инициализирует значение и возвращает само значение, а не указатель.

Ещё одно отличие в области применения. new работает с любым типом, а make только со слайсами, мапами и каналами.

🐸 Библиотека Go для собеса