Указатели в Go

Что можно и чего нельзя

Указатель хранит адрес значения: & берёт адрес, * разыменовывает. И на этом всё - арифметики указателей в Go нет, p++ не скомпилируется, привести указатель к числу и обратно штатными средствами нельзя.

Это не занудство, а две конкретные выгоды. Первая: выход за границы памяти через указатель невозможен в принципе, потому что сдвинуть его некуда. Вторая: сборщик мусора точно знает, на что указывает каждый указатель, и может двигать объекты и определять живое без догадок. Обход последовательностей делают слайсом с индексом, и этого хватает.

Разыменование nil даёт панику с текстом runtime error: invalid memory address or nil pointer dereference. Именно панику - со стеком, с трассировкой и с возможностью перехватить через recover, а не порчу чужой памяти и не загадочное поведение через двадцать минут.

// Тонкость, которую любят спрашивать: вызвать метод на nil-указателе можно, если тело не обращается к полям. Проверено: метод с получателем *T, начинающийся с проверки if t == nil, спокойно вызывается на nil и возвращает свой ответ. На этом строят nil-безопасные методы вроде func (t *Tree) Size() int - для пустого дерева ноль.

разыменование

*p - обращение к значению по адресу

nil pointer dereference

паника при обращении к полю nil-указателя; перехватывается через recover

Escape analysis: кто решает, где жить значению

В C переменная функции живёт на стеке, стек сворачивается при выходе, и адрес становится мусором. В Go выбор между стеком и кучей делает не программист, а компилятор, и делает он его на этапе сборки.

Анализ простой по идее: если компилятор доказал, что адрес значения не переживает вызов, значение остаётся на стеке - это дёшево, стек сворачивается сам. Если адрес утекает наружу, значение размещается в куче, и дальше за ним следит сборщик мусора. Повисшего указателя не возникает никогда.

Посмотреть решения можно сборкой с флагом -gcflags=-m. На конструкторе func New() *T { return &T{X: 1} } вывод скажет: &T{...} escapes to heap. А рядом обнаружится вторая частая причина ухода в кучу, про которую забывают: укладка значения в интерфейс. Строчка p.X escapes to heap появляется просто потому, что поле передали в fmt.Println, а он принимает any.

// Поэтому конструктор вида func New() *T { return &T{} } - нормальная идиома Go, а не подозрительный код. И поэтому же fmt.Println в горячем цикле стоит дороже, чем кажется: каждый аргумент уезжает в кучу.

escape analysis

анализ компилятора, решающий, разместить значение на стеке или в куче

-gcflags=-m

флаг сборки, печатающий решения этого анализа

Когда указатель, а когда значение

Указатель берут по двум причинам: нужно менять оригинал или структура крупная и копия заметна. Всё остальное по умолчанию передают значением - оно проще, безопаснее в конкурентном коде и часто остаётся на стеке.

Брать указатель везде подряд - распространённая ошибка новичка. Каждый указатель на структуру, уехавшую в кучу, это работа сборщику мусора, а сборщик в Go хоть и быстрый, но не бесплатный.

Отдельная категория - типы, которые нельзя копировать после начала использования: sync.Mutex, sync.WaitGroup, sync.Once и всё, что содержит их внутри. Копия получает собственное состояние блокировки, и синхронизация тихо перестаёт работать: два потока спокойно заходят в критическую секцию, каждый через свою копию мьютекса.

// Ловит это go vet, и сообщение вполне внятное: Bad passes lock by value: Store contains sync.Mutex. Поэтому методы у типов с мьютексом объявляют на указателе, а WaitGroup передают указателем либо замыкают в горутине. Проверено на живом примере - vet находит это сразу.

go vet

штатный статический анализатор; ловит копирование блокировок и ещё десяток типовых ошибок

Как отвечать: «Безопасно ли возвращать указатель на локальную переменную?»

Да, в Go это обычная и безопасная идиома, в отличие от C. Компилятор делает escape analysis: видит, что адрес локальной переменной уходит наружу и переживает вызов, и размещает значение не на стеке, а в куче. Дальше за ним следит сборщик мусора, поэтому повисшего указателя не возникает. Проверить решение компилятора можно сборкой с -gcflags=-m: в выводе будет строчка про escapes to heap. Поэтому конструкторы вида func New() *T { return &T{} } - нормальный идиоматичный код, и бояться тут нечего. Заодно упомяну две смежные вещи. Арифметики указателей в Go нет, p++ не скомпилируется, и это отрезает выход за границы памяти и упрощает работу сборщику. А разыменование nil даёт предсказуемую панику с трассировкой, которую можно перехватить, а не порчу памяти. Причём вызвать метод на nil-указателе можно, если тело не трогает поля - на этом строят nil-безопасные методы.

Назван механизм, дан способ проверить его инструментом, идиома конструктора подана как норма, и добавлены смежные факты про отсутствие арифметики и поведение nil - видно понимание модели памяти, а не заученная фраза.

На чём валят

• −Боятся возвращать &t из функции по привычке из C - в Go это безопасно.
• −Ищут арифметику указателей: p++ в Go не компилируется.
• −Копируют структуру с sync.Mutex внутри и тихо теряют синхронизацию.
• −Считают, что вызов любого метода на nil-указателе обязательно паникует.
• −Берут указатель везде подряд и грузят сборщик мусора без нужды.
• −Забывают, что аргумент fmt.Println уезжает в кучу из-за укладки в интерфейс.