Интерфейс в Go: два слова, nil, который не nil, и вызов дороже в четыре раза

Что здесь на самом деле спрашивают

Лестница почти всегда такая:

1. «Как устроен интерфейс внутри?» — проверяют, скажете ли вы «два слова» или ограничитесь словом «контракт».
2. «Почему err != nil сработало, хотя вернули nil?» — та самая ловушка; спрашивают её чаще всего остального вместе взятого.
3. «Когда помещение значения в интерфейс выделяет память?» — проверяют, понимаете ли вы, что второе слово — указатель.
4. «Вызов через интерфейс дороже прямого? Насколько?» — вопрос на честность: «незначительно» и «в разы» одинаково плохи без числа.
5. «Чем x.(T) отличается от switch x := v.(type)?» — проверяют, знаете ли вы, что обе формы делают одно и то же.
6. «Почему мой тип не реализует интерфейс?» (с кодом) — про наборы методов и получатель-указатель.

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

База: реализация без объявления

Интерфейс в Go — это список методов, которому дали имя. Stringer ничего не говорит о том, из чего состоит значение и откуда оно взялось; он говорит одно: «это умеет String() string». Функция, объявляющая параметр типа Stringer, тем самым требует не конкретный тип, а способность.

Дальше идёт решение, которого нет в большинстве языков: тип реализует интерфейс молча. Ни implements, ни списка интерфейсов у типа — компилятор сам смотрит, есть ли нужные методы, и если есть, значение подходит. Объявлять о намерении не надо, и объявить его негде.

bench/gointerface/methodsets.sh собирает и запускает программу, в которой Point не упоминает Stringer ни одним словом:

type Stringer interface{ String() string }
 
type Point struct{ X, Y int }
 
func (p Point) String() string { return fmt.Sprintf("(%d,%d)", p.X, p.Y) }
 
var s Stringer = Point{1, 2}

assigned: (1,2)
--- exit code: 0

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

Интерфейс принадлежит тому, кто его ПОТРЕБЛЯЕТ, а не тому, кто реализует. Объявить Stringer можно в своём пакете — и Point из чужой библиотеки будет его реализовывать, ничего не зная о вашем существовании. В языках с явной реализацией так нельзя: чтобы тип подошёл под интерфейс, его надо изменить.

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

Практическое следствие того же: интерфейсы в Go маленькие. io.Reader — один метод, io.Writer — один. Интерфейс на десять методов почти всегда означает, что его объявили со стороны реализации, а не со стороны нужды.

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

Механизм 1: набор методов — где неявность кончается

Тихая реализация имеет ровно одну границу, и на ней спотыкаются все. Метод с получателем-указателем не входит в набор методов значения.

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

func (p *Point) String() string { return "point" }
 
var byValue Stringer = Point{1, 2}     // ошибка
var byPointer Stringer = &Point{1, 2}  // законно

bad.go:10:25: cannot use Point{…} (value of struct type Point) as Stringer value in variable declaration: Point does not implement Stringer (method String has pointer receiver)
--- go build exit code: 1

Ошибку стоит уметь прочитать вслух целиком: она называет причину сама.

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

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

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

Механизм 2: динамический тип и динамическое значение

Теперь модель, из которой выводится всё остальное, — и она не про рантайм. Интерфейсная переменная несёт две вещи: какой конкретный тип в ней сейчас лежит и какое значение этого типа.

Две вещи, а не одна, — и это не деталь реализации, а наблюдаемая семантика:

var s Stringer          // тип: нет,      значение: нет
s = Point{1, 2}         // тип: Point,    значение: {1, 2}
s = &Point{1, 2}        // тип: *Point,   значение: адрес

Отсюда сразу три вещи, которые спрашивают по отдельности.

Утверждение типа возвращает конкретный тип обратно. s.(Point) спрашивает не «похоже ли», а «динамический тип ровно Point?». Именно поэтому *Point не подойдёт под Point — это разные динамические типы.

Сравнение интерфейсов сравнивает пару целиком. Равны, если совпал и тип, и значение. Отсюда же паника при сравнении интерфейсов с несравнимым динамическим типом внутри: сравнивать срез нечем.

И главное — интерфейс пуст, только когда пусты ОБЕ половины. Это следующий механизм, и это самый частый вопрос собеседования по Go.

Механизм 3: nil, который не nil

Это самый частый вопрос собеседования по Go, и отвечать на него надо не фразой, а механизмом.

Правило одно, и оно записано в FAQ языка:

Теперь посмотрите, что происходит с двумя словами в каждом из четырёх случаев — переключайте:

Ловушка целиком видна на переключении между первым и вторым случаем: второе слово в обоих пусто, отличаются они только первым. Именно поэтому

var p *NotFound      // nil-указатель
var err error = p    // но интерфейс уже не пуст: тип известен
fmt.Println(err == nil)   // false

даёт false. Значение внутри — нулевой указатель, но слово с типом заполнено, а правило требует, чтобы пусты были оба.

Где это стреляет в реальном коде. Всегда в одном месте — когда функция объявлена возвращающей error, а внутри возвращает конкретный тип ошибки:

func do() error {
    var e *MyErr          // nil
    if bad() {
        e = &MyErr{}
    }
    return e              // ЛОВУШКА: даже когда e == nil, error != nil
}

Вызывающий пишет if err != nil — и получает «ошибку», которой нет.

Лечится это тремя способами, и назвать стоит все три:

1. Объявить переменную интерфейсного типа, а не конкретного: var err error — тогда при отсутствии ошибки в ней действительно пусты оба слова.
2. Возвращать nil явно в успешной ветке: return nil, а не return e.
3. Не хранить конкретные типы ошибок в промежуточных переменных — это первопричина, а первые два пункта лечат её симптомы.

Правило для запоминания: конкретный тип не переживает присваивания в интерфейс незаметно. Как только значение положено в интерфейс, его тип там остаётся — даже если самого значения нет.

Механизм 4: утверждение типа — это сравнение указателя

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

Замерено на одинаковой работе — в тех же прогонах и на той же машине, что и остальные числа урока:

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

Что действительно надо знать про эти формы:

• Форма с одним результатом паникует, с двумя — нет: v.(int) против v, ok := x.(int). В коде, который не контролирует источник значения, всегда вторая.
• Спецификация требует, чтобы x было не nil: x.(T) утверждает, that x is not nil and that the value stored in x is of type T (что x не равно nil и что хранящееся в x значение имеет тип T). Утверждение на чистом nil-интерфейсе не пройдёт никогда.
• case nil в type switch ловит именно чистый nil — тот, где пусты оба слова. Типизированный nil попадёт в ветку своего типа, и это ещё одно место, где ловушка с nil, который не nil, выходит боком.

Механизм 5: как этим пользуются

Последний механизм — не про устройство, а про то, во что всё сказанное превращается в чужом коде. Три правила, и каждое выводится из уже сказанного.

Интерфейсы объявляют маленькими и там, где потребляют. Это прямо следует из «Базы»: раз реализация неявная, интерфейс не обязан жить рядом с типом. Функция объявляет ровно те методы, которые ей нужны, — и к ней подходит всё, что их имеет. Признак ошибки: интерфейс на восемь методов, объявленный рядом с единственной реализацией. Такой интерфейс ничего не абстрагирует, он повторяет структуру.

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

На границах следите за парой «тип и значение». Ловушка с типизированным nil живёт именно там, где интерфейс пересекает границу пакета: внутри функция работает с *MyErr, наружу отдаёт error. Правило простое — на границе объявляйте переменную интерфейсным типом, var err error, и возвращайте nil явно.

Отсюда же ответ на частый вопрос «зачем вообще интерфейс, если реализация одна». Затем же, зачем io.Writer: чтобы вызывающий мог подставить свою. Если подставлять некому и не планируется — интерфейс не нужен, и его отсутствие не недостаток дизайна.

Глубже: как это устроено внутри

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

Пара «тип и значение» лежит в памяти как два машинных слова. Это не обещание языка, а то, как сделано сейчас, — и это измеримо:

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

Уточнение про первое слово: у пустого интерфейса (any) там просто дескриптор типа, у интерфейса с методами — таблица методов (itab), в которой рядом с типом лежат адреса реализаций. Разница важна для цены вызова — о ней ниже.

Дальше — по одному следствию на слово: второе объясняет выделения памяти, первое — цену вызова.

Второе слово — указатель, поэтому упаковка выделяет память

Второе слово хранит не значение, а адрес значения. Отсюда простое правило: если упаковываемое не помещается в указатель, его надо куда-то положить — и это выделение в куче.

Замерено (bench/gointerface/internals.go):

Три строки объясняются одним предложением, четвёртая — отдельно.

Указатель кладётся как есть: копировать нечего, выделений ноль. Структуру приходится размещать в куче, потому что во второе слово помещается только адрес. А вот 42 против 1000 — это отдельный факт, который стоит знать: у рантайма есть готовый массив маленьких целых, и для чисел от 0 до 255 берётся адрес оттуда, а не выделяется новый.

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

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

Первое слово — таблица, поэтому вызов через неё дороже

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

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

Замерено на 4096 фигурах двух конкретных типов — в одном прогоне на одной машине, и кратность верна ровно для него:

И тут же — как этот замер положено делать. Первая редакция сравнивала вызов на переменной конкретного типа с вызовом на переменной интерфейсного и получила 0,87 — «через интерфейс быстрее». Это была не находка, а расписка в том, что замер негоден: у пакетной переменной интерфейсного типа компилятор знает единственный конкретный тип, девиртуализует вызов и встраивает его. Чтобы вызов остался вызовом, нужны два разных конкретных типа в срезе и данные из памяти, а не из литерала.

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

Что из этого следует для кода. Ничего вроде «не используйте интерфейсы». Четыре раза — это четыре раза от пустого метода в тесном цикле; как только внутри есть настоящая работа, доля вызова падает до незаметной. Правило такое: интерфейс на границе — норма, интерфейс внутри горячего цикла на миллион итераций — то, что стоит померить.

Как отвечать на собеседовании

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

Этого достаточно, чтобы ответить верно. Дальше — то, что добавляют, если собеседник копает.

Если интервьюер копает глубже

На «как устроен интерфейс» отвечайте «два слова». «Тип или таблица методов и указатель на значение; шестнадцать байт против восьми у указателя — так это сделано сейчас, спецификация обещает только пару». Дальше почти всё выводится отсюда, и собеседующий это слышит.

Ловушку с nil объясняйте правилом, а не примером. «Интерфейс равен nil, только когда пусты оба слова; здесь второе пусто, а первое заполнено типом». Пример потом — он занимает две строки и подтверждает, а не заменяет.

Про упаковку говорите «второе слово — указатель». «Указатель кладётся как есть, ноль выделений; структуру надо где-то разместить, одно. Маленькие целые — исключение, у рантайма готов массив от 0 до 255». Последнее предложение показывает, что вы это запускали.

Про цену вызова называйте число и причину. «У меня выходило вчетверо на пустом методе, и дорожает не поиск в таблице, а потеря встраивания». И сразу — как мерили: два конкретных типа в срезе, иначе компилятор девиртуализует.

Про x.(T) и type switch скажите «одно и то же». «Обе формы сравнивают указатель на тип; выбирают по числу веток, а не по скорости». Ответ «switch быстрее» без числа звучит хуже, чем «разница есть, но она в пятую часть на пустой операции».

Про набор методов назовите причину, а не правило. «У значения в интерфейсе нет адреса, поэтому метод с получателем-указателем в его набор не входит».

Дальше спросят

var _ Stringer = (*Point)(nil)

Частые заблуждения

Практика

Две задачи. Сначала ответьте, потом сверьтесь с настоящим выводом: в обеих правильный ответ взят из прогона скрипта, а не назначен.

type NotFound struct{ Key string }

func find(ok bool) error {
var missing *NotFound
if ok {
	return nil
}
return missing
}

err := find(false)
fmt.Println(err == nil)
var p *NotFound
fmt.Println(p == nil)
fmt.Println(reflect.TypeOf(err), err == nil)
fmt.Println(find(true) == nil)

false
true
*main.NotFound false
true

true
true
<nil> true
true

false
false
*main.NotFound false
false

true
true
*main.NotFound true
true

Проверка знаний