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

defer внутри цикла откладывает освобождение ресурса до завершения всей функции benchmark, а не текущей итерации. Поэтому ресурсы накапливаются до конца прогона, а измерение дополнительно включает стоимость регистрации каждого defer; такой benchmark может показывать искажённое время и потребление памяти.

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

defer появился в Go как безопасный способ гарантировать выполнение очистки при выходе из функции, включая выход по ошибке или через return. Его область действия определяется функцией, поэтому он удобен для локальных операций, но не является механизмом автоматического завершения каждой итерации цикла.

Benchmark-функция обычно выполняет множество итераций внутри одного вызова. Из-за этого разница между областью действия функции и областью действия итерации становится существенной.

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

В таком коде освобождение откладывается до завершения BenchmarkBad:

package example

import "testing"

type resource struct{}

func acquire() *resource { return &resource{} }
func release(*resource)  {}
func work(*resource)      {}

func BenchmarkBad(b *testing.B) {
	for i := 0; i < b.N; i++ {
		r := acquire()
		defer release(r)
		work(r)
	}
}

При большом b.N одновременно удерживается много ресурсов. Кроме того, defer регистрируется на каждой итерации, а сами отложенные вызовы выполняются уже после остановки цикла. В результате benchmark измеряет не только work, но и накладные расходы накопления отложенных вызовов, а при реальном ресурсе может исчерпать файловые дескрипторы, память или другие лимиты.

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

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

func oneIteration() {
	r := acquire()
	defer release(r)
	work(r)
}

func BenchmarkGood(b *testing.B) {
	for i := 0; i < b.N; i++ {
		oneIteration()
	}
}

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

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

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

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

Benchmark проверял обработку сетевых соединений и создавал соединение на каждой итерации, закрывая его через defer прямо в цикле. На малом числе итераций проблема была незаметна, но при автоматически выбранном большом b.N процесс достигал лимита открытых файлов, а время итерации росло от прогона к прогону.

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

Выбрали отдельную функцию для одной операции: соединение закрывалось после каждой итерации, а benchmark оставался близким к production-сценарию. После этого исчезло накопление ресурсов, а результаты стали стабильнее между запусками.

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

Выполняется ли defer после каждой итерации цикла?

Нет. Он выполняется при выходе из функции, в которой был зарегистрирован. Для обычного цикла внутри benchmark это означает выполнение всех отложенных вызовов после завершения цикла и выхода из benchmark-функции.

Всегда ли defer внутри benchmark нужно считать ошибкой?

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

Нужно ли исключать очистку из времени benchmark?

Не всегда. Если пользовательская операция включает закрытие ресурса, исключение Close даст слишком оптимистичный результат. Если цель — отдельно измерить только вычисление, очистку можно вынести за измеряемую область, но это решение должно соответствовать формулировке метрики. В benchmark важно заранее определить, измеряется ли полная операция, включая управление ресурсом, или только её отдельная фаза.