La sentencia defer es la instrucción que le dice al runtime que ejecute una función justo antes de que la función actual termine su ejecución. Internamente, Go gestiona esto mediante una pila (stack) de llamadas pendientes que se procesa en orden inverso (LIFO) al retornar. Históricamente, cada defer implicaba una asignación en el heap y un pequeño overhead de rendimiento, pero desde Go 1.14 [disponible desde Go 1.14], el compilador implementó los open-coded defers. Esto significa que si el compilador puede determinar estáticamente qué funciones se van a ejecutar y el contexto es simple, simplemente “inلinea” la llamada al final de la función, eliminando prácticamente cualquier costo de ejecución.
Deberías usar defer siempre que necesites garantizar la liberación de recursos (como un os.File o un sync.Mutex) para evitar fugas. Sin embargo, el compilador solo puede aplicar la optimización de open-coded defers en casos muy específicos. Si el defer está dentro de un bucle for o si su ejecución depende de una variable cuyo valor solo se conoce en tiempo de ejecución, el compilador debe recurrir al mecanismo tradicional de la pila dinámica, que es más lento y consume más memoria. El peligro real no es el costo de CPU, sino el error de diseño: usar defer dentro de un loop. Al hacerlo, no estás liberando el recurso al final de la iteración, sino que acumulas todas las llamadas en la pila de la función principal, lo que puede agotar los descriptores de archivos o la memoria antes de que la función siquiera termine.
package main
import (
"fmt"
)
// MockResource simula un recurso que consume un descriptor de archivo o memoria.
type MockResource struct {
id int
}
func (r *MockResource) Close() {
fmt.Printf(" [Cleanup] Liberando recurso %d\n", r.id)
}
func main() {
fmt.Println("--- Escenario 1: Uso correcto (encapsulamiento) ---")
processBatchSafe()
fmt.Println("\n--- Escenario 2: Uso incorrecto (acumulación en loop) ---")
processBatchLeaky()
}
// processBatchSafe demuestra cómo delimitar el ciclo de vida de un defer.
func processBatchSafe() {
for i := 1; i <= 3; i++ {
// Usamos una función anónima para crear un nuevo scope.
// El defer se ejecuta al terminar la función anónima, no la función principal.
func(id int) {
res := &MockResource{id: id}
defer res.Close() // Este defer es de bajo costo y se libera rápido.
fmt.Printf("Procesando recurso %d de forma segura\n", id)
}(i)
}
}
// processBatchLeaky muestra el error de acumular defers en un loop.
func processBatchLeaky() {
// Simulamos una lista de recursos que se quedan abiertos hasta el final de la función.
for i := 1; i <= 3; i++ {
res := &MockResource{id: i}
// ERROR: El defer se registra en la pila de processBatchLeaky.
// No se ejecutará hasta que processBatchLeaky retorne.
defer res.Close()
fmt.Printf("Procesando recurso %d (pero su defer está esperando...)\n", i)
}
fmt.Println("Finalizando loop de leakyProcessing...")
// Solo aquí se ejecutarán todos los defers acumulados de golpe.
}
Desglose del código
En processBatchSafe, hemos evitado el anti-patrón envolviendo la lógica en una función anónima (también conocida como closure). Al llamar a res.Close() mediante un defer dentro de esa función, el runtime libera el recurso inmediatamente después de que termina la iteración i. Esto permite que el compilador optimice la gestión de la pila y mantiene la huella de memoria constante, sin importar cuántas iteraciones realicemos.
Por el contrario, en processBatchLeaky, el defer res.Close() está registrado directamente en el scope de processBatchLeaky. Fíjate que, aunque el loop termine, los mensajes de [Cleanup] no aparecen durante el loop; aparecen todos juntos al final, después del mensaje "Finalizando loop...". Esto es porque el runtime ha ido apilando cada llamada a Close() en la pila de la función. Si este loop procesara un millón de archivos, tendrías un millón de llamadas esperando en memoria y un error de “too many open files” mucho antes de llegar al final de la función.
El error frecuente
El error más común es confundir el alcance (scope) de la instrucción defer con el alcance del bucle for.
// Código con error de fuga de recursos
func problematicLoop() error {
for _, filename := range files {
f, err := os.Open(filename)
if err != nil {
return err
}
// MAL: f.Close() no se ejecutará hasta que problematicLoop termine.
// Si 'files' tiene 10.000 elementos, abrirás 10.000 archivos simultáneamente.
defer f.Close()
if err := process(f); err != nil {
return err
}
}
return nil
}
Si necesitas que un recurso se cierre en cada iteración, tienes dos opciones: llamar a la función de cierre manualmente (si es seguro) o, preferiblemente, refactorizar el cuerpo del loop en una función independiente o una función anónima para que el defer actúe como esperas.
N° 45