Отложенные вызовы defer

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

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

В C до этого доходили через goto cleanup — метка в конце функции, куда сходились все ветки. Defer — та же идея, встроенная в язык и безопасная даже при панике.

Отложенные вызовы копятся в стек и выполняются в обратном порядке: последним объявлен — первым выполнен. LIFO (last in, first out) здесь не прихоть дизайнеров, а прямое следствие парности ресурсов. Открыли A, потом внутри открыли B — закрывать нужно сначала B, потом A. Блокировка, взятая внутри транзакции, отпускается раньше самой транзакции. Обратный порядок поддерживает вложенность автоматически, вам не надо ничего запоминать.

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

Нюанс, на котором валится половина собеседований: аргументы отложенного вызова вычисляются тогда, когда выполняется строка defer, — а не когда вызов доходит до исполнения. Разберём на примере.

```go package main

import "fmt"

func main() { x := 1 defer fmt.Println("defer x =", x) // значение прочитано прямо здесь: 1 x = 100 fmt.Println("тело x =", x) } // Вывод в настоящем Go: // тело x = 100 // defer x = 1 ```

Строка с defer прочитала x, когда он был равен 1, — и сохранила это значение в стеке. Присваивание x = 100 уже ничего не меняет. При этом замыкание defer func() { ... }() захватывает переменную по ссылке и видит финальное значение — об этом следующий блок.

Именованные возвращаемые значения меняют правила игры вместе с defer. Функция с сигнатурой (result int) возвращает переменную result, а оператор return без значения возвращает её текущее содержимое. Отложенное замыкание выполняется после возврата из тела, но до передачи значения вызывающему — и успевает изменить result.

Классический приём — доработка результата: счётчики вызовов, логирование, преобразования. И классическая же ловушка: замыкание в defer может незаметно подменить то, что вы аккуратно посчитали. Если ни одно замыкание в defer не трогает ваши именованные возвраты — механизм вам не мешает. Если трогает — теперь вы знаете, откуда берётся «магическое» значение на выходе.

Тот же механизм работает и в обратную сторону: библиотеки сериализации ошибок пишут в named return внутри defer, чтобы заменить сырую панику на ошибку — приём, о котором поговорим в уроке про панику и восстановление.

Соберём механизм в одну картину. Оператор return в функции с именованным возвратом работает в три шага: сначала вычисляются возвращаемые выражения и записываются в переменные возврата, затем выполняются все отложенные вызовы по порядку LIFO, и только потом настоящий выход — значения из переменных возврата уходят вызывающему. Отсюда и возможность доработать результат: отложенный код исполняется после «возврата», но до того, как его кто-то увидел.

Из того же порядка следует и ограничение: defer не может предотвратить выход из функции (для этого нужен recover, о нём — следующий урок) и не может вернуть другое значение вместо заявленных результатов, если только не перепишет переменные возврата напрямую.

Запомните порядок «вычислил — отработал defer — вышел»: он же объясняет, почему замыкание в defer видит финальные значения, а обычный аргумент — зафиксированные.

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

Идиоматичное решение — вынести тело цикла в отдельную функцию. Defer внутри неё живёт ровно одну итерацию: обработали элемент — убрались — перешли к следующему. Ниже этот паттерн вживую.

Три сценария, где defer — не украшение, а необходимость: файлы и соединения, мьютексы, перехват паник. С файлом идиома выглядит как f, err := os.Open(path), следом defer f.Close() — и ни одна ветка не утечёт. С мьютексом — mu.Lock() и тут же defer mu.Unlock(): без отложенной разблокировки её забывают в ветке с ошибкой, и однажды программа просто встаёт. Перехват паник — отдельный разговор: recover работает только из отложенной функции, так что без defer его не существует вовсе; см. урок про панику и восстановление.

Мнение о цене: до Go 1.13 defer был дорогим, и в горячем коде его избегали. Сейчас компилятор превращает большинство defer в почти бесплатный вызов, и я больше не пишу ручные ветки уборки ради производительности. Единственное исключение — код, который вызывается десятки миллионов раз в секунду: там сначала замерьте, потом решайте. Про блокировки подробнее — в уроке про мьютексы.