Отражение в Go: как устроено внутри и сколько стоит

Сериализация структуры через encoding/json на горячем пути неожиданно даёт аллокации там, где их не ждёшь: профиль показывает reflect.packEface, reflect.Value.Interface и рост GC-пауз под нагрузкой. Причина одна — рефлексия. Разберём, что стоит за reflect.ValueOf и reflect.TypeOf на уровне рантайма Go 1.22, откуда берётся цена и когда её можно убрать. Замеры делайте сами через go test -bench: конкретные наносекунды зависят от железа и данных, поэтому важнее понимать механизм, а не заучивать цифру.

Что такое интерфейс в памяти

Чтобы понять рефлексию, надо сначала понять устройство пустого интерфейса. Любое значение, попавшее в interface{} (он же any), в рантайме представлено парой указателей: на дескриптор типа и на сами данные. Эта структура называется eface — empty interface.

// схематично, из runtime (не публичный API)
type eface struct {
    _type *_type          // дескриптор типа
    data  unsafe.Pointer  // указатель на значение
}

Для интерфейсов с методами используется iface с таблицей методов itab вместо голого _type. Рефлексия работает поверх этой пары: reflect.TypeOf достаёт первое поле, reflect.ValueOf — оба.

Почему передача в any может аллоцировать

Поле data в eface — указатель. Когда вы кладёте в any значение, которое не помещается в один указатель и не является указателем само по себе (например, int на некоторых платформах, структуру, большой массив), рантайм обязан разместить его так, чтобы data на него ссылался. Часто это значит аллокацию в куче. Отсюда первый источник цены рефлексии: она почти всегда начинается с оборачивания значения в интерфейс.

Рефлексия не «медленная сама по себе». Дорого не чтение дескриптора типа, а то, что вокруг него: упаковка в интерфейс, escape в кучу и невозможность инлайнинга.

Что делает reflect.ValueOf

Сигнатура func ValueOf(i any) Value уже показывает главное: аргумент принимается через any. Значит, ещё до входа в функцию компилятор вставил упаковку вашего значения в интерфейс. Внутри reflect.Value хранит примерно те же три вещи, что и eface, плюс битовый набор флагов:

• указатель на дескриптор типа (*rtype);
• указатель на данные;
• флаги: экспортируемость, адресуемость, kind, признак того, лежит ли значение по указателю или инлайн.

Компилятор Go не может доказать, что значение, ушедшее в ValueOf, не переживёт вызов, поэтому оно почти всегда escape-ится в кучу. Это видно в анализе побега:

// Go 1.22
// go build -gcflags='-m' main.go
func dump(user User) {
    v := reflect.ValueOf(user) // user escapes to heap
    _ = v.NumField()
}

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

Три уровня цены

Разложим стоимость рефлексии на составляющие, от самого дешёвого к самому дорогому.

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

Поиск поля по имени

Обращение v.FieldByName("Email") кажется удобным, но за ним стоит просмотр полей типа. Рантайм кеширует часть метаданных типа, но сам факт поиска по строке дороже индексного доступа v.Field(2). Если вы обходите одну и ту же структуру миллионы раз, разумно один раз вычислить индексы полей и дальше ходить по ним.

Как измерять, а не гадать

Не доверяйте интуиции о том, что «тут рефлексия и потому медленно». Померьте. Микробенчмарк на testing.B с флагом аллокаций даст и время, и число аллокаций на операцию:

// Go 1.22
// go test -bench=. -benchmem
package bench

import (
    "reflect"
    "testing"
)

type User struct {
    ID    int
    Name  string
    Email string
}

// прямой доступ — базовая линия
func BenchmarkDirect(b *testing.B) {
    u := User{ID: 1, Name: "Ann", Email: "a@x.ru"}
    var sink int
    for i := 0; i < b.N; i++ {
        sink += u.ID
    }
    _ = sink
}

// доступ через рефлексию по индексу поля
func BenchmarkReflect(b *testing.B) {
    u := User{ID: 1, Name: "Ann", Email: "a@x.ru"}
    var sink int64
    for i := 0; i < b.N; i++ {
        v := reflect.ValueOf(u)
        sink += v.Field(0).Int()
    }
    _ = sink
}

Смотрите на колонку allocs/op в выводе -benchmem. Если у прямого доступа там ноль, а у рефлексии — единица или больше, вы нашли источник давления на GC. Абсолютные наносекунды сравнивайте только между запусками на одной машине: они бессмысленны в отрыве от железа и версии Go.

Как уменьшить цену, не отказываясь от рефлексии

Полный отказ от рефлексии часто невозможен: на ней держатся сериализация, ORM, валидаторы. Но давление на рантайм можно снизить.

1. Кешируйте reflect.Type. Дескриптор типа неизменен. Считайте его один раз для типа, а не на каждый вызов. Часто это делают через sync.Map с ключом-типом.
2. Ходите по индексам, а не по именам. Один раз вычислите номера нужных полей через TypeOf, дальше используйте Field(i).
3. Избегайте Interface() в цикле. Если нужно только прочитать число или строку — берите v.Int(), v.String() напрямую, без обратной упаковки в any.
4. Кодогенерация вместо рантайма. Для горячих путей стоит сгенерировать код доступа заранее через go generate. Так работают быстрые JSON-библиотеки: рефлексия используется один раз при построении плана, дальше исполняется сгенерированный или закешированный код.

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

Где подход ломается

Границы, о которые спотыкаются чаще всего:

• Неэкспортируемые поля. v.Field(i).Interface() на поле с маленькой буквы вызовет панику. Читать их без unsafe нельзя — это защита рантайма, а не баг.
• Адресуемость. reflect.ValueOf(x) даёт неадресуемое значение: Set паникует. Чтобы менять поля, нужен указатель и reflect.ValueOf(&x).Elem().
• Кеш типа и дженерики. Инстанцированные обобщённые типы дают разные reflect.Type. Ключ кеша по типу это учитывает, но размер кеша может расти неожиданно.
• Паники вместо ошибок. Рефлексия сообщает о несоответствии типов паникой в рантайме, а не ошибкой компиляции. Всё, что компилятор мог поймать статически, вы теряете.

Что делать дальше

Прогоните go test -bench=. -benchmem на своём горячем пути и найдите вызовы с ненулевым allocs/op. Если давление на GC заметно в pprof по alloc_space — вынесите разбор типа в кеш или в кодогенерацию. Читать первоисточник стоит в пакете reflect и в файле runtime/iface.go исходников Go: устройство eface/iface объясняет большинство неожиданностей. Инвалидация кеша типов и работа с unsafe.Pointer для обхода экспортируемости — отдельные темы, здесь мы их не разворачивали.