Storia della domanda. La mappa di Go è implementata come una tabella hash con bucket crescibili. Quando il fattore di carico supera una soglia, il runtime avvia una fase di crescita in cui le voci vengono rehashed e redistribute in nuovi array di bucket più grandi.
Il problema. Se il linguaggio consentisse espressioni come &m["key"], il puntatore risultante farebbe riferimento a una specifica posizione di memoria all'interno di un bucket hash. Durante la crescita della mappa, le voci vengono copiate in nuovi bucket e i vecchi bucket vengono liberati, rendendo eventuali puntatori esistenti pendenti e non sicuri.
La soluzione. La specifica di Go proibisce esplicitamente di prendere l'indirizzo di un'espressione di indice della mappa. Il compilatore tratta &m[k] come un'operazione non valida, garantendo che nessun programma possa mantenere puntatori agli interni della mappa. Ciò consente al runtime di riposizionare liberamente le voci durante la crescita o la riduzione senza dover gestire aggiornamenti o invalidazioni dei puntatori.
Descrizione del problema. In un servizio di telemetria ad alta capacità, gli ingegneri avevano bisogno di aggiornare un campo contatore all'interno di una grande struttura di configurazione memorizzata in una mappa di cache in memoria. I tentativi iniziali utilizzavano cfg := &configMap[deviceID]; cfg.Counter++, che non compilava con l'errore "impossibile prendere l'indirizzo dell'elemento della mappa". Questo schema era comune nei repository di codice C++ da cui il team si era migrato, dove gli iteratori di std::map rimangono stabili.
Soluzione 1: Memorizzare puntatori nella mappa. Cambiare il tipo di mappa da map[string]Config a map[string]*Config. Ciò consente di recuperare il puntatore e modificare direttamente la struttura sottostante senza riassegnazione. I pro includono la modifica diretta e l'evitamento della copia della struttura, mentre i contro includono l'aumento delle allocazioni heap, la riduzione della località della cache e la necessità di controlli null.
Soluzione 2: Copia-modifica-riassegna. Recuperare il valore in una variabile locale, modificarlo e riscriverlo utilizzando cfg := configMap[deviceID]; cfg.Counter++; configMap[deviceID] = cfg. I pro includono il lavoro con tipi valore e zero allocazioni aggiuntive, mentre i contro includono il sovraccarico delle prestazioni di copia di grandi strutture a ogni aggiornamento.
Soluzione 3: Usare un sync.RWMutex con un wrapper di struttura. Proteggere la mappa con un mutex per consentire cicli di lettura-modifica-scrittura sicuri in ambienti concorrenti. I pro includono la sincronizzazione esplicita per l'accesso concorrente, mentre i contro includono la potenziale contesa del lock e la continua necessità di riassegnazione.
Soluzione scelta e risultato. Per piccole strutture (<64 byte), è stata adottata la Soluzione 2 per la sua semplicità e proprietà senza allocazione. Per strutture grandi e frequentemente aggiornate, è stata utilizzata la Soluzione 1 con allocazione in pool per mitigare la pressione del GC. Il sistema ha raggiunto prestazioni stabili senza fare affidamento su hack di puntatori non sicuri.
Perché posso prendere l'indirizzo di un elemento di slice ma non di un elemento di mappa?
Prendere l'indirizzo di un elemento di slice &s[i] è valido perché l'array di supporto di uno slice ha un indirizzo di memoria stabile a meno che lo slice non venga riallocato (ad esempio, tramite append che supera la capacità). Il puntatore rimane valido finché l'array sottostante non viene riallocato. Al contrario, i bucket della mappa vengono rutinariamente riposizionati durante le operazioni di crescita. Se gli indirizzi degli elementi della mappa fossero consentiti, diventerebbero puntatori pendenti dopo il rehashing, violando la sicurezza della memoria.
L'uso di una mappa di puntatori consente di modificare i dati memorizzati senza riassegnazione?
Sebbene non sia possibile prendere l'indirizzo dello slot del puntatore stesso (&m[key] è non valido anche per map[K]*V), è possibile copiare il valore del puntatore e dereferenziarlo: p := m[key]; p.Field = newVal. Questo funziona perché si sta modificando la struttura allocata in heap tramite una copia del puntatore, non l'archiviazione interna della mappa. La distinzione è sottile: la mappa memorizza il valore del puntatore (un indirizzo), e mentre quel valore di indirizzo non può essere indirizzato direttamente, può essere letto e utilizzato per accedere all'oggetto heap.
Come funzionerebbe la crescita della mappa se fossero consentiti gli indirizzi degli elementi?
Se il linguaggio consentisse &m[key], il runtime dovrebbe garantire la stabilità dei puntatori durante la migrazione dei bucket. Questo richiederebbe indirection (memorizzare puntatori a voci nei bucket, raddoppiando il sovraccarico dei puntatori), non liberare mai i vecchi bucket (perdita di memoria) o implementare una barriera di lettura per aggiornare i puntatori durante il riposizionamento (costo di prestazione significativo). L'attuale design ottimizza il caso comune delle operazioni con la mappa sacrificando la possibilità di prendere indirizzi degli elementi, evitando questi sovraccarichi.