Antes de Go 1.22, la especificación del lenguaje asignaba las variables de bucle una vez por declaración de bucle en lugar de por iteración. Esta única ubicación de memoria se reutilizaba para cada iteración, cambiando solo su valor secuencialmente. Cuando un cierre capturaba esta variable por referencia—común en goroutines lanzadas dentro del bucle—todos los cierres compartían la misma dirección de memoria. En consecuencia, cada cierre observaba el valor final asignado a esa dirección una vez que el bucle se completaba.
Go 1.22 introdujo un alcance por iteración, lo que significa que cada iteración instancia una variable nueva con una dirección de memoria distinta. Esto asegura que los cierres capturen el valor específico para esa iteración en lugar de una ubicación mutable compartida. Este cambio eliminó una de las trampas de concurrencia más comunes mientras mantenía la compatibilidad hacia atrás para el código que no dependía de la identidad de dirección de las variables de bucle.
Un servicio de procesamiento de datos necesitaba distribuir lecturas de sensores a goroutines de trabajo para validación paralela antes de almacenamiento.
El equipo inicialmente implementó la dispersión utilizando la sintaxis de cierre idiomática:
readings := []SensorReading{{ID: 1}, {ID: 2}, {ID: 3}} for _, r := range readings { go func() { validate(r.ID) // Error crítico: Todas las goroutines validan el ID 3 }() }
Al implantarse, los registros revelaron que cada trabajador procesaba el mismo último registro, mientras que los registros anteriores eran completamente ignorados, causando pérdida de datos.
Solución 1: Sombreado de variables. Este enfoque introduce una nueva variable dentro del cuerpo del bucle para sombrear la variable de iteración, forzando una asignación de pila distinta para cada iteración. Pros: Soluciona inmediatamente el problema de captura sin requerir cambios en las firmas de función. Contras: Se basa en un sutil truco léxico que parece sintácticamente redundante para los revisores y no proporciona protección del compilador si se elimina accidentalmente durante la refactorización.
Solución 2: Paso de parámetros. Este método pasa explícitamente el valor como argumento al cierre, asegurando que la evaluación ocurra en cada iteración en lugar de en el momento de la llamada. Pros: Es inequívoco, portátil a través de todas las versiones de Go, y hace que las dependencias de datos sean explícitas y auto-documentadas. Contras: Requiere reestructurar el cierre para aceptar parámetros, lo que añade una sobrecarga sintáctica mínima pero no nula.
Solución 3: Actualización de infraestructura. Migrar toda la flota a Go 1.22+ para aprovechar la nueva semántica de variable por iteración. Pros: Elimina la causa raíz a nivel de lenguaje, permitiendo un código idiomático más limpio. Contras: Requiere cambios coordinados en la infraestructura y no ofrece alivio para las bases de código heredadas que deben permanecer en herramientas más antiguas.
El equipo seleccionó Solución 2 para el despliegue inmediato. Esta decisión aseguró que el código se comportara correctamente en todas las versiones del compilador y no dependiera de sutiles trucos de sombreado que podrían ser eliminados accidentalmente.
Después de la implementación, cada goroutine recibió su ID de sensor distinto, la tubería procesó todos los registros correctamente y el sistema se mantuvo estable durante la posterior actualización a Go 1.22.
¿Por qué tomar la dirección de una variable de iteración de for-range en Go 1.22+ aún no permite la modificación directa de los elementos originales del slice?
Incluso con variables por iteración, la variable de iteración contiene una copia del elemento del slice, no el elemento en sí. Tomar su dirección da como resultado un puntero a esta copia efímera en lugar de la entrada en el array subyacente. Dado que la variable de cada iteración es una ubicación distinta pero contiene una copia del valor, modificar *(&v) afecta solo la copia temporal, que se descarta cuando termina la iteración. Para modificar el slice origen, debes usar la sintaxis de índice: for i := range slice { slice[i].Field = NewValue }.
¿El cambio de alcance por iteración en Go 1.22 introduce costos de rendimiento o asignaciones adicionales de heap en comparación con el modelo de reutilización de variables anterior a 1.22?
No. El compilador de Go optimiza las variables por iteración para residir en la pila o en registros cuando los cierres no escapan al heap. El cambio semántico afecta el alcance léxico y la identidad del puntero, no la estrategia de asignación o el rendimiento en tiempo de ejecución del bucle en sí. Los bucles sin cierres exhiben características de rendimiento idénticas antes y después del cambio.
¿Cómo afectó el comportamiento de reutilización de variables en el Go anterior a 1.22 a los bucles for de tres cláusulas tradicionales en comparación con los bucles for-range?
El comportamiento era idéntico en todas las variantes del bucle for. Tanto for i := 0; i < n; i++ como for _, v := range m reutilizaban la misma dirección de memoria para sus variables de iteración en todas las iteraciones. Los candidatos a menudo asumen incorrectamente que el error de cierre obsoleto era único de los bucles range, pero los cierres que capturaban el índice i en un bucle de tres cláusulas sufrían el mismo problema, imprimiendo el valor final de i en lugar del valor esperado de iteración. Go 1.22 resolvió esto de manera uniforme para todos los tipos de bucles.