Выделение структур в стеке и куче в Go: как это связано со сборкой мусора?

Короткий ответ: доверяй компилятору, но знай теорию

В Go нет жёсткого правила «оператор & = куча, var x T = стек». Решение о месте размещения принимает компилятор на этапе оптимизации (это называется escape analysis — анализ ускользания). Если компилятор докажет, что указатель на переменную не «убегает» за пределы функции, переменная останется на стеке. Если указатель может быть использован после возврата из функции (или передан в другую горутину), переменная «убегает» в кучу.

Разбор вашего примера

func createUser(name string, age int) *User {
    u := User{Name: name, Age: age}
    return &u // указатель на локальную переменную возвращается наружу
}

Здесь u обязательно будет выделена в куче. Почему? Потому что после возврата из функции стековый фрейм createUser будет уничтожен, а указатель &u продолжает жить в вызывающем коде. Если бы u осталась на стеке, мы бы получили висячий указатель — как в C++. Go этого не допускает, поэтому компилятор перемещает структуру в кучу. Сборщик мусора (GC) потом освободит эту память, когда на неё не останется ссылок.

Когда структура остаётся на стеке?

Если структура создаётся и используется только внутри функции, не возвращается и не передаётся по указателю в другие функции (которые могут сохранить указатель), она с высокой вероятностью попадёт на стек.

func process() {
    p := Point{X: 10, Y: 20} // живёт только здесь
    fmt.Println(p.X)
} // после этой скобки p уничтожается вместе со стеком

Здесь p — на стеке. Сборщик мусора даже не знает о её существовании.

А что с передачей по значению vs по указателю?

Передача структуры по значению (копирование) часто безопаснее для стека: компилятору легче доказать, что данные не ускользают. Передача по указателю может заставить компилятор переместить данные в кучу, если он не уверен в безопасности.

// По значению — обычно стек (если структура маленькая)
func printUser(u User) {
    fmt.Println(u.Name)
}

// По указателю — может ускользнуть в кучу
func printUserPtr(u *User) {
    fmt.Println(u.Name)
}

Но это не абсолютное правило! Если передать указатель и функция просто читает поле, не сохраняя указатель, компилятор может и в этом случае оставить всё на стеке.

Как это связано со сборкой мусора?

• Стек — память управляется автоматически: фреймы создаются при вызове функции и уничтожаются при возврате. GC не нужен.
• Куча — память выделяется динамически, и GC периодически проверяет, какие объекты больше не используются, и освобождает их.

Чем больше данных в куче, тем чаще и дольше работает GC. Поэтому для высокопроизводительного кода стараются минимизировать «убегание» в кучу.

Как проверить, куда что попало?

Используйте флаг -gcflags="-m" при компиляции:

go build -gcflags="-m" main.go

Вы увидите сообщения вида:

./main.go:10:6: moved to heap: u
./main.go:15:14: &Point escapes to heap

Это лучший способ узнать, что на самом деле решил компилятор.

Практический совет

Не пытайтесь угадать — пишите логичный код. Если структура маленькая (до 4-8 слов памяти) и не мутируется, передавайте её по значению. Если большая или должна быть общей — используйте указатель. Доверьте escape analysis оптимизацию компилятору. Профилируйте и смотрите на аллокации через go tool pprof, если производительность критична.