Risposta

In Go le mappe non sono thread-safe per impostazione predefinita. Se più goroutine scrivono o leggono contemporaneamente dalla stessa mappa senza sincronizzazione, si verificherà una condizione di corsa (data race), che porta a panic fatal error: concurrent map read and map write o corruzione dei dati.

Per lavorare in modo thread-safe con le mappe è necessario:

• Utilizzare i primitivi sync.Mutex o sync.RWMutex per proteggere tutte le operazioni di lettura e scrittura.
• Oppure utilizzare il pacchetto sync.Map, progettato per scenari concorrenti ad alto carico.

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

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

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

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

Domanda ingannevole

Perché la lettura e la scrittura simultanee da diverse goroutine nella mappa in Go sono così pericolose, se la mappa è un tipo incorporato?

Risposta: In Go il tipo incorporato mappa non fornisce sincronizzazione. L'accesso simultaneo a una mappa da parte di più goroutine non causa solo valori anomali, ma può portare al crash del programma. Anche la lettura e la scrittura simultanee (quando non ci sono chiavi sovrapposte!) possono causare un errore fatale. Questo è diverso rispetto ad altri linguaggi, dove le collezioni sono "tolleranti" agli accessi concorrenti.

Esempi di errori reali a causa della mancata comprensione delle sottigliezze dell'argomento

---

Storia

In un progetto reale, uno sviluppatore ha utilizzato una mappa globale per la memorizzazione nella cache dei dati. Il servizio funzionava stabilmente nei test, ma nei test di carico e in produzione ha iniziato a fallire con l'errore fatal error: concurrent map read and map write. La causa era l'accesso parallelo alla mappa da diverse richieste http senza l'uso di Mutex.

---

Storia

In un'applicazione web Go, uno sviluppatore ha cercato di migliorare le prestazioni e ha utilizzato una normale mappa come pool di connessioni, presupponendo che la multithreading fosse garantita dal framework. Con un'improvvisa crescita del traffico, il servizio ha iniziato a crollare senza una causa evidente: a causa della corsa, i dati nella mappa venivano danneggiati e si verificavano panico.

---

Storia

In un servizio interno, un'applicazione Go utilizzava una mappa per raccogliere statistiche "al volo", pensando che l'accesso principale fosse solo in scrittura. In realtà, un'altra parte del codice richiedeva periodicamente dati per la generazione di report, il che portava a crash difficili da individuare che si verificavano solo una volta al giorno — proprio quando venivano attivate le statistiche. L'analisi ha dimostrato che le letture e le scritture si sovrapponevano senza alcun blocco.