Выравнивание данных в структурах Go: почему 15 байт весят 32

Сложите размеры полей структуры, вызовите unsafe.Sizeof — и получите число почти вдвое больше. Это не баг и не магия, а выравнивание данных. Разберём, откуда берутся «лишние» байты, почему компилятор Go их добавляет, как их посчитать руками и когда их стоит убрать. По ходу есть конструктор структур, где вы соберёте свою раскладку и увидите каждый байт.

Статья написана под Go 1.27 (релиз — август 2026). Числа даны для 64-битных платформ (amd64, arm64), для 32-битных есть отдельные столбцы и переключатель в конструкторе. Все размеры относятся к компилятору gc.

Структура на 15 байт весит 32

type Event struct {
    Seen   bool    // 1 байт
    UserID int64   // 8 байт
    Kind   bool    // 1 байт
    Score  float32 // 4 байта
    Fresh  bool    // 1 байт
}

fmt.Println(unsafe.Sizeof(Event{})) // 32

Чтобы понять, как так получилось, нужно разобраться с тем, как процессор читает память.

Зачем нужно выравнивание

Выравнивание (alignment) — требование, чтобы значение лежало по адресу, кратному некоторому числу. Значение типа int64 должно начинаться с адреса, кратного 8; int32 — кратного 4; byte — любого. Если очередное поле «не попадает» в такой адрес, компилятор вставляет перед ним пустые байты — padding (набивку).

Процессор и кэш-линия

Причин у этого требования несколько, и все они про железо:

• Процессор читает память словами. Шина и регистры рассчитаны на порции по 1, 2, 4, 8 байт. Выровненное значение читается одной операцией, а невыровненное может потребовать двух чтений и склейки результата.
• Кэш-линия. Память между кэшем и ОЗУ ходит блоками по 64 байта (на типичных x86-64 и ARM-серверах). Выровненное 8-байтное значение никогда не пересечёт границу линии. Невыровненное — может, и тогда для него нужны две линии.
• Атомарность. Атомарные инструкции работают только с выровненными значениями. Невыровненный доступ либо не атомарен, либо вообще вызывает аппаратную ошибку на части архитектур.
• Простота железа. Требование «адрес кратен размеру» упрощает схемы выборки; поэтому на ряде архитектур невыровненный доступ был запрещён или заметно медленнее.

Правила в Go

Спецификация Go гарантирует немного. Размеры числовых типов фиксированы, а для выравнивания даны три минимальных свойства:

1. Для переменной любого типа unsafe.Alignof(x) — не меньше 1.
2. Для переменной структурного типа Alignof(x) — наибольшее из значений Alignof(x.f) по всем полям, но не меньше 1.
3. Для массива Alignof(x) равно выравниванию его элемента.

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

Алгоритм раскладки

Компилятор раскладывает поля строго в том порядке, в котором вы их объявили (Go никогда не переставляет поля сам). Для каждого поля:

1. offset = roundUp(конец_предыдущего_поля, align_поля) — смещение округляется вверх до кратного выравниванию;
2. разница между смещением и концом предыдущего поля — это padding перед полем;
3. после последнего поля: size = roundUp(конец_последнего, align_структуры). Хвостовой padding нужен, чтобы в массиве [N]T каждый следующий элемент тоже начинался с выровненного адреса.

Пройдём этим алгоритмом по структуре Кати (64-бит):

Итого 17 байт padding на 15 байт данных. Теперь та же структура с полями по убыванию выравнивания:

type Event struct {
    UserID int64   // offset 0,  8 байт
    Score  float32 // offset 8,  4 байта
    Seen   bool    // offset 12
    Kind   bool    // offset 13
    Fresh  bool    // offset 14
    // хвост: 15 → 16 (align структуры 8)
}

Из чего следует правило: чтобы минимизировать padding, расставляйте поля по убыванию выравнивания. Размер каждого типа кратен его выравниванию, поэтому после крупных полей мелкие естественно укладываются плотно, а дыры остаются только в хвосте.

Размеры и выравнивание типов

Спецификация гарантирует размеры только числовых типов. Всё остальное зависит от реализации и разрядности платформы, ниже — как это устроено в gc.

Конструктор структур

Соберите свою структуру из типов-«кирпичиков» или возьмите пример. Двигайте поля кнопками ↑ и ↓ и смотрите, как меняется карта памяти. Красная штриховка — padding между полями, жёлтая — хвостовой padding. Ниже появятся расчёт, размер, класс аллокатора и цена на заданном количестве объектов.

Что стоит попробовать

1. Выберите «Пример из истории» и нажмите «Отсортировать по убыванию align»: 32 → 16 байт.
2. Переключите платформу на 32-бит. Размер изменился — int64 теперь выровнен по 4, а string занимает 8 байт.
3. Добавьте struct{} последним полем: размер вырастет на выравнивание. Это особенность gc (см. ниже).
4. Выберите «Профиль пользователя» и посмотрите на строку «GC просматривает» до и после пункта «Указатели вперёд».
5. Сравните «в срезе» и «по одному в куче»: во втором случае работают классы размера аллокатора.

Как оптимизировать

Алгоритм прост и не требует ничего, кроме перестановки строк:

1. Сортируйте поля по убыванию выравнивания: сначала 8-байтные (int64, указатели, string, срезы, интерфейсы), потом 4-байтные, потом 2-байтные, потом одиночные байты и bool.
2. Внутри одной группы можно выбирать порядок по смыслу.
3. Если есть указатели, ставьте их в начало (см. ниже про GC).

// до: 40 байт
type Profile struct {
    Active  bool      // 0, затем 7 байт padding
    ID      int64     // 8
    Age     int8      // 16, затем 7 байт padding
    Name    string    // 24
}

// после: 32 байта
type Profile struct {
    ID     int64      // 0
    Name   string     // 8
    Age    int8       // 24
    Active bool       // 25, хвост до 32
}

Указатели и сборщик мусора

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

// GC просматривает всю структуру: указатель в самом конце
type A struct {
    Buf  [1024]byte
    Next *A
}

// GC просматривает только первые 8 байт
type B struct {
    Next *A
    Buf  [1024]byte
}

Анализатор fieldalignment умеет сообщать об обоих выигрышах: что структуру можно сделать меньше и что можно сократить количество «байтов указателей», которые просматривает GC.

Где это важно

Классы размеров аллокатора

Когда вы создаёте объект в куче (new(T), &T{}), аллокатор округляет запрошенный размер вверх до одного из классов размеров: 8, 16, 24, 32, 48, 64, 80, 96, 112, 128, 144, 160, … байт (полный список в runtime/sizeclasses.go, он может меняться между версиями). Поэтому объект на 33 байта реально занимает 48, а на 49 — 64.

Отдельный случай — tiny allocator: объекты размером меньше 16 байт без указателей могут упаковываться в общие 16-байтные блоки. Это ещё одна причина, по которой маленькие структуры из скаляров обходятся дёшево.

False sharing: когда padding нужен

Ядра процессора хранят данные в кэш-линиях по 64 байта. Если два ядра пишут в разные переменные, лежащие в одной линии, процессоры вынуждены постоянно пересылать линию друг другу — это называется false sharing (ложное разделение). Логически переменные независимы, но аппаратно они связаны.

import "golang.org/x/sys/cpu"

// счётчики разных горутин не делят кэш-линию
type Counters struct {
    a atomic.Int64
    _ cpu.CacheLinePad
    b atomic.Int64
    _ cpu.CacheLinePad
}

sync/atomic и 32 бита

Атомарные операции над 64-битными значениями требуют выравнивания по 8 байт. На 64-битных платформах это выполняется автоматически, а вот на 386, arm и 32-битном mips int64 выровнен только по 4. В документации sync/atomic сказано, что на этих платформах за выравнивание таких слов отвечает вызывающий код. Типы atomic.Int64 и atomic.Uint64 решают проблему: компилятор выравнивает их по 8 байт сам.

type Stats struct {
    ready bool
    hits  atomic.Int64 // безопасно на всех платформах
}

// старый стиль: int64 должен быть первым полем структуры,
// выделенной через new или обычную переменную
type Legacy struct {
    hits  int64
    ready bool
}

Пустое поле в конце структуры

Структура из нулевых полей имеет размер 0, а пустые поля в середине размера не добавляют. Но если пустое поле стоит последним, компилятор gc добавляет после него байт (с последующим округлением), чтобы указатель на это поле не указывал за пределы объекта и не удерживал соседний объект от сборки.

type A struct {
    n int64
    _ struct{} // в конце: размер 16, а не 8
}

type B struct {
    _ struct{} // в начале: размер 8
    n int64
}

fmt.Println(unsafe.Sizeof(A{}), unsafe.Sizeof(B{})) // 16 8

Это ещё одна причина ставить нулевые поля (_ struct{}, маркеры noCopy) в начало структуры.

А что в Go 1.27

Прямо отвечу на вопрос, который напрашивается: правила выравнивания и раскладки структур в Go 1.27 не изменились. Спецификация по-прежнему гарантирует таблицу размеров числовых типов и три свойства выравнивания, а в релиз-нотах нет ничего о смене размеров стандартных типов. Код, который проверяет unsafe.Sizeof, ведёт себя как в предыдущих версиях.

Зато есть изменение рядом, которое делает размер структуры ещё более ощутимым. Из релиз-нот Go 1.27 (пересказ с английского):

Компилятор теперь генерирует вызовы специализированных по размеру процедур выделения памяти, что снижает стоимость некоторых малых (<80 байт) аллокаций на величину до 30%. Улучшения зависят от нагрузки, но в реальных программах с интенсивным выделением памяти ожидается около 1%. Размер бинарного файла вырастает примерно на 60 КБ.

• Что это значит для структур. Объекты меньше 80 байт попадают в «быстрый» путь. Если вы сжали структуру с 88 до 72 байт, она оказывается в числе малых аллокаций из релиз-нот. Выигрыш складывается с экономией памяти.
• Чего не стоит ждать. Это ускоряет выделение, а не доступ к полям; средний выигрыш на реальных программах авторы оценивают в районе 1%.
• Выключатель. Поведение отключается переменной GOEXPERIMENT=nosizespecializedmalloc при сборке. По релиз-нотам, этот выключатель планируется убрать в Go 1.28.
• Рядом. У go fix появились новые «модернизаторы», в том числе unsafefuncs. Подробности про него в релиз-нотах не раскрываются, поэтому за описанием смотрите справку go fix.

Как проверить на своём коде

import (
    "fmt"
    "reflect"
    "unsafe"
)

type Event struct {
    Seen   bool
    UserID int64
    Kind   bool
    Score  float32
    Fresh  bool
}

func main() {
    var e Event
    // unsafe.Sizeof, Alignof, Offsetof — константы времени компиляции
    fmt.Println("size:", unsafe.Sizeof(e), "align:", unsafe.Alignof(e))
    fmt.Println("UserID offset:", unsafe.Offsetof(e.UserID))

    // то же самое через reflect — для любого типа в рантайме
    t := reflect.TypeOf(e)
    for i := 0; i < t.NumField(); i++ {
        f := t.Field(i)
        fmt.Printf("%-7s off=%2d size=%d align=%d\n",
            f.Name, f.Offset, f.Type.Size(), f.Type.Align())
    }
}

# анализатор fieldalignment (в go vet по умолчанию не входит)
go install golang.org/x/tools/go/analysis/passes/fieldalignment/cmd/fieldalignment@latest

fieldalignment ./...
# event.go:3:12: struct of size 32 could be 16

# автоматически переставить поля
fieldalignment -fix ./...

Ловушки и мифы

• «Компилятор сам переставит поля». Нет. Go раскладывает поля в порядке объявления и никогда их не переставляет (в отличие, например, от Rust). Порядок — ваша ответственность.
• «Надо оптимизировать каждую структуру». Нет. Для структур, которых в программе единицы или сотни, это бессмысленно. Считайте выгоду: экономия на объект × количество.
• «Читаемость не страдает». Страдает. Логически связанные поля (Lat и Lng) могут оказаться далеко друг от друга. Группируйте по смыслу внутри групп одинакового выравнивания и комментируйте причину.
• Порядок полей — часть API. Для публичных типов перестановка меняет позиционные литералы (T{1, 2}), поведение reflect-кода и порядок вывода некоторых форматов. Проверьте, не ломаете ли вы пользователей.
• Платформы. Размер, посчитанный на amd64, не равен размеру на 386. Если нужны точные цифры для обеих — тесты с unsafe.Sizeof под каждую платформу.
• Сжатие структур против false sharing. Для горячих параллельных счётчиков нужен обратный приём — преднамеренный padding.
• Приведение через unsafe. Читать байты как структуру (и наоборот) через unsafe.Pointer опасно: раскладка зависит от платформы, а padding содержит произвольные значения.
• Не измерено — не оптимизировано. Подтверждайте эффект измерением памяти (runtime.MemStats, pprof) и бенчмарками на реальных данных.

Сводная таблица приёмов и их побочных эффектов

Плюсы и минусы выравнивания как такового

Проверь себя

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

Шпаргалка

• offset = roundUp(конец_предыдущего, align_поля), size = roundUp(конец_последнего, align_структуры).
• Выравнивание структуры — максимум из выравниваний её полей.
• Расставляйте поля по убыванию выравнивания; указатели — вперёд.
• string — 16 байт, срез — 24, интерфейс — 16, указатель — 8 (на 64-бит).
• Go не переставляет поля сам. struct{} в конце добавляет padding.
• В Go 1.27 раскладка не менялась; малые (<80 байт) аллокации стали дешевле.
• Для параллельных счётчиков — наоборот, разносите по кэш-линиям.

Полезные материалы

Ссылки ведут на первоисточники: спецификацию языка, документацию пакетов и релиз-ноты Go 1.27.

• Спецификация Go: Size and alignment guarantees — гарантированные размеры и три правила выравнивания
• Спецификация Go: Package unsafe — Sizeof, Alignof, Offsetof как константы
• Пакет unsafe — документация функций и правила использования
• reflect.Type — Size, Align, FieldAlign, StructField.Offset
• Go 1.27 Release Notes — аллокация малых объектов, GOEXPERIMENT=nosizespecializedmalloc
• Go 1 compatibility promise — на что можно рассчитывать при смене версий
• fieldalignment — анализатор, который находит структуры, которые можно сделать меньше
• sync/atomic: заметка о выравнивании — 64-битные слова на 32-битных платформах
• cpu.CacheLinePad — padding под размер кэш-линии платформы
• runtime/sizeclasses.go — актуальный список классов размеров аллокатора
• runtime/malloc.go — аллокатор, tiny allocator и описание размерных классов
• A Guide to the Go Garbage Collector — как GC работает с объектами и указателями