Historique de la question. La map de Go est implémentée comme une table de hachage avec des seaux extensibles. Lorsque le facteur de charge dépasse un seuil, le runtime initie une phase de croissance où les entrées sont re-hachées et redistribuées dans de nouveaux tableaux de seaux plus grands.
Le problème. Si le langage permettait des expressions comme &m["key"], le pointeur résultant référencerait un emplacement mémoire spécifique au sein d'un seau de hachage. Lors de la croissance de la map, les entrées sont copiées dans de nouveaux seaux et les anciens seaux sont libérés, rendant tout pointeur existant flottant et dangereux.
La solution. La spécification Go interdit explicitement de prendre l'adresse d'une expression d'index de map. Le compilateur traite &m[k] comme une opération invalide, garantissant qu'aucun programme ne peut détenir des pointeurs vers les internals de la map. Cela permet au runtime de déplacer librement les entrées lors de la croissance ou de la réduction sans gérer les mises à jour des pointeurs ou leur invalidation.
Description du problème. Dans un service de télémétrie à haut débit, les ingénieurs devaient mettre à jour un champ compteur dans une grande struct de configuration stockée dans une map de cache en mémoire. Les tentatives initiales ont utilisé cfg := &configMap[deviceID]; cfg.Counter++, ce qui a échoué à se compiler avec l'erreur "impossible de prendre l'adresse d'un élément de la map". Ce modèle était courant dans les bases de code C++ dont l'équipe avait migré, où les itérateurs std::map restent stables.
Solution 1 : Stocker des pointeurs dans la map. Changer le type de la map de map[string]Config à map[string]*Config. Cela permet de récupérer le pointeur et de modifier la struct sous-jacente directement sans réaffectation. Les avantages incluent la possibilité de modification directe et l'évitement de la copie de la struct, tandis que les inconvénients incluent l'augmentation des allocations sur le tas, la réduction de la localité du cache et la nécessité de vérifications de nil.
Solution 2 : Copier-modifier-réaffecter. Récupérer la valeur dans une variable locale, la modifier et la réécrire en utilisant cfg := configMap[deviceID]; cfg.Counter++; configMap[deviceID] = cfg. Les avantages incluent le travail avec des types de valeur et aucune allocation supplémentaire, tandis que les inconvénients incluent le coût de performance de la copie de grandes structs à chaque mise à jour.
Solution 3 : Utiliser un sync.RWMutex avec un wrapper de struct. Protéger la map avec un mutex pour permettre des cycles de lecture-modification-écriture en toute sécurité dans des environnements concurrents. Les avantages incluent une synchronisation explicite pour l'accès concurrent, tandis que les inconvénients incluent une contention potentielle sur les verrous et la nécessité continue de réaffectation.
Solution choisie et résultat. Pour de petites structs (<64 octets), la Solution 2 a été adoptée pour sa simplicité et ses propriétés sans allocation. Pour de grandes structs fréquemment mises à jour, la Solution 1 a été utilisée avec une allocation de pool pour atténuer la pression du GC. Le système a atteint des performances stables sans avoir recours à des hacks de pointeur non sûrs.
Pourquoi puis-je prendre l'adresse d'un élément de slice mais pas d'un élément de map ?
Prendre l'adresse d'un élément de slice &s[i] est valide parce que le tableau de base d'un slice a une adresse mémoire stable, sauf si le slice est réalloué (par exemple, via append dépassant la capacité). Le pointeur reste valide tant que le tableau sous-jacent n'est pas réalloué. En revanche, les seaux de map sont régulièrement déplacés lors des opérations de croissance. Si les adresses des éléments de map étaient autorisées, elles deviendraient des pointeurs flottants après re-hachage, violant la sécurité mémoire.
L'utilisation d'une map de pointeurs permet-elle de modifier les données stockées sans réaffectation ?
Bien que vous ne puissiez pas prendre l'adresse de l'emplacement du pointeur lui-même (&m[key] est invalide même pour map[K]*V), vous pouvez copier la valeur du pointeur et la déréférencer : p := m[key]; p.Field = newVal. Cela fonctionne parce que vous modifiez la struct allouée sur le tas via une copie du pointeur, pas le stockage interne de la map. La distinction est subtile : la map stocke la valeur du pointeur (une adresse), et bien que cette valeur d'adresse ne puisse pas être adressée directement, elle peut être lue et utilisée pour accéder à l'objet du tas.
Comment la croissance de la map fonctionnerait-elle si les adresses des éléments étaient permises ?
Si le langage permettait &m[key], le runtime devrait garantir la stabilité des pointeurs lors de la migration des seaux. Cela nécessiterait soit une redirection (stockage de pointeurs vers des entrées dans des seaux, doublant la surcharge des pointeurs), jamais de libérer d'anciens seaux (fuite de mémoire), ou de mettre en œuvre une barrière de lecture pour mettre à jour les pointeurs lors de la relocalisation (coût de performance significatif). La conception actuelle est optimisée pour le cas courant des opérations de map en sacrifiant la possibilité de prendre les adresses des éléments, évitant ainsi ces surcharges.