La iteración sobre mapas en Go es una operación inherentemente no determinista, lo que significa que el orden de los elementos devueltos en un bucle range no está garantizado entre ejecuciones sucesivas, incluso si el contenido del mapa permanece estático.
Este comportamiento fue introducido deliberadamente por el equipo de diseño de Go para evitar que los desarrolladores dependieran de un orden accidental derivado de la implementación interna de la tabla de hash. En lenguajes donde el orden parece consistente debido a la estructura de los buckets, los programadores suelen escribir código frágil que se rompe cuando cambia la versión del lenguaje o la arquitectura. Go fuerza el reconocimiento de este límite técnico aleatorizando el punto de inicio de la iteración mediante el runtime.
Mecanismo de aleatorización en el hmap
Internamente, un mapa es un puntero a una estructura hmap. Cuando se inicia un bucle range, Go no comienza simplemente en el primer bucket de memoria. En su lugar, el runtime selecciona un bucket de inicio aleatorio y un offset de celda también aleatorio mediante una semilla generada al inicializar el iterador. Este proceso asegura que, aunque los datos residan físicamente en las mismas direcciones de memoria (underlying type *hmap), la secuencia lógica observada por el programa sea distinta en cada ejecución.
Para obtener un orden predecible, la técnica estándar consiste en extraer las claves a un slice, ordenarlas explícitamente y luego iterar sobre dicho slice para acceder a los valores del mapa.
package main
import (
"fmt"
"sort"
)
func main() {
stats := map[string]int{
"alpha": 10,
"beta": 20,
"gamma": 30,
"delta": 40,
}
// Ejemplo 1: Iteración no determinista
// El output cambiará en distintas ejecuciones de 'go run'
for k, v := range stats {
fmt.Printf("%s: %d ", k, v)
}
// Posible Output A: gamma: 30 alpha: 10 delta: 40 beta: 20
// Posible Output B: alpha: 10 delta: 40 gamma: 30 beta: 20
// Ejemplo 2: Iteración ordenada (Determinista)
keys := make([]string, 0, len(stats))
for k := range stats {
keys = append(keys, k)
}
// Ordenamiento in-place del slice de claves
sort.Strings(keys)
fmt.Println("\nOrdenado:")
for _, k := range keys {
fmt.Printf("%s: %d ", k, stats[k])
}
// Output siempre constante: alpha: 10 beta: 20 delta: 40 gamma: 30
}
El aspecto más contraintuitivo de este comportamiento es que el orden puede parecer estable durante pequeñas pruebas locales o dentro de una misma sesión de ejecución si no se reinicia el binario, lo que genera una falsa sensación de seguridad que suele derivar en bugs difíciles de reproducir en entornos de integración continua (CI) o producción.
Semillas de hash y estabilidad en mapas pequeños
Un comportamiento específico del runtime de Go es que la aleatorización ocurre incluso en mapas extremadamente pequeños que residen en un solo bucket. Aunque físicamente no hay otros buckets hacia donde saltar, el iterador aplica el offset aleatorio dentro de las ocho celdas del bucket único.
Existe un edge case relacionado con la serialización: al codificar un mapa a JSON mediante encoding/json, la librería estándar de Go ordena las claves alfabéticamente de forma automática antes de generar el string. Esto se hace para garantizar que las firmas de red o los archivos generados sean comparables (deterministas), a pesar de que el mapa en memoria carezca de ese orden. Confundir la estabilidad de una salida JSON con la estabilidad del mapa nativo es un error conceptual común en el manejo de estados compartidos.
- Módulo: Colecciones y Memoria
- Artículo número: #42