Вопросы и ответы для собеседования Go-разработчика01.04.2022 14:46

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

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

Да, это очень объемный пост, и врятли его можно вдумчиво осилить за один подход, но поместив его в закладки он, возможно, когда-то сослужит вам добрую службу (читать его можно по частям, находясь в метро или между вечными совещаниями; да и Ctrl + F никто не отменял). Ещё ему очень не хватает оглавления для удобной навигации между вопросами, но у хабраредактора нет возможности генерировать TOC (если будут запросы об этом в комментариях — сделаю его руками). Об очепятках, пожалуйста, пишите в личку.


Расскажи о себе?

Чаще всего этот вопрос идёт первым и даёт возможность интервьюверу задать вопросы связанные с твоим резюме, познакомиться с тобой, попытаться понять твой характер для построения последующих вопросов. Следует иметь в виду, что интервьюверу не всегда удается подготовиться к интервью, или он банально не имеет перед глазами твоего резюме. Тут есть смысл ещё раз представиться (часто в мессенджерах используются никнеймы, а твоё реальное имя он мог забыть), назвать свой возраст, образование, рассказать о предыдущих местах работы и должностях, сколько лет в индустрии, какие ЯП и технологии использовал — только «по верхам», для того чтоб твой собеседник просто понял с кем он «имеет дело».


Расскажи о своем самом интересном проекте?

К этому вопросу есть смысл подготовиться заранее и не спустя рукава. Дело в том, что это тот момент, когда тебе надо подобно павлину распустить хвост и создать правильное первое впечатление о себе, так как этот вопрос тоже очень часто идёт впереди всех остальных. Возьми и выпиши для себя где-нибудь на листочке основные тезисы о том, что это был за проект/сервис/задача, уделяя основное внимание тому какой профит это принесло для компании/команды в целом. Например:


  • Я со своей командой гоферов из N человек в течении трех месяцев создали аналог сервиса у которого компания покупала данные за $4000 в месяц, а после перехода на наш сервис — расходы сократились до $1500 в месяц и значительно повысилось их качество и uptime;
  • Внедренные мной практики в CI/CD пайплайны позволили сократить время на ревью изменений в проектах на 25…40%, а зная сколько стоит время работы разработчиков — вы сами всё понимаете;
  • Разработанный мной сервис состоял из такого-то набора микросервисов, такие-то службы и протоколы использовал, были такие-то ключевые проблемы которые мы так-то зарешали; основной ценностью было то-то.


Кем был создан язык, какие его особенности?

Go (часто также golang) — компилируемый многопоточный язык программирования, разработанный внутри компании Google. Разработка началась в 2007 году, его непосредственным проектированием занимались Роберт Гризмер, Роб Пайк и Кен Томпсон. Официально язык был представлен в ноябре 2009 года.

В качестве ключевых особенностей можно выделить:


  • Простая грамматика (минимум ключевых слов — язык создавался по принципу «что ещё можно выкинуть» вместо «что бы ещё в него добавить»)
  • Строгая типизация и отказ от иерархии типов (но с сохранением объектно-ориентированных возможностей)
  • Сборка мусора (GC)
  • Простые и эффективные средства для распараллеливания вычислений
  • Чёткое разделение интерфейса и реализации
  • Наличие системы пакетов и возможность импортирования внешних зависимостей (пакетов)
  • Богатый тулинг «из корочки» (бенчмарки, тесты, генерация кода и документации), быстрая компиляция

Для того, чтоб вспомнить историю создания Go и о его особенностях можно посмотреть:


Go — императивный или декларативный? А в чем разница?

Go является императивным языком.

Императивное программирование — это описание того, как ты делаешь что-то (т.е. конкретно описываем необходимые действия для достижения определенного результата), а декларативное — того, что ты делаешь (например, декларативным ЯП является SQL — мы описываем что мы хотим получить от СУБД, но не описываем как именно она должна это сделать).


Что такое ООП? Как это сделано в Golang?

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


  • Абстракция вообще присуща для любого программирования, а не только для ООП. По большому счету (топорный, но понятный пример) это про выделение общего и объединение этого в какие-то сущности, но без реализации, про контракты. Например — экземпляры абстрактных классов не могут быть созданы (new AbstractClass), но могут содержать абстрактные методы, чтоб разработчик решив наследоваться от этого абстрактного класса их реализовал так, как ему нужно для своих целей (например — ходить в SQL СУБД или файл). Другой пример — это интерфейсы, они же контракты чистой воды — содержат только сигнатуры методов и ни капельки реализации. Но абстракция не ограничивается ими и должна быть умеренной, так как усложняет архитектуру приложения в общем и целом. Опираться следует на интуицию и опыт. Слишком много слоев абстракции (ещё раз — тут дело не ограничивается интерфейсами и абстрактными классами) приводит к переусложнению и головной боли последующего сопровождения продукта. Недостаточная — к сложности внесения изменений и расширению функционала
  • Инкапсуляция про контроль доступа к свойствам объекта и их динамическая валидация/преобразования. Если метод/свойство должно быть доступно «из вне» объекта — объявляем публичным, иначе — приватным. Если есть необходимость переопределять его из потомков класса — то защищенным (protected). Python, например, реализуют инкапсуляцию, но не предусматривает возможности сокрытия в принципе; в то время как С++ и Java она просто всюду
  • Наследование это возможность (барабанная дробь!) наследоваться одним объектам от других, «перенимая» все методы родительских объектов. Своеобразный вариант Матрешки. Т.е. выделяя в родительских объектах «всё общее» мы можем не повторяться в реализации частных, а просто «наследоваться»
  • Полиморфизм — «поли» — много, «морф» — вид. Везде, где есть интерфейсы — подразумевается полиморфизм. Суть — это контракты (интерфейсы), мы можем объявить «что-то умеет закрывать себя методом Close()», и нам не важно что именно это будет. Реализаций может быть много, и если это что-то умеет делать то, что нам надо — нам удобнее с этим работать

Тут же можно упомянуть про знание SOLID, а именно:


  • S (single responsibility principle, принцип единственной ответственности) — определенный класс/модуль должен решать только определенную задачу, максимально узко, но максимально хорошо (своеобразные UNIX-way). Если для выполнения своей задачи ему требуются какие-то другие ресурсы — они в него должны быть инкапсулированы (это отсылка к принципу инверсии зависимостей)
  • O (open-closed principle, принцип открытости/закрытости) — классы/модули должны быть открыты для расширения, но закрыты для модификации. Должна быть возможность расширить поведение, наделить новым функционалом, но при этом исходный код/логика модуля должна быть неизменной
  • L (Liskov substitution principle, принцип подстановки Лисков) — поведение наследующих классов не должно противоречить поведению, заданному базовым классом, то есть поведение наследующих классов должно быть ожидаемым для кода
  • I (interface segregation principle, принцип разделения интерфейса) — много тонких интерфейсов лучше, чем один толстый
  • D (dependency inversion principle, принцип инверсии зависимостей) — «завязываться» на абстракциях (интерфейсах), а не конкретных реализациях. Так же (это уже про IoC, но всё же) можно рассказать что если какому-то классу для своей работы требуется функциональность другого — то есть смысл «запрашивать» её в конструкторе нашего класса используя интерфейс, под который подходит наша зависимость. Таким образом целевая реализация опирается только на интерфейсы (не зависит от реализаций) и соответствует принципу под буквой S

А теперь о том, как это реализовано в Go (наконец-то!).

В Go нет классов, объектов, исключений и шаблонов. Нет иерархии типов, но есть сами типы (т.е. возможность описывать свои типы/структуры). Структурные типы (с методами) служат тем же целям, что и классы в других языках. Так же следует упомянуть что структура определяет состояние.

В Go нет наследования. Совсем. Но есть встраивание (называемое «анонимным», так как Foo в Bar встраивается не под каким-то именем, а без него) при этом встраиваются и свойства, и функции: 

import "fmt"

type Foo struct {
    name    string
    Surname string
}

func (f Foo) SayName() string { return f.name }

type Bar struct {
    Foo
}

func main() {
    bar := Bar{Foo{name: "one", Surname: "baz"}}

    fmt.Println(bar.SayName()) // one
    fmt.Println(bar.Surname)   // baz

    bar.name = "two"

    fmt.Println(bar.SayName()) // two
}

Есть интерфейсы (это типы, которые объявляют наборы методов). Подобно интерфейсам в других языках, они не имеют реализации. Объекты, которые реализуют все методы интерфейса, автоматически реализуют интерфейс (так называемый Duck-typing). Не существует наследования или подклассов или ключевого слова Implements: 

import "fmt"

type Speaker interface {
    Speak() string
}

type Foo struct{}

func (Foo) Speak() string { return "foo" }

type Bar struct{}

func (Bar) Speak() string { return "bar" }

func main() {
    var foo, bar Speaker = new(Foo), &Bar{}

    fmt.Println(foo.Speak()) // foo
    fmt.Println(bar.Speak()) // bar
}

В примере выше мы объявили переменные foo и bar с явным указанием интерфейсного типа, а так интерфейс это «ссылочный» тип (на самом деле в Go нет ссылок, но есть указатели) — то и структуры мы инициализировали указателями на них с использованием new() (что аллоцирует структуру и возвращает указатель на неё) и (или) &.

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

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


Что можно почитать: ООП в картинках, Golang и ООП


Как устроено инвертирование зависимостей?

Инвертирование зависимостей позволяет в нашем коде не «завязываться» на конкретную реализацию (используя, например, интерфейсы), тем самым понижая связанность кода и повышая его тестируемость. Так же сужается зона ответственности конечной структуры/пакета, что повышает его переиспользуемость.

Принцип инверсии зависимостей (dependency inversion principle) в Go который можно реализовывать следующим образом: 

import (
    "errors"
    "fmt"
)

type speaker interface {
    Speak() string
}

type Foo struct {
    s speaker // s *Foo - было бы плохо
}

func NewFoo(s speaker) (*Foo, error) {
    if s == nil {
        return nil, errors.New("speaker is nil")
    }

    return &Foo{s: s}, nil
}

func (f Foo) SaySomething() string { return f.s.Speak() }

func main() {
    var foo, err = NewFoo(someSpeaker)

    if err != nil {
        panic(err)
    }

    fmt.Println(foo.SaySomething()) // depends on the speaker implementation
}

Мы объявляем интерфейс speaker не экспортируемым на нашей, принимающей стороне, и используя псевдо-конструктор NewFoo гарантируем что свойство s будет проинициализировано верным типом (дополнительно проверяя его на nil).


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

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


Типы данных и синтаксис

К фундаментальным типам данных можно отнести:


  • Целочисленные — int{8,16,32,64}, int, uint{8,16,32,64}, uint, byte как синоним uint8 и rune как синоним int32. Типы int и uint имеют наиболее эффективный размер для определенной платформы (32 или 64 бита), причем различные компиляторы могут предоставлять различный размер для этих типов даже для одной и той же платформы
  • Числа с плавающей запятой — float32 (занимает 4 байта/32 бита) и float64 (занимает 8 байт/64 бита)
  • Комплексные числа — complex64 (вещественная и мнимая части представляют числа float32) и complex128 (вещественная и мнимая части представляют числа float64)
  • Логические aka bool
  • Строки string


Как устроены строки в Go?

В Go строка в действительности является слайсом (срезом) байт, доступным только для чтения. Строка содержит произвольные байты, и у неё нет ёмкости (cap). При преобразовании слайса байт в строку (str := string(slice)) или обратно (slice := []byte(str)) — происходит копирование массива (со всеми следствиями).

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

var (
    str = "hello world"
    sub = str[0:5]
    usr = "/usr/kot"[5:]
)

print(sub, " ", usr) // hello kot

Go использует тип rune (алиас int32) для представления Unicode. Конструкция for ... range итерирует строку посимвольно (а не побайтово, как можно было бы предположить): 

var str = "привет"

println(str, len(str)) // привет 12

for i, c := range str {
    println(i, c, string(c))
}

// 0 1087 п
// 2 1088 р
// 4 1080 и
// 6 1074 в
// 8 1077 е
// 10 1090 т

И мы видим, что для кодирования каждого символа кириллицы используются по 2 байта.

Эффективным способом работы со строками (когда есть необходимость часто выполнять конкатенацию, например) является использование слайса байт или strings.Builder: 

import "strings"

func main() { // происходит только 1 аллокация при вызове `Grow()`
    var str strings.Builder

    str.Grow(12) // сразу выделяем память

    str.WriteString("hello")
    str.WriteRune(' ')
    str.WriteString("мир")

    println(str.String()) // hello мир
}

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

const str = "hello мир!"

println(len(str), utf8.RuneCountInString(str)) // 13 10

Тут дело в том, что для кодирования символов м, и и р используются 2 байта вместо одного. Поэтому len == 13, а фактически в строке лишь 10 символов (пакет utf8, к примеру, нам в помощь).


Что можно почитать: Строка, байт, руна, символ в Golang


В чём ключевое отличие слайса (среза) от массива?


  • Срез — всегда указатель на массив, массив — значение
  • Срез может менять свой размер и динамически аллоцировать память


В Go не бывает ссылок —, но есть указатели. Где говорится про «по ссылке» имеется в виду «по указателю»

Слайсы и массивы в Go это проиндексированные упорядоченные структуры данных последовательностей элементов. Ёмкость массива объявляется в момент его создания, и после изменить её уже нельзя (его длина это часть его типа). Память, необходимая для хранения элементов массива выделяется соответственно сразу при его объявлении, и по умолчанию инициализируется в соответствии с нулевыми значением для типа (fasle для bool, 0 для int, nil для интерфейсов и т.д.). На стеке можно разместить массив объемом 10 MB. В качестве размера можно использовать константы (компилятор должен знать это значение на этапе компиляции, т.е. что-то вида var a [getSize()]int или i := 3; var a [i]int недопустимо): 

const mySize uint8 = 8

type myArray [mySize]byte

var constSized = [...]int{1, 2, 3} // размер сам посчитается исходя из кол-ва эл-ов

Кстати, массивы с элементами одного типа, но с разными размерами являются разными типами. Массивы не нужно инициализировать явно; нулевой массив — это готовый к использованию массив, элементы которого являются нулями: 

var a [4]int // [0 0 0 0]

a[0] = 1  // [1 0 0 0]
i := a[0] // i == 1

Представление [4]int в памяти — это просто четыре целых значения, расположенных последовательно. Так же следует помнить что в Go массивы передаются по значению, т.е. передавая массив в какую-либо функцию она получает копию массива (для передачи его указателя нужно явно это указывать, т.е. foo(&a)).

А слайс же это своего рода версия массива, но с вариативным размером (структура данных, которая строится поверх массива и предоставляет доступ к элементами базового массива). Слайсы до 64 KB могут быть размещены на стеке. Если посмотреть исходники Go (src/runtime/slice.go), то увидим: 

type slice struct {
    array unsafe.Pointer // указатель на массив
    len   int            // длина (length)
    cap   int            // вместимость (capacity)
}

Для аллокации слайса можно воспользоваться одной из команд ниже: 

var (
    a = []int{}            // []              len=0 cap=0
    b = []int{1, 2}        // [1 2]           len=2 cap=2
    c = []int{5: 123}      // [0 0 0 0 0 123] len=6 cap=6
    d = make([]int, 5, 10) // [0 0 0 0 0]     len=5 cap=10
)

В последнем случае рантайм Go создаст массив из 10 элементов (выделит память и заполнит их нулями), но доступны прямо сейчас нам будут только 5, и установит значения len в 5, а cap в 10. Cap означает ёмкость и помогает зарезервировать место в памяти на будущее, чтобы избежать лишних операций выделения памяти при росте слайса (это ключевой параметр для аллокации памяти, влияет на производительность вставки в срез). При добавлении новых элементов в слайс новый массив для него не будет создаваться до тех пор, пока cap меньше len.

Слайсы передаются «по ссылке» (фактически будет передана копия структуры slice со своими len и cap, но указатель на массив array будет тот-же самый). Для защиты слайса от изменений следует передавать его копию: 

var (
    a = []int{1, 2, 0, 0, 1}
    b = make([]int, len(a))
)

copy(b, a)

fmt.Println(a, b) // [1 2 0 0 1] [1 2 0 0 1]

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

var (
    one = []int{1, 2} // [1 2]
    two = one         // [1 2]
)

two[0] = 123

fmt.Println(one, two) // [123 2] [123 2]

one = append(one, 666)

fmt.Println(one, two) // [123 2 666] [123 2]


Что можно почитать: Как не наступать на грабли в Go, Слайсы в Go: использование и особенности, Принцип работы типа slice в GO


Как вы отсортируете массив структур по алфавиту по полю Name?

Например, преобразую массив в слайс и воспользуюсь функцией sort.SliceStable: 

package main

import (
  "fmt"
  "sort"
)

func main() {
  var arr = [...]struct{ Name string }{{Name: "b"}, {Name: "c"}, {Name: "a"}}
  //             ^^^^^^^^^^^^^^^^^^^^^ анонимная структура с нужным нам полем

  fmt.Println(arr) // [{b} {c} {a}]

  sort.SliceStable(arr[:], func(i, j int) bool { return arr[i].Name < arr[j].Name })
  //                  ^^^ вот тут вся "магия" - из массива сделали слайс

  fmt.Println(arr) // [{a} {b} {c}]
}

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


Как работает append в слайсе?

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

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

Увеличении размера слайса (метод growslice) происходит по следующему алгоритму — если его размер менее 1024 элементов, то его размер будет увеличиваться вдвое; иначе же слайс увеличивается на ~12.5% от своего текущего размера.

Что важно помнить — если на основании слайса one выделить подслайс two, а затем увеличим слайс one (и его вместимость будет превышена) — то one и two будут уже ссылаться на разные участки памяти! 

var (
    one = make([]int, 4) // [0 0 0 0]
    two = one[1:3]       // [0 0]
)

one[2] = 11

fmt.Println(one, two)           // [0 0 11 0] [0 11]
fmt.Printf("%p %p\n", one, two) // 0xc0000161c0 0xc0000161c8

one = append(one, 1)

fmt.Printf("%p %p\n", one, two) // 0xc00001c1c0 0xc0000161c8

one[2] = 22

fmt.Println(one, two)           // [0 0 22 0 1] [0 11]
fmt.Printf("%p %p\n", one, two) // 0xc00001c1c0 0xc0000161c8

Есть еще много примеров добавления, копирования и других способов использования слайсов тут — Slice Tricks.


Что можно почитать: Как не наступать на грабли в Go


Задача про слайсы #1

Вопрос: У нас есть 2 функции — одна делает append() чего-то в слайс, а другая просто сортирует слайс, используя пакет sort. Модифицируют ли слайс первая и (или) вторая функции?

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


Задача про слайсы #2

Вопрос: Что выведет следующая программа? 

package main

import "fmt"

func main() {
  a := [5]int{1, 2, 3, 4, 5}
  t := a[3:4:4]

  fmt.Println(t[0])
}


Ответ

Выведет 4

Объяснение: Такой синтаксис позволяет задать capacity (вместимость) для полученного под-слайса, который будет равен «последний элемент минус первый элемент из выражения в квадратных скобках», т.е. из примера выше он будет равен 1 (т.к. от четырёх, т.е. третьего сегмента вычитаем первый, т.е. тройку). Если бы выражение имело вид a[3:4:5], то cap была бы равна 2 (5 — 3 = 2). Но при этом на сами данные он не влияет.

Появилась эта штука в Go 1.2.


Что можно почитать: Slicing a slice with slice [a : b : c], Full slice expressions


Какое у слайса zero value? Какие операции над ним возможны?

Zero value у слайса всегда nil, а len и cap равны нулю, так как «под ним» нет инициализированного массива: 

var a []int

println(a == nil, len(a), cap(a)) // true 0 0
a = append(a, 1)
println(a == nil, len(a), cap(a)) // false 1 1

Как видно из примера выше — несмотря на то, что a == nil (слайс «не инициализирован»), с этим слайсом возможна операция append — в этом случае Go самостоятельно создаёт нижележащий массив и всё работает так, как и ожидается. Более того — для полной очистки слайса рекомендуется его присваивать к nil.

Так же важно помнить, что не делая make для слайса — не получится сделать пре-аллокацию, что часто очень болезненно для производительности.


Что можешь рассказать про map?

Карта (map или hashmap) — это неупорядоченная коллекция пар вида ключ-значение. Пример: 

type myMap map[string]int

Подобно массивам и слайсам, к элементам мапы можно обратиться с помощью скобок: 

var m = make(map[string]int) // инициализация

m["one"] = 1 // запись в мапу

fmt.Println(m["one"], m["two"]) // 1 0


Лучше выделить память заранее (передавая вторым аргументом функции make), если известно количество элементов — избежим эвакуаций

В случае с m["two"] вернулся 0 так как это является нулевым значением для типа int. Для проверки существования ключа используем конструкцию вида (доступ к элементу карты может вернуть два значения вместо одного) называемую «multiple assignment»: 

var m = map[string]int{"one": 1}

v1, ok1 := m["one"] // чтение
v2, ok2 := m["two"]

fmt.Println(v1, ok1) // 1 true
fmt.Println(v2, ok2) // 0 false

for k, v := range m { // итерация всех эл-ов мапы
    fmt.Println(k, v)
}

delete(m, "one") // удаление

v1, ok1 = m["one"]

fmt.Println(v1, ok1) // 0 false

Мапы всегда передаются по ссылке (вообще-то Go не бывает ссылок, невозможно создать 2 переменные с 1 адресом, как в С++ например;, но зато можно создать 2 переменные, указывающие на один адрес —, но это уже указатели). Если же быть точнее, то мапа в Go — это просто указатель на структуру hmap: 

type hmap struct {
    // Note: the format of the hmap is also encoded in cmd/compile/internal/reflectdata/reflect.go.
    // Make sure this stays in sync with the compiler's definition.
    count     int // # live cells == size of map.  Must be first (used by len() builtin)
    flags     uint8
    B         uint8  // log_2 of # of buckets (can hold up to loadFactor * 2^B items)
    noverflow uint16 // approximate number of overflow buckets; see incrnoverflow for details
    hash0     uint32 // hash seed

    buckets    unsafe.Pointer // array of 2^B Buckets. may be nil if count==0.
    oldbuckets unsafe.Pointer // previous bucket array of half the size, non-nil only when growing
    nevacuate  uintptr        // progress counter for evacuation (buckets less than this have been evacuated)

    extra *mapextra // optional fields
}

Так же структура hmap содержит в себе следующее:


  • Количество элементов
  • Количество «ведер» (представлено в виде логарифма для ускорения вычислений)
  • Seed для рандомизации хэшей (чтобы было сложнее заddosить — попытаться подобрать ключи так, что будут сплошные коллизии)
  • Всякие служебные поля и главное указатель на buckets, где хранятся значения

ajygnfp_745tid9futbqteysivc.png

На картинке схематичное изображение структуры в памяти — есть хэдер hmap, указатель на который и есть map в Go (именно он создается при объявлении с помощью var, но не инициализируется, из-за чего падает программа при попытке вставки). Поле buckets — хранилище пар ключ-значение, таких «ведер» несколько, в каждом лежит 8 пар. Сначала в «ведре» лежат слоты для дополнительных битов хэшей (e0..e7 названо e — потому что extra hash bits). Далее лежат ключи и значения как сначала список всех ключей, потом список всех значений.

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


Как растет map?

В исходном коде можно найти строчку Maximum average load of a bucket that triggers growth is 6.5. То есть, если в каждом «ведре» в среднем более 6,5 элементов, происходит увеличение массива buckets. При этом выделяется массив в 2 раза больше, а старые данные копируются в него маленькими порциями каждые вставку или удаление, чтобы не создавать очень крупные задержки. Поэтому все операции будут чуть медленнее в процессе эвакуации данных (при поиске тоже, нам же приходится искать в двух местах). После успешной эвакуации начинают использоваться новые данные.

Из-за эвакуации данных нельзя и взять адрес мапы — представьте, что мы взяли адрес значения, а потом мапа выросла, выделилась новая память, данные эвакуировались, старые удалились, указатель стал неправильным, поэтому такие операции запрещены.


Что там про поиск?

Поиск, если разобраться, устроен не так уж и сложно: проходимся по цепочкам «ведер», переходя в следующее, если в этом не нашли. Поиск в «ведре» начинается с быстрого сравнения дополнительного хэша, для которого используется всего 8 бит (вот для чего эти e0...e7 в начале каждого — это «мини» хэш пары для быстрого сравнения). Если не совпало, идем дальше, если совпало, то проверяем тщательнее — определяем где лежит в памяти ключ, подозреваемый как искомый, сравниваем равен ли он тому, что запросили. Если равен, определяем положение значения в памяти и возвращаем.

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


Что можно почитать: Хэш таблицы в Go. Детали реализации, Кажется, поиск в map дороже чем O (1)


Есть ли у map такие же методы как у слайса: len, cap?

У мапы есть len, но нет cap. У нас есть только overflow который указывает «куда-то» когда мапа переполняется, и поэтому у нас не может быть capacity.


Какие типы ключей разрешены для ключа в map?

Любым сравнимым (comparable) типом, т.е. булевы, числовые, строковые, указатели, канальные и интерфейсные типы, а также структуры или массивы, содержащие только эти типы. Слайсы, мапы и функции использовать нельзя, так как эти типы не сравнить с помощью оператора == или !=.


Может ли ключом быть структура? Если может, то всегда ли?

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


Что будет в map, если не делать make или short assign?

Будет паника (например — при попытке что-нибудь в неё поместить), так как любые «структурные» типы (а мапа как мы знаем таковой является) должны быть инициализированы для работы с ними.


Race condition. Потокобезопасна ли мапа?

Нет, потокобезопасной является sync.Map. Для обеспечения безопасности вокруг мапы обычно строится структура вида: 

type ProtectedIntMap struct {
    mx sync.RWMutex
    m  map[string]int
}

func (m *ProtectedIntMap) Load(key string) (val int, ok bool) {
    m.mx.RLock()
    val, ok = m.m[key]
    m.mx.RUnlock()

    return
}

func (m *ProtectedIntMap) Store(key string, value int) {
    m.mx.Lock()
    m.m[key] = value
    m.mx.Unlock()
}


Что такое интерфейс?

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


Как устроен Duck-typing в Go?


Если это выглядит как утка, плавает как утка и крякает как утка, то это, вероятно, утка и есть.

Если структура содержит в себе все методы, что объявлены в интерфейсе, и их сигнатуры совпадают — она автоматически удовлетворяет интерфейс.

Такой подход позволяет полиморфно (полиморфизм — способность функции обрабатывать данные разных типов) работать с объектами, которые не связаны в иерархии наследования. Достаточно, чтобы все эти объекты поддерживали необходимый набор методов.


Интерфейсный тип

В Go интерфейсный тип выглядит вот так: 

type iface struct {
    tab  *itab
    data unsafe.Pointer
}

Где tab — это указатель на Interface Table или itable — структуру, которая хранит некоторые метаданные о типе и список методов, используемых для удовлетворения интерфейса, а data указывает на реальную область памяти, в которой лежат данные изначального объекта (статическим типом).

Компилятор генерирует метаданные для каждого статического типа, в которых, помимо прочего, хранится список методов, реализованных для данного типа. Аналогично генерируются метаданные со списком методов для каждого интерфейса. Теперь, во время исполнения программы, runtime Go может вычислить itable на лету (late binding) для каждой конкретной пары. Этот itable кешируется, поэтому просчёт происходит только один раз.

Зная это, становится очевидно, почему Go ловит несоответствия типов на этапе компиляции, но кастинг к интерфейсу — во время исполнения.

Что важно помнить — переменная интерфейсного типа может принимать nil. Но так как объект интерфейса в Go содержит два поля: tab и data — по правилам Go, интерфейс может быть равен nil только если оба этих поля не определены (faq): 

var (
    builder  *strings.Builder
    stringer fmt.Stringer
)

fmt.Println(builder, stringer) // nil nil
fmt.Println(stringer == nil)   // true
fmt.Println(builder == nil)    // true

stringer = builder

fmt.Println(builder, stringer) // nil nil
fmt.Println(stringer == nil)   // false (!!!)
fmt.Println(builder == nil)    // true


Пустой interface{}

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


Что можно почитать: Краш-курс по интерфейсам в Go, Реализация интерфейсов в Golang, Инт

© Habrahabr.ru