❓ Как происходит передача значений в функции, вызовы которых отложены с помощью defer

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

Сам вызов функции с defer будет выполнен уже после завершения текущего блока кода или функции, но с теми значениями аргументов, которые были на момент вызова defer.

Пример:

package main

import "fmt"

func main() {
    x := 10
    defer fmt.Println("До:", x) // x вычисляется сейчас, но вывод откладывается
    x = 20
    fmt.Println("После:", x)
}

Выведется 20 и 10, потому что значение x для defer зафиксировалось при объявлении defer, а не к моменту выполнения отложенной функции.

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

❓ У вас есть массив чисел, в котором все числа встречаются по два раза, кроме одного — уникального, которое встречается один раз. Как вы бы решили эту задачу используя операцию XOR

Суть метода в свойствах XOR:

• Любое число XOR с самим собой дает 0:
a⊕a = 0
a⊕a = 0.

• Любое число XOR с нулем дает само число:
a⊕0 = a
a⊕0 = a.

• Операция XOR коммутативна и ассоциативна, то есть порядок операндов не важен.

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

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

❓ В чем практические и внутренние различия между буферизованными и небуферизованными каналами

Небуферизованный канал — строгий. Отправка и прием завершаются одновременно и образуют отношение happens-before между записью и чтением значения.

Буферизованный канал хранит элементы в кольцевом буфере внутри структуры до выборки получателем. Отправитель блокируется лишь при полном буфере.

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

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

❓ Зачем нужен канал с размером 1

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

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

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

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

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

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

❓ Какова алгоритмическая сложность обращения к мапе

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

При переаллокации данных сложность может деградировать до O(n).

Это происходит, когда количество элементов в мапе превышает load factor, примерно 6,125 элементов на баккет в среднем, или около 81% заполненности. Тогда Go выделяет новую память под бакеты в два раза больше и постепенно переносит данные из старых бакетов в новые.

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