unsafe и представление памяти

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

Зачем тогда об этом целый урок? Затем, что запрос «unsafe go» приходит не из любопытства: «память golang» перестаёт быть магией ровно в момент, когда вы видели размеры своими глазами. Сорок мегабайт вместо двенадцати на срезе из миллиона структур — это паддинг, и он предсказуем. Заявление «len работает за O(1)» — это устройство заголовка строки, а не добродетель разработчиков. Код на encoding/binary, syscall, cgo и в драйверах баз — это unsafe.Pointer с дисциплиной из пяти правил спецификации. Даже рефлексия из прошлого урока внизу читает те же самые смещения полей: reflect.Offsetof и unsafe.Offsetof смотрят на одну и ту же раскладку. Понимать этот этаж нужно каждому, кто пишет на Go дольше месяца; трогать его руками — почти никому.

Договоримся о правилах урока. Мы измеряем и объясняем — Sizeof, Alignof, Offsetof, заголовки, смещения; паттерны с unsafe.Pointer разбираем обзорно, читая их как документацию, а не как рецепт. Это честно отражено в интерактиве: метрические функции раннеры исполняют (и вывод у них детерминированный, как у настоящего Go на 64-битной платформе), а вот конверсии указателей песочница не исполняет вовсе — что фолбэк-движок, что основной: у первого пакет запрещён целиком, у второго сломана именно переклейка типов, и мы зафиксируем точные тексты отказов. И ещё одна оговорка заранее: все числа урока — для 64-битной платформы, где машинное слово равно восьми байтам. На 32-битных архитектурах int, uintptr и указатель худеют до четырёх, и часть раскладок поедет — это не помеха пониманию, а лучшая иллюстрация того, что размеры не вшиты в язык.

unsafe.Sizeof(x) принимает операнд любого типа и возвращает размер его представления в байтах как uintptr — константу, которую компилятор знает уже на этапе сборки, до всякого запуска. Важная тонкость, на которой спотыкаются: Sizeof измеряет не «логическое содержимое», а значение-заголовок переменной этого типа. Для строки ответ всегда один и тот же — 16 байт на 64-битной платформе — независимо от того, пустая она или на гигабайт: Sizeof("abc") равен 16, а Sizeof("") тоже 16, потому что измеряется заголовок (указатель на байты плюс длина), а не содержимое. Байты содержимого считает len: len("abc") — 3. Это различие «вес ручки против веса чемодана» — главный навык урока.

Базовая шкала для 64-бит. Числа фиксированной разрядности честны: int8 — 1, int16 — 2, int32 — 4, int64 и uint64 — 8, float32 — 4, float64 — 8, complex128 — 16. bool и byte — по одному байту. А вот int, uint и uintptr — это машинное слово: 8 байт на 64-битных платформах и 4 на 32-битных. Отсюда практическое правило, которое стоит запомнить быстрее всех прочих: когда вам важен размер в сериализации или в протоколе — берите типы с явной разрядностью (int64, uint32), а int оставляйте для счётчиков и индексов, где платформозависимость безразлична. Указатель — слово: *int — 8 байт, каким бы тяжёлым ни было то, на что он смотрит.

Составные типы складываются из заголовков. Срез — три слова: указатель на массив, длина, ёмкость — итого 24 байта, опять же без учёта самих элементов. Карта и канал — по одному слову (8): внутри — указатели на рантайм-структуры, наружу торчит только ручка. Функция — слово. Интерфейс — два слова (16): типовой компонент и содержимое, та самая пара «какой тип — какое значение», из которой reflect.TypeOf доставал паспорт в прошлом уроке. Структура — не сумма полей, а сумма полей ПЛЮС выравнивание, и это следующий блок; но даже до него вы уже можете предсказывать размеры: []int из десяти элементов весит 24 байта заголовка плюс 80 байт массива — и ни байтом больше или меньше.

Отдельно — про именованные типы. type Celsius float64 не создаёт новое представление: Sizeof(Celsius(0)) равен 8, как у float64. Определение типа заводит новую личность в системе типов (мы это видели через reflect в прошлом уроке), но байты под значениями остаются родительскими. Поэтому «сколько весит» всегда спрашивается у базового представления — и поэтому же перевод между ними не требует перекопирования памяти.

Процессор не читает память по одному байту: он забирает машинные слова, и обращение к int64 по адресу, не кратному восьми, на многих архитектурах либо медленнее, либо вовсе невозможно. Поэтому компилятор Go раскладывает поля структур по адресам, кратным их собственному выравниванию, а дырки заполняет нулями. Эти дырки называются padding (паддинг, выравнивающее заполнение) — и они же причина главного сюрприза урока: размер структуры не равен сумме размеров полей.

Правило раскладки простое, и его стоит сформулировать один раз. Каждое поле ложится на ближайшее свободное смещение от начала структуры, кратное его выравниванию (Alignof): int64 требует кратности 8, int32 — 4, int16 — 2, байты и bool кладутся на любой адрес. Если до кратности не хватает места — вставляется pad. В конце структуры компилятор добивает размер так, чтобы СЛЕДУЮЩАЯ структура в массиве тоже начиналась с выравненного адреса: размер всей структуры кратен максимальному выравниванию её полей. Отсюда классический пример: struct { A byte; B int64 } занимает 16 байт — один байт поля, семь байт pad, восемь байт int64. Переставим поля: struct { B int64; A byte } — тоже 16, потому что теперь семь байт pad висят хвостом, ради следующего элемента массива. Порядок полей меняет, где дырка, но не факт, что убирает её.

Откуда дырки убираются совсем: когда поля идут по убыванию разрядности. struct { int64; int32; byte } — 8 + 4 + 1 + 3 хвоста = 16, а struct { int64; int32; int32 } — ровно 16 без единого паддинга: 8 + 4 + 4. А вот пара байт и int32 struct { X, Y byte; I int32 } весит 8: 1 + 1 + 2 pad + 4 — выравнивание int32 отработало. Смысл для практики — экономия на массивах: структура из байта и int64 в срезе на миллион элементов — это 16 мегабайт, из которых шесть — чистые дырки; перестановка полей сжимает то же самое до восьми. encoding/json вас не спросит о порядке полей, а память — спросит: это единственное место в языке, где порядок объявлений имеет наблюдаемый эффект на размер.

Учитесь читать раскладку глазами, прежде чем мерить: увидев структуру, пройдите по полям сверху вниз и нарисуйте смещения — byte на 0, pad до 8, int64 на 8, int32 на 16, хвост до кратности 8. Этот навык — ручная репетиция того, что делает Alignof и Offsetof, к которым мы перейдём после раннера; а пока проверьте себя на структурах попроще.

Теперь можно назвать вещи, которые Sizeof только что показал пальцем. Строка — это заголовок из двух машинных слов: указатель на байты содержимого и длина в байтах. Весь тип string — 16 байт ручки; сами байты лежат где-то в памяти, чаще всего в read-only сегменте, если строка литеральная, или в куче, если собрана в рантайме. Отсюда всё поведение строк, которое вы уже набили до автоматизма: len(s) — чтение второго поля заголовка, поэтому O(1); s[0:2] — новый заголовок с тем же указателем и другой длиной, поэтому срез строки не копирует содержимое; конкатенация копирует байты, потому что собирает новый буфер. Два заголовка могут указывать на один и тот же байтовый массив — «копия строки» стоит 16 байт и ноль копирования, пока вы не пишете в неё — а писать в строку нельзя вовсе: содержимое иммутабельно, и это защита не абстракции, а памяти.

Срез — заголовок из трёх слов: указатель на первый элемент массива, длина len и ёмкость cap. Двадцать четыре байта ручки — и вся механика срезов выводится из этого представления, как из аксиомы. len и cap — чтения полей заголовка: O(1). Срез s[1:3] — новый заголовок с указателем, сдвинутым на размер элемента, len 2 и cap, уменьшенной на единицу: содержимое не копируется, что объясняет, почему подсрезы «делят» массив и правки через один видны через другой. append при наличии ёмкости пишет в тот же массив за заголовком; когда ёмкость кончилась — аллокация нового массива больше и копирование, поэтому старая присказка «append может оторваться от оригинала» — это буквально история про то, что заголовки перестали указывать на один массив. В уроках про срезы и строки вы проходили это на поведении; здесь видно, почему поведение именно такое.

Третьим лицом этого семейства стоит map и канал: по одному слову наружу, рантайм-структуры внутри — поэтому nil-карта читается, но не пишется (заголовок пуст, писать некуда), и поэтому же их нельзя сравнивать на равенство кроме как с nil: два заголовка указывают на внутренности, про которые язык не знает структуры сравнения. Но главные герои урока — строка и срез, потому что именно их заголовки являются целью законных unsafe-паттернов: zero-copy разбор строки в []byte и обратно возможен ровно потому, что у обоих под ручкой байтовый массив, и отличается только форма ручки.

Заголовки стоит удерживать в голове при каждой оценке «сколько это стоит в памяти». Срез из тысячи строк — это 24 тысячи байт заголовков плюс сумма длин строк: заголовки и содержимое живут в разных местах и считаются по-разному. Копирование среза в функцию копирует 24 байта, не элементы: тот факт, что срез «дорогой на вид», но дешёвый в передаче, — прямое следствие представления. А string-ключи в картах сравниваются за O(len) по байтам, хотя сам ключ — ручка: заголовок делает дешёвым хранение, но не сравнение.

unsafe.Pointer — тип-посредник, «универсальная ручка»: любой указатель T можно превратить в unsafe.Pointer и обратно в U другого типа. В этом весь механизм; вся сложность — в дисциплине его применения. Спецификация Go (раздел Package unsafe в go.dev/ref/spec) фиксирует, какие преобразования с unsafe.Pointer законны, — их ровно пять, и мы пройдём их обзорно, как экскурсию по забору с табличкой «не влезай — убьёт».

*Паттерн 1: T1 → unsafe.Pointer → T2*, когда типы занимают одинаковую память. Это reinterpret cast: те же байты читаются другой интерпретацией. Классика — посмотреть на float64 как на uint64 и увидеть его биты: преобразование легально, потому что оба типа восьмибайтные; читать через тип меньшего размера уже нельзя. На этом паттерне стоит бинарный разбор форматов, энкодеры и заголовки из листинга выше.

Паттерн 2: unsafe.Pointer → uintptr → unsafe.Pointer — круглый рейс, разрешённый ТОЛЬКО как одно выражение: uintptr(p) вычисляет адрес как число, и если между получением и обратным превращением GC не может сдвинуть или освободить объект — вы вернётесь по тому же адресу. Целевое применение — арифметика адресов в следующем паттерне. Держать uintptr в переменной, в поле структуры, передавать его между функциями — запрещено: uintptr не считается указателем, сборщик мусора про него не знает.

Паттерн 3: uintptr(p) + смещение → unsafe.Pointer — адресная арифметика для полей структуры: адрес поля равен адресу структуры плюс Offsetof. Формула unsafe.Pointer(uintptr(p) + unsafe.Offsetof(s.Field)) законна, потому что вся она — одно выражение. Так syscall-функции и cgo собирают указатели на вложенные поля чужих структур. Тот же механизм — единственный способ посчитать адрес элемента массива по индексу, не зная типа.

Паттерны 4 и 5 — про uintptr, который уже хранится где-то в памяти: конвертировать обратно в Pointer можно только uintptr, пришедший из reflect.Value.Pointer() или reflect.Value.UnsafeAddr(), и uintptr, выданный Syscall-вызовом — и только немедленно, в том же выражении. Оба случая — мосты к API, которые адреса принимают как числа, и оба существуют ради совместимости, а не для повседневной работы. Пять правил сжимаются в одну фразу: Pointer честен, пока uintptr живёт внутри одного выражения; всё, что пережило выражение, — мусорный адрес, по которому рантайм ничего не обещает.

Нарушение этих правил не похоже на обычную ошибку Go: программа собирается, работает, проходит тесты — и падает раз в неделю, когда GC перенёс объект, а вы держали старый uintptr. Это самый коварный жанр багов в экосистеме, поэтому ревьюеры в Go-проектах реагируют на unsafe.Pointer как на кнопку с красной пломбой: допустимо, но объясни в комментарии, какой из пяти паттернов и почему он здесь законен. Go-флаг -race и проверка go vet частично ловят злоупотребления — но не все, и ставка на «протестируется» здесь не работает.

Есть жанр кода, который без unsafe.Pointer не существует, — и он окружает вас в каждом продакшн-проекте, оставаясь невидимым. Драйверы баз (pq, mysql-драйверы, pgx) разбирают сетевые пакеты: байты, пришедшие по сокету, нужно прочитать как числа и строки, не копируя их по сто раз, — там живут reinterpret-паттерны и адресная арифметика по смещениям. encoding/binary сериализует целые в байты и обратно; под капотом стандартной библиотеки unsafe встречается ровно там, где измерения и разбор должны быть быстрыми. syscall и cgo — полностью построены на пятом паттерне: операционная система принимает адреса как числа, и языковой мост обязан конвертировать их по правилам, которые мы перечислили. Рефлексия из прошлого урока внизу читает те же смещения: reflect.Type.Offsetof и unsafe.Offsetof считают одно и то же — просто рефлексия даёт ручку через валидацию, а unsafe — без.

Второй жанр — zero-copy: работа с байтами без копирования. Канонический пример — перевод string в []byte без аллокации: обычное преобразование []byte(s) копирует содержимое, а через unsafe.Pointer можно собрать заголовок среза, указывающий на байты строки, — и разбор мегабайтного ответа API не удвоит память. Обратная сторона там же: нельзя писать в байты строки (иммутабельность — часть контракта рантайма, её нарушит только паттерн, который и нарушать не надо), и нельзя держать такой срез дольше жизни строки. Тот же жанр — парсеры протоколов: взять буфер целиком и читать числа по смещениям, как мы читали поля структуры через Offsetof. Если ваш профиль показывает, что время уходит на копирования, — это место, где память golang начинают считать не в интуициях, а в байтах, и zero-copy — легальный ответ.

Третий жанр — оптимизация памяти структур, то есть паддинг из середины урока, применённый осознанно. В горячих сервисах структуры по миллиону элементов — это мегабайты, и перестановка полей по убыванию разрядности — самая дешёвая оптимизация из существующих: ноль строк логики, минус десятки процентов RSS. Заметьте иерархию: сначала считается профиль и GC-давление (урок про бенчмарки даёт инструменты), потом проектируется раскладка структур, и только потом — если куда-то не хватило всех обычных средств — открывается unsafe. Большинству разработчиков хватает первых двух шагов всю карьеру.

И во всех трёх жанрах общая черта: unsafe сидит на ГРАНИЦЕ системы — там, где код встречается с сетью, с ОС, с форматом файла, с чужой библиотекой. Внутри ядра приложения ходят обычные типы. Это тот же принцип границы, что у рефлексии в прошлом уроке: дорогой и опасный механизм допустим на низкой частоте и подконтрольной периферии, и запрещён в горячем цикле по своим же данным. Когда вы читаете чужой код и видите import "unsafe", вопрос всегда один: какая граница за этим импортом — сетевой протокол, системный вызов, формат? Если ответа нет — небрежность, и её место в ревью с пометкой.

Начнём с самого частого случая — unsafe ради скорости на ровном месте. Интуиция «через указатели быстрее» в Go обычно ложь: компилятор уже размещает поля, уже знает смещения, уже разворачивает методы, и прямая запись m.Hits = 99 компилируется в одну инструкцию по известному адресу. Переход на unsafe.Pointer с арифметикой добавляет проверки, ломает встраивание и инлайн-оптимизации, а выигрыш есть только в узких местах, которые вы ВИДЕЛИ в профиле. Правило из урока про бенчмарки переносится дословно: нет бенчмарка — нет и права на unsafe.

unsafe ради «типизировать чужие байты» — второй кандидат на отказ. Если данные пришли по сети, язык даёт encoding/binary с ByteOrder, да срезы с бинарными протоколами; reinterpret через Pointer без пяти правил превращает программу в лотерею с GC. Вариант «мне просто посмотреть содержимое» решается %v, fmt.Printf с %#x, hex-дампами и отладчиком — все они безопасны и дают больше, чем сырой указатель. Чтение байт как байт — это не unsafe, это обычная работа с []byte, и она не требует переклейки типов вовсе.

unsafe ради структур данных с хранением адресов — классическая ловушка новичков: поле uintptr в структуре как «быстрый указатель». uintptr не ссылка для GC: объект, на который он указывает, может быть собран или перемещён, и поле однажды укажет в чужую память. Хотите адрес в структуре — храните честный указатель или индекс. Это правило стоит повторить: ССЫЛКИ В ДАННЫХ — ТОЛЬКО УКАЗАТЕЛИ; uintptr — тип для одного выражения, не для хранения.

Unsafe ради массивов переменной длины — тоже мимо: в современном Go есть unsafe.Slice, но чаще всего задача «буфер с длиной» — это обычный make([]T, n), а «стек без аллокаций» — фиксированный массив с индексом. Наконец, отдельно: не трогайте неэкспортируемые поля чужих структур через Pointer — это не «хак», а прямой путь к несовместимости: внутреннее представление типов стандартной библиотеки меняется между версиями Go без предупреждения, и код, читавший чужие байты, тихо ломается при обновлении тулчейна. Единственная легальная дверь к чужим внутренностям — API, которое авторы для этого оставили: reflect с его проверками или документированные конвертеры. Если двери нет — значит, за ней не для вас построено.

Соберём урок в одну карту. unsafe.Sizeof измеряет представление: скаляры — по разрядности, int и uintptr — по машинному слову, string — 16 (указатель плюс длина), срез — 24 (указатель, len, cap), интерфейс — 16, указатель — 8. Выравнивание раскладывает поля структур по кратным адресам, padding — цена этой раскладки, и порядок полей — единственный рычаг, которым вы её регулируете: по убыванию разрядности — минимальные дырки. Alignof и Offsetof делают раскладку наблюдаемой: смещения 0, 8, 16 из раннера — это то, что компилятор делает с каждой структурой молча. unsafe.Pointer — посредник с пятью паттернами из спецификации: reinterpret равных типов, круглый рейс через uintptr одним выражением, адресная арифметика по Offsetof и два мостовых случая для reflect и syscall. Всё это — язык границы: драйверы, binary-протоколы, zero-copy, cgo; внутри приложения обычным типам есть что сказать и без него, и когда НЕ трогать — главный вывод урока: нет профиля, нет бенчмарка, нет границы — нет и unsafe.

Двадцатый урок — файлы и io: мы выйдем из памяти наружу, к диску и потокам — os.Open, чтение файлов, Writer и Reader, и увидим, что байтовое мышление из этого урока там работает напрямую: заголовки срезов — это буферы, строки из байтов — это содержимое файлов, и размер имеет значение, когда файл на гигабайт. Рефлексия отвечала «какой это тип», unsafe — «сколько он весит и как лежит», файлы покажут, «откуда он приходит».

До встречи на странице курса. Если захочется перечитать смежное — урок про рефлексию: reflect.Type.Offsetof и unsafe.Offsetof смотрят на одну раскладку с разных этажей; а если захочется измерить, что паддинг действительно стоит памяти, — каркас бенчмарков ждёт в уроке про бенчмарки: BenchmarkBad против BenchmarkGood на срезах из миллиона структур — упражнение на десять минут, которое раз и навсегда превращает раскладку из теории в цифры.