Respuesta.

El trabajo con colecciones concurrentes en Go se ha convertido en un tema importante debido a las crecientes demandas de aplicaciones multihilo. Los mapas normales en Go no son seguros para hilos y pueden conducir a condiciones de carrera (data race). La aparición de sync.Map proporcionó una solución estándar para el acceso seguro compartido a colecciones sin sincronización externa.

Historia del tema:

Antes de la aparición de sync.Map, los desarrolladores debían usar mapas normales con un Mutex o RWMutex externo para organizar el acceso seguro desde múltiples goroutines. Esto aumentaba la cantidad de código y la probabilidad de errores de sincronización. En Go 1.9 se introdujo sync.Map con el objetivo de simplificar el trabajo con colecciones concurrentes.

Problema:

Un mapa normal no es seguro para hilos. Si varias goroutines leen y escriben en un mapa sin sincronización, esto puede llevar a pánicos o resultados inesperados. El Mutex es complicado de usar correctamente y puede llevar a bloqueos y degradación del rendimiento. También se presentan dificultades con el "double check" y problemas de sincronización difícil de medir.

Solución:

sync.Map es una estructura especial de la biblioteca estándar que proporciona métodos seguros para hilos como Load, Store, LoadOrStore, Delete, Range. Implementa una estrategia sin bloqueo (parcialmente), optimizada para escenarios con lecturas frecuentes y escrituras poco frecuentes.

Ejemplo de código:

import (
	"fmt"
	"sync"
)

func main() {
	var m sync.Map
	m.Store("foo", 42)
	value, ok := m.Load("foo")
	fmt.Println(value, ok) // 42 true
	m.Delete("foo")
}

Características clave:

Seguridad para hilos sin bloqueo explícito para la mayoría de las operaciones.
El rendimiento es óptimo para sistemas donde predominan las lecturas sobre las escrituras.
Ausencia de una fuerte tipificación de claves y valores (tipo de interfaz).

Preguntas capciosas.

¿Se puede reemplazar todos los mapas por sync.Map en programas multihilo?

No, sync.Map no es un reemplazo universal para un mapa normal. Funciona bien para aquellas estructuras de datos donde predominan las lecturas competitivas e independientes, pero en casos de escritura intensa (modificaciones frecuentes) o para colecciones pequeñas, los mapas normales + Mutex son más rápidos y eficientes.

¿Qué sucede si utilizo un mapa normal solo para lectura en varias goroutines?

Si el mapa está completamente inicializado y no se modifica después de que todas las goroutines han comenzado, la lectura paralela es aceptable y segura. Pero cualquier eliminación o modificación de datos dará lugar a un comportamiento impredecible, pánico o un mapa corrupto.

¿Qué tipos de datos se pueden usar como clave para sync.Map?

Las reglas son las mismas que para un mapa normal: solo tipos comparables. Sin embargo, sync.Map acepta claves de cualquier tipo de interfaz{}, lo que puede crear riesgos de objetos con semánticas diferentes que no se pueden comparar entre sí o en los que se permiten errores en tiempo de ejecución.

Ejemplo de código:

var m sync.Map
m.Store([]int{1,2}, "value") // panic: runtime error: hash of unhashable type []int

Errores comunes y anti-patrones

Uso prematuro o injustificado de sync.Map en lugar de un mapa normal y Mutex sin perfilado.
Uso de sync.Map para colecciones pequeñas, lo que lleva a costos adicionales y a una degradación del rendimiento.
Intento erróneo de usar tipos de claves incorrectas (por ejemplo, slices).
Uso simultáneo de sync.Map y primitivas de sincronización externas para los mismos datos.

Ejemplo de la vida real

Caso negativo

Un desarrollador utilizó sync.Map para almacenar configuraciones de aplicaciones que cambian raramente, pero se leen frecuentemente. Sin embargo, más tarde comenzaron a escribir masivamente datos sobre sesiones de usuarios, lo que llevó a un aumento inesperado en la carga del GC y degradación del rendimiento.

Ventajas:

El código se volvió más simple, con menos gestión manual de mutex.
No aparecieron problemas de competencia en la fase inicial.

Desventajas:

Aumento rápido de memoria y latencias con un gran número de escrituras paralelas.
Surgen dificultades con la tipificación y errores al trabajar con claves.

Caso positivo

El equipo implementó sync.Map para almacenar el caché de resultados de cálculos solicitados frecuentemente en un servicio de alta carga. La cantidad de "lecturas" supera a las "escrituras" por cientos de veces. Todo funciona de manera estable y eficiente, y el código se volvió más corto y más fácil de mantener.