Определите, сможет ли сборщик мусора Go освободить объекты после завершения makeCycle, несмотря на взаимные...

package main

import "runtime"

type Node struct {
    next *Node
    data [1024]byte
}

func makeCycle() {
    a := new(Node)
    b := new(Node)
    a.next = b
    b.next = a
    runtime.KeepAlive(a)
}

func main() {
    makeCycle()
    runtime.GC()
}

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

Да. После возврата из makeCycle объекты a и b могут быть собраны, если до них больше нельзя добраться из корней GC. Взаимная ссылка сама по себе не сохраняет цикл живым; runtime.GC() лишь запускает сборку, но не гарантирует немедленное возвращение памяти операционной системе.

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

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

Для Go это особенно важно в программах с графами объектов, кэшами и долгоживущими горутинами. Цена подхода — необходимость периодически обходить достижимые объекты и учитывать влияние сборки на CPU и пропускную способность приложения.

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

Разработчик может ошибочно считать, что объект жив, пока на него ссылается хотя бы другой объект. При таком рассуждении цикл a -> b -> a выглядит неосвобождаемым, хотя после выхода из функции весь цикл может стать недостижимым.

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

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

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

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

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

Вызов runtime.GC() просит рантайм выполнить сборку, но не является способом управлять каждым объектом вручную. Освобождение памяти внутри управляемой кучи и возврат страниц ОС — разные операции; даже после обнаружения мусора процесс может сохранить выделенные страницы для последующих аллокаций.

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

В сервисе строится временный граф взаимосвязанных объектов для обработки запроса. После обработки разработчик опасается циклов и добавляет код, который вручную обнуляет ссылки во всех узлах.

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

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

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

1. Вопрос: Может ли один живой объект удерживать весь циклический граф?

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

2. Вопрос: Что изменится, если сохранить a в глобальной переменной перед возвратом из makeCycle?

   Ответ: Цикл станет достижимым через глобальную переменную. Пока глобальная ссылка не будет заменена или очищена, GC будет считать живыми и a, и b, поскольку от a существует путь до b, а затем обратно до a. Обнуление глобальной ссылки делает граф недостижимым, но всё равно не задаёт точный момент фактической сборки.

3. Вопрос: Почему наличие цикла не гарантирует утечку памяти, но глобальный кэш может её создать?

   Ответ: Цикл без внешнего пути от корней не достигается при трассировке и может быть собран. Кэш обычно является глобальным или долгоживущим объектом, поэтому записи в нём остаются достижимыми независимо от того, используются ли они логически. Если кэш не ограничивает размер или время жизни записей, память растёт из-за достижимости объектов, а не из-за самого факта циклических ссылок.