Resumen de Puntos Clave de Concurrencia

Cada punto clave de las 9 páginas de esta sección, reunido en una sola página y agrupado por la página de la que proviene.

Concurrencia en Go: Goroutines y Canales Primero

• La concurrencia en Go se basa en goroutines y canales, no en hilos y bloqueos por defecto
• El lema es compartir memoria comunicando, no comunicar compartiendo memoria
• Los canales sin búfer sincronizan el remitente y el receptor en el punto de enlace
• El planificador GPM del runtime multiplexa goroutines en hilos del sistema operativo
• Existen Mutexes y atómicos para cuando los canales son la abstracción incorrecta

Conceptos Básicos de Concurrencia

• Lanza goroutines con go; siempre sincroniza con WaitGroup o canales, no con time.Sleep
• Los canales sin búfer bloquean los envíos hasta que un receptor está listo, creando sincronización
• Dimensiona los canales con búfer según el estallido natural de tu pipeline, no arbitrariamente grandes
• Pasa las variables de bucle como parámetros a las goroutines para evitar errores de captura de cierre
• Solo el remitente cierra un canal; recibir de un canal cerrado devuelve valores cero
• Protege los datos compartidos mutados por múltiples goroutines con un bloqueo para evitar carreras

Goroutines: Costo de Creación y Resumen de Planificación

• Las pilas de goroutines comienzan pequeñas y crecen bajo demanda
• El modelo GPM mapea muchas goroutines a menos hilos del sistema operativo
• Las llamadas al sistema bloqueantes y las esperas de canal detienen las goroutines sin desperdiciar hilos
• GOMAXPROCS limita la ejecución paralela de CPU, no el número de goroutines
• La expansión ilimitada de goroutines aún puede agotar la memoria

Canales: Reglas de Búfer, Sin Búfer y Cierre

• Los canales sin búfer bloquean al remitente hasta que el receptor está listo para una sincronización fuerte
• Los canales con búfer almacenan valores hasta la capacidad, reduciendo la presión de sincronización
• Enviar en un canal cerrado provoca un pánico, pero recibir de forma segura devuelve el valor cero
• Solo el remitente debe cerrar un canal para evitar pánicos de doble cierre
• Iterar sobre un canal hasta el cierre o usar ok para detectar el cierre del canal
• Dimensiona los búferes para que coincidan con el SLA, no para enmascarar sobrecargas o ocultar el crecimiento de la latencia

Sentencia select y Casos Predeterminados

• select se bloquea hasta que un caso procede, eligiendo de forma pseudoaleatoria si varios están listos
• default se ejecuta inmediatamente cuando ningún caso de canal está listo; nunca lo uses para espera activa
• Evita time.After en bucles ajustados; usa time.NewTimer o context para un mejor comportamiento de la GC
• Calcula valores costosos antes de select; las expresiones se evalúan de forma anticipada antes de esperar
• break solo sale de select, no del bucle for circundante; usa etiquetas o return para escapar
• Establece el canal en nil para deshabilitar una rama del caso select hasta que la necesites de nuevo

sync.Mutex, RWMutex y WaitGroup

• Serializa el acceso con Mutex, o permite muchos lectores con RWMutex
• Usa defer unlock inmediatamente después de lock para prevenir deadlocks
• Nunca copies Mutex o WaitGroup después del primer uso; pásalos por puntero
• Llama a Add antes de iniciar goroutines; Done una vez por Add; luego Wait
• Copia los datos bajo el bloqueo, suelta, luego realiza operaciones de E/S
• Establece un orden de bloqueo global para prevenir deadlocks entre goroutines

sync.Once, Cond, Pool y sync.Map

• sync.Once garantiza que una función se ejecute exactamente una vez
• sync.Cond coordina goroutines que esperan una condición
• sync.Pool reutiliza objetos temporales entre ciclos de GC
• sync.Map se adapta a cachés con muchas lecturas y claves estables
• Cada primitiva resuelve un problema específico; no uses sync.Map por defecto para todos los mapas

Detector de Carreras: Ejecución e Interpretación de Salida

• Habilita con -race en go test, go run o go build para encontrar carreras
• Una carrera de datos requiere que dos goroutines accedan a la misma memoria con al menos una escritura
• La sobrecarga es de 2-10 veces la CPU y 5-10 veces la memoria, no apta para producción
• Corrige las carreras con mutexes, canales, atómicos o reestructurando la propiedad
• Haz que -race sea obligatorio en CI para evitar que las carreras lleguen a producción
• El detector de carreras encuentra carreras pero no detecta deadlocks

Mejores Prácticas de Fundamentos de Concurrencia

• Prefiere canales para la transferencia de propiedad; mutexes para estructuras compartidas
• Siempre coordina el apagado antes de que main retorne
• Ejecuta go test -race en CI para paquetes concurrentes
• Dimensiona los búferes y los pools de trabajadores según la carga, no por suposiciones
• Propaga la cancelación del contexto para detener fugas de goroutines

WTI5a1pXZDFhV1JsY3k1cGIzeGpaMmx2TXpreGZESXdNall3Tnc9PQ==