Краткий ответ

Нет. uintptr — это целочисленное значение, а не ссылка, распознаваемая сборщиком мусора, поэтому оно само по себе не удерживает объект живым. После исчезновения последнего отслеживаемого указателя объект может стать недостижимым, а обратное преобразование сохранённого адреса — обратиться к уже освобождённой или переиспользованной памяти.

Для кратковременной передачи адреса в низкоуровневую операцию typed pointer нужно сохранять живым до момента окончания этой операции, обычно с помощью runtime.KeepAlive. Хранить адрес в uintptr для последующего использования нельзя считать безопасным способом продления жизни объекта.

Исторический контекст

Точный сборщик мусора должен отличать указатели от обычных чисел. Если бы любое целое, похожее на адрес, удерживало объект, случайные числовые значения могли бы бесконечно препятствовать освобождению памяти.

Тип uintptr нужен, в частности, для низкоуровневого взаимодействия с адресами и интерфейсами, где адрес временно представляется числом. Такая возможность отделяет арифметику над адресом от управления временем жизни объекта, поэтому ответственность за корректный срок использования лежит на программе.

Постановка проблемы

Наивная схема выглядит логично: получить адрес объекта, сохранить его как uintptr, а затем позже преобразовать обратно в указатель. Однако GC видит только ссылки, которые компилятор и runtime считают указателями; числовое значение адреса не входит в граф достижимости.

Если объект станет недостижимым, сборщик может освободить связанную память или использовать её для другого объекта. Обратное преобразование старого uintptr тогда приводит к неопределённому с точки зрения безопасности доступа поведению: данные могут быть изменены, память может уже не принадлежать объекту, а указатель может оказаться недействительным.

Подробное решение

Преобразование указателя в uintptr не является операцией, продлевающей жизнь объекта. Сборщик учитывает *T, unsafe.Pointer и другие отслеживаемые формы ссылок, но не обязан распознавать число как адрес объекта.

runtime.KeepAlive(x) гарантирует, что x считается живым до этой точки программы. Вызов должен находиться после последней операции, которой нужен адрес или сам объект:

package main

import (
    "runtime"
    "unsafe"
)

func useAddress(p *byte) {
    address := uintptr(unsafe.Pointer(p))
    consumeAddress(address)
    runtime.KeepAlive(p)
}

func consumeAddress(uintptr) {}

В примере consumeAddress символизирует немедленную низкоуровневую операцию. KeepAlive после неё не создаёт указатель из числа и не делает длительное хранение адреса безопасным; он лишь не позволяет компилятору считать p мёртвым раньше завершения операции.

Важно учитывать и правила unsafe: преобразование должно использоваться только в допустимых сценариях, а указатель нельзя сохранять в uintptr для произвольного будущего доступа. Для долгоживущей связи с объектом нужен настоящий указатель, а не числовая копия адреса. При взаимодействии с системными вызовами или внешним кодом также необходимо соблюдать требования соответствующего API и не передавать адрес дольше разрешённого времени.

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

Ситуация из практики

В сетевом сервисе адрес буфера преобразовали в uintptr и передавали в нативную библиотеку. Иногда библиотека читала буфер после возврата из Go-функции; при нагрузке это приводило к повреждению данных, потому что исходный объект уже не был надёжно удержан Go-ссылкой.

Рассматривались два варианта. Первый — добавить runtime.KeepAlive после вызова библиотеки; это исправляет срок жизни только при условии, что библиотека завершает использование адреса до возврата. Второй — изменить контракт так, чтобы библиотека копировала данные или явно ограничить время синхронного вызова; он уменьшает риск, но может добавить копирование или изменить производительность.

Выбрали синхронный вызов с KeepAlive после последнего обращения и запретили библиотеке сохранять адрес. Это решение устранило ошибку без дополнительной копии; если бы требовалось асинхронное использование, применили бы явное владение буфером и другой безопасный контракт, а не хранение uintptr.

Что кандидаты часто упускают

1. Достаточно ли оставить исходный указатель в локальной переменной до конца функции?

Нет, не всегда. Компилятор выполняет анализ достижимости переменных и может считать указатель больше не используемым до конца лексической области. Поэтому важна не только область видимости переменной, но и фактическая точка последнего использования. runtime.KeepAlive явно задаёт границу, до которой объект должен считаться живым.

2. Продлевает ли unsafe.Pointer жизнь объекта так же, как обычный typed pointer?

Пока значение действительно сохраняется как отслеживаемый указатель и остаётся достижимым, GC может учитывать его при трассировке. Но преобразование в uintptr эту связь разрывает. Кроме того, правила unsafe ограничивают допустимость хранения и преобразований указателей, поэтому одного факта наличия unsafe.Pointer недостаточно для безопасного произвольного управления временем жизни.

3. Можно ли безопасно преобразовать сохранённый uintptr обратно в указатель, если объект, предположительно, ещё не собирался?

На это нельзя полагаться. Предположение о том, что GC ещё не запускался или память пока не переиспользована, не является гарантией корректности. Безопасность требует, чтобы на всём интервале использования существовала корректная отслеживаемая ссылка либо чтобы операция была организована по правилам конкретного низкоуровневого API; простое совпадение числового адреса этого не обеспечивает.