var m map[string]int
println(m["a"]) // 0
m["a"] = 1 // panic: assignment to entry in nil map
ログイン後にコピー
しかし、問題は、新しいキーと値のペアを nil マップに追加することはできないということです。
実際、Go はスライスを処理する方法とよく似た方法でマップを処理します。マップとスライスは両方とも nil として始まり、nil の間にそれらに対して「無害な」何かを行っても Go はパニックになりません。たとえば、「ドラマ」なしで nil スライスをループできます。
では、nil マップをループしようとするとどうなるでしょうか?
var m map[string]int
for k, v := range m {
println(k, v)
}
ログイン後にコピー
何も起こらず、エラーも、驚きもありません。ただ静かに何もしません。
Go のアプローチは、任意の型のデフォルト値を、プログラムのダウンを引き起こすものではなく、有用なものとして扱うことです。 Go がフィットをスローするのは、新しいキーと値のペアを nil マップに追加しようとしたり、スライス内の範囲外のインデックスにアクセスしたりするなど、本当に違法な操作を行った場合のみです。
func main() {
m := map[interface{}]int{
1: 1,
"a": 2,
}
m[[]int{1, 2, 3}] = 3
m[func() {}] = 4
}
// panic: runtime error: hash of unhashable type []int
// panic: runtime error: hash of unhashable type func()
ログイン後にコピー
Everything looks fine until you try to assign an uncomparable type as a map key.
That's when you'll hit a runtime error, which is trickier to deal with than a compile-time error. Because of this, it's usually a good idea to avoid using interface{} as a map key unless you have a solid reason and constraints that prevent misuse.
But that error message: "hash of unhashable type []int" might seem a bit cryptic. What's this about a hash? Well, that's our cue to dig into how Go handles things under the hood.
Map Anatomy
When explaining the internals of something like a map, it's easy to get bogged down in the nitty-gritty details of the Go source code. But we're going to keep it light and simple so even those new to Go can follow along.
What you see as a single map in your Go code is actually an abstraction that hides the complex details of how the data is organized. In reality, a Go map is composed of many smaller units called "buckets."
type hmap struct {
...
buckets unsafe.Pointer
...
}
ログイン後にコピー
Look at Go source code above, a map contains a pointer that points to the bucket array.
This is why when you assign a map to a variable or pass it to a function, both the variable and the function's argument are sharing the same map pointer.
But don't get it twisted, maps are pointers to the hmap under the hood, but they aren't reference types, nor are they passed by reference like a ref argument in C#, if you change the whole map m2, it won't reflect on the original map m1 in the caller.
In Go, everything is passed by value. What's really happening is a bit different: when you pass the map m1 to the changeMap function, Go makes a copy of the *hmap structure. So, m1 in the main() and m2 in the changeMap() function are technically different pointers point to the same hmap.
Map is passed by value
For more on this topic, there's a great post by Dave Cheney titled There is no pass-by-reference in Go.
Each of these buckets can only hold up to 8 key-value pairs, as you can see in the image below.
Buckets of a map
The map above has 2 buckets, and len(map) is 6.
So, when you add a key-value pair to a map, Go doesn't just drop it in there randomly or sequentially. Instead, it places the pair into one of these buckets based on the key's hash value, which is determined by hash(key, seed).
Let's see the simplest assignment scenario in the image below, when we have an empty map, and assign a key-value pair "hello": 1 to it.
Assign a key-value pair to an empty map
It starts by hashing "hello" to a number, then it takes that number and mods it by the number of buckets.
Since we only have one bucket here, any number mod 1 is 0, so it's going straight into bucket 0 and the same process happens when you add another key-value pair. It'll try to place it in bucket 0, and if the first slot's taken or has a different key, it'll move to the next slot in that bucket.
Take a look at the hash(key, seed), when you use a for-range loop over two maps with the same keys, you might notice that the keys come out in a different order:
func main() {
a := map[string]int{"a": 1, "b": 2, "c": 3, "d": 4, "e": 5, "f": 6}
b := map[string]int{"a": 1, "b": 2, "c": 3, "d": 4, "e": 5, "f": 6}
for i := range a {
print(i, " ")
}
println()
for i := range b {
print(i, " ")
}
}
// Output:
// a b c d e f
// c d e f a b
ログイン後にコピー
How's that possible? Isn't the key "a" in map a and the key "a" in map b hashed the same way?
But here's the deal, while the hash function used for maps in Go is consistent across all maps with the same key type, the seed used by that hash function is different for each map instance. So, when you create a new map, Go generates a random seed just for that map.
In the example above, both a and b use the same hash function because their keys are string types, but each map has its own unique seed.
"Wait, a bucket has only 8 slots? What happens if the bucket gets full? Does it grow like a slice?"
Well, sort of. When the buckets start getting full, or even almost full, depending on the algorithm's definition of "full", the map will trigger a growth, which might double the number of main buckets.
But here's where it gets a bit more interesting.
'주 버킷'이라고 하면 '오버플로 버킷'이라는 또 다른 개념을 설정하는 것입니다. 이는 충돌이 많은 상황에 처했을 때 적용됩니다. 4개의 버킷이 있는데 그 중 하나는 높은 충돌로 인해 8개의 키-값 쌍으로 완전히 채워지고 나머지 3개 버킷은 비어 있다고 상상해 보세요.
전체 게시물은 https://victoriametrics.com/blog/go-map/에서 볼 수 있습니다.
以上がGo Maps の説明: Key-Value ペアが実際にどのように保存されるかの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
