Desarrollador Go: pregunta de entrevista
¿Por qué las escrituras concurrentes en maps son inseguras en Go?
Los maps normales de Go no son seguros para escrituras concurrentes. La mutación concurrente puede provocar un panic; protege el map con sync.Mutex o sync.RWMutex, divide la propiedad o usa sync.Map solo si su patrón de acceso encaja.
Respuesta directa
Qué debe cubrir una buena respuesta
Cómo funciona
El map integrado no está sincronizado. El runtime detecta algunas escrituras concurrentes y aborta el programa con un error fatal que no se puede recuperar, y los accesos sin sincronizar que escapan a la detección pueden corromper los buckets internos. Una lectura concurrente con una escritura también es una carrera de datos, así que la regla cubre cualquier patrón de acceso.
Ejemplo
Una caché actualizada por varias goroutines puede usar un mutex alrededor de read-modify-write; no supongas que leer es seguro si otra goroutine puede escribir. Ejecuta el detector de carreras en CI para que go test -race avise de un lock ausente antes de que sea una caída en producción.
Errores frecuentes
- Creer que las lecturas son seguras si solo una goroutine escribe.
- Usar sync.Map por defecto en lugar de un mutex alrededor de un map normal.
- Copiar un map para pasarlo a otra goroutine mientras se sigue mutando el original.
Una estructura útil para responder
Responde desde tu propia experiencia.
No memorices un guion: usa solo ejemplos que puedas explicar con honestidad en preguntas posteriores.
Abre el espacio de trabajo de escritorio y ensaya una respuesta clara con tus propias palabras.