Réponse

En Go, les maps ne sont pas sûres pour les threads par défaut. Si plusieurs goroutines écrivent ou lisent simultanément dans la même map sans synchronisation, cela entraînera une condition de course (data race), provoquant une panique fatal error: concurrent map read and map write ou la corruption des données.

Pour un accès sûr aux maps, il est nécessaire de :

• Utiliser les primitives sync.Mutex ou sync.RWMutex pour protéger toutes les opérations de lecture et d'écriture.
• Ou utiliser le package sync.Map, qui est destiné aux scénarios concurrents à fort trafic.

var mu sync.RWMutex
m := make(map[string]int)

// Écriture
mu.Lock()
m["key"] = 1
mu.Unlock()

// Lecture
mu.RLock()
v := m["key"]
mu.RUnlock()

// Ou sync.Map
var sm sync.Map
sm.Store("key", 1)
v, _ := sm.Load("key")

Question piège

Pourquoi la lecture et l'écriture simultanées à partir de différentes goroutines dans une map en Go sont-elles si dangereuses, alors que la map est un type intégré ?

Réponse : En Go, le type intégré map ne fournit pas de synchronisation. Un accès simultané à la map depuis plusieurs goroutines ne conduit pas seulement à des valeurs incorrectes, mais peut également provoquer un crash du programme. Même les lectures et écritures simultanées (lorsqu'il n'y a pas de clés en conflit !) peuvent entraîner des erreurs fatales. Cela diffère de certains autres langages où les collections sont "tolérantes" aux accès concurrents.

Exemples d'erreurs réelles dues à une méconnaissance des subtilités du sujet

---

Histoire

Dans un projet réel, un développeur a utilisé une map globale pour mettre en cache des données. Le service fonctionnait de manière stable lors des tests, mais a commencé à rencontrer des erreurs fatal error: concurrent map read and map write lors des tests de charge et en production. La cause était l'accès parallèle à la map depuis différentes requêtes http sans utiliser de Mutex.

---

Histoire

Dans une application web Go, un programmeur a décidé d'améliorer la performance en utilisant une map ordinaire comme pool de connexions, supposant que la multithreading serait gérée par le framework. Lors d'une forte augmentation du trafic, le service a commencé à s'arrêter sans raison évidente : en raison de la condition de course, les données dans la map étaient corrompues et des paniques se produisaient.

---

Histoire

Dans un service interne, l'application Go utilisait une map pour collecter des statistiques "en temps réel", pensant que la majorité des accès ne concernait que l'écriture. En réalité, une autre partie du code interrogeait périodiquement les données pour générer des rapports, ce qui entraînait des arrêts difficiles à détecter une fois par jour - juste au moment où les statistiques étaient activées. L'analyse a montré que les lectures et écritures se chevauchaient sans aucune protection.