質問の歴史。 Goのマップは、成長可能なバケットを持つハッシュテーブルとして実装されています。ロードファクタがしきい値を超えると、ランタイムは成長フェーズを開始し、エントリを再ハッシュして新しい大きなバケット配列に再分配します。
問題点。 もし言語が&m["key"]のような式を許可すると、結果のポインタはハッシュバケット内の特定のメモリ位置を参照することになります。マップが成長する際に、エントリは新しいバケットにコピーされ、古いバケットは解放されるため、既存のポインタはダングリングになり、安全ではなくなります。
解決策。 Goの仕様は、マップインデックス式のアドレスを取得することを明示的に禁止しています。コンパイラは&m[k]を無効な操作として扱い、プログラムがマップ内部へのポインタを保持できないようにします。これにより、ランタイムは成長や縮小中にエントリを自由に移動でき、ポインタの更新や無効化を管理する必要がなくなります。
問題の説明。 高スループットのテレメトリーサービスで、エンジニアはメモリ内キャッシュマップに保存された大きな構成構造体内のカウンタフィールドを更新する必要がありました。最初の試みでcfg := &configMap[deviceID]; cfg.Counter++を使用したところ、コンパイルに失敗し、エラー*"マップ要素のアドレスを取得できません"*が表示されました。このパターンは、チームが移行したC++コードベースで一般的でしたが、そこではstd::mapのイテレータは安定していました。
解決策1：マップにポインタを格納。 マップの型をmap[string]Configからmap[string]*Configに変更します。これにより、ポインタを取得し、再代入なしで基礎構造体を直接変更することができます。利点には直接の変更が可能で、構造体のコピーを回避できることが含まれ、欠点にはヒープ割り当ての増加、キャッシュローカリティの低下、nilチェックの必要性が含まれます。
解決策2：コピーして修正し再代入。 値をローカル変数に取得し、修正してからcfg := configMap[deviceID]; cfg.Counter++; configMap[deviceID] = cfgを使って書き戻します。利点は値型で作業でき、追加の割り当てがゼロであることですが、欠点は毎回の更新で大きな構造体をコピーするオーバーヘッドがあります。
解決策3：structラッパーを持つsync.RWMutexを使用。 マップをミューテックスで保護し、同時実行環境で安全な読み取り-修正-書き込みサイクルを可能にします。利点には同時アクセスのための明示的な同期があり、欠点にはロックの争奪競争の潜在的な影響と再代入の必要が残ることが含まれます。
選択された解決策と結果。 小さな構造体（<64バイト）には、単純さとゼロ割り当ての特性のために解決策2が採用されました。大きく頻繁に更新される構造体には解決策1が使用され、プール割り当てでGCの圧力を軽減しました。システムは安全なポインタハックに依存せず、安定した性能を達成しました。
なぜスライス要素のアドレスを取得できるのに、マップ要素のアドレスは取得できないのですか？
スライス要素&s[i]のアドレスを取得することは有効です。なぜなら、スライスのバックエンド配列は、スライスが再割り当てされない限り、安定したメモリアドレスを持つからです（例えば、appendが容量を超えた場合など）。基礎となる配列が再割り当てされない限り、ポインタは有効です。それに対して、マップバケットは成長操作中に定期的に移動されます。もしマップ要素のアドレスが許可されていた場合、再ハッシュ後にそれらはダングリングポインタになり、メモリ安全が損なわれます。
ポインタのマップを使用すると、再代入なしで格納されたデータを変更できますか？
ポインタスロット自体のアドレスを取得することはできません（&m[key]はmap[K]*Vに対しても無効）、ただしポインタ値を取得して逆参照することはできます：p := m[key]; p.Field = newVal。これは、ポインタのコピーを通じてヒープに割り当てられた構造体を修正しているため機能します。地図内部のストレージを直接変更しているわけではありません。この違いは微妙ですが、マップはポインタ値（アドレス）を格納し、アドレス値自体は直接アドレス指定できませんが、読み取ってヒープオブジェクトにアクセスするために使用できます。
要素のアドレスが許可されている場合、マップの成長はどのように機能するでしょうか？
もし言語が&m[key]を許可していた場合、ランタイムはバケットの移行中にポインタの安定性を確保する必要があります。これには、ポインタのオーバーヘッドを倍増させるために、バケット内のエントリへのポインタを保存する間接参照、古いバケットを決して解放しないこと（メモリリーク）、または移動中にポインタを更新するための読み取りバリアの実装（大きな性能コスト）が必要になります。現在の設計は、要素のアドレスを取得する能力を犠牲にして、マップ操作の一般的なケースを最適化し、これらのオーバーヘッドを回避しています。