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

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

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

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

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

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

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

Неверно считать, что достижение объектом состояния недостижимости немедленно вызывает очистку. Кроме того, финализатор может случайно снова сделать объект достижимым, усложнив анализ времени жизни и задержав освобождение ещё сильнее.

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

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

Финализатор не следует воспринимать как часть обычного протокола владения ресурсом. Основной путь должен явно освобождать ресурс, например через метод закрытия и конструкцию defer, а финализатор может использоваться только как аварийный запасной путь.

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

Минимальный пример регистрации финализатора:

package main

import "runtime"

type Resource struct{}

func cleanup(*Resource) {}

func main() {
	r := &Resource{}
	runtime.SetFinalizer(r, cleanup)
	// Явное освобождение ресурса должно быть основным путем.
	_ = r
}

Регистрация финализатора сама по себе не даёт синхронного вызова cleanup. Для проверки такого поведения нельзя полагаться на немедленный запуск GC или на наличие конкретного вывода в заданный момент.

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

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

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

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

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

Вопрос: Может ли финализатор сделать объект снова достижимым?

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

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

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