Go maphash.Hash 怎么避免每次重新分配缓冲区

批量给字符串或复合键计算哈希时，最容易误判的一点是：每次写入并不等于都要重新分配一个缓冲区。maphash.Hash 本身带有固定的内部缓冲，重复使用时应调用 Reset 清掉上一次的数据；如果输入只有一个字符串或字节切片，则直接使用 maphash.String 或 maphash.Bytes，连 Hash 对象都不必显式创建。

官方资料：https://pkg.go.dev/hash/maphash

先弄清 maphash.Hash 到底分配了什么

官方实现中的 Hash 结构包含一个 128 字节的数组缓冲和当前未刷入状态的长度。短输入会先复制进这个数组，Sum64 读取当前内容；Reset 将状态恢复到原 seed，并把未使用字节数归零。它不是把每次输入追加到一个不断增长的 []byte 中。

因此，看到分配数上升时，优先检查外层代码：是否把字符串转换成了新的字节切片，是否把 *Hash 交给了接口，或者是否在循环中拼接了复合键。仅仅把 var h maphash.Hash 写在循环体里，并不能直接证明发生了堆分配；是否逃逸要以编译器分析为准。

单输入场景不要绕一圈创建 Hash

只有一个字符串或字节切片时，带 seed 的便捷函数就是更合适的候选。它们表达的是“用这个 seed 计算这一份输入”，不会让调用方维护可复用对象：

package main

import "hash/maphash"

func hashKeys(seed maphash.Seed, keys []string) []uint64 {
	result := make([]uint64, len(keys))
	for i, key := range keys {
		// 单个字符串直接哈希，避免先转换成 []byte 再交给 Hash。
		result[i] = maphash.String(seed, key)
	}
	return result
}

func hashBytes(seed maphash.Seed, payloads [][]byte) []uint64 {
	result := make([]uint64, len(payloads))
	for i, payload := range payloads {
		// Bytes 不会修改输入切片，适合已经存在的字节数据。
		result[i] = maphash.Bytes(seed, payload)
	}
	return result
}

这两种写法的分配主要来自返回的 result，而不是每次哈希都由调用方新建一个缓冲。若只需要一个 uint64，可以把结果直接用于桶索引、布隆过滤器或哈希表定位。

组合字段时复用同一个 Hash

当 key 由租户、资源类型和资源编号组成时，不建议先用 fmt.Sprintf 或多次 append 拼成临时字符串。为一个工作协程保存一个 Hash，每次开始前 Reset，再按稳定顺序写入字段：

type KeyHasher struct {
	seed maphash.Seed
	h    maphash.Hash
}

func NewKeyHasher(seed maphash.Seed) *KeyHasher {
	var h maphash.Hash
	h.SetSeed(seed)
	return &KeyHasher{seed: seed, h: h}
}

func (k *KeyHasher) Sum(tenant, resource string, id uint64) uint64 {
	// Reset 保留 seed，只丢弃上一条 key 的字节序列。
	k.h.Reset()
	k.h.WriteString(tenant)
	k.h.WriteByte(0) // 分隔字段，避免边界拼接产生歧义。
	k.h.WriteString(resource)
	k.h.WriteByte(0)
	maphash.WriteComparable(&k.h, id)
	return k.h.Sum64()
}

这个对象不能被多个 goroutine 同时调用。并发处理时共享同一个 Seed，每个 goroutine 创建或持有自己的 KeyHasher；不要把一个可变的 Hash 放进全局共享结构后再用锁外访问。

什么时候才需要 sync.Pool

如果直接持有的 Hash 已经能留在栈上，加入对象池反而会增加生命周期管理和并发复用的复杂度。只有当基准或逃逸分析显示它因为接口调用、闭包或长期保存而进入堆，并且调用频率足够高，才值得比较对象池方案：

var hasherPool = sync.Pool{
	New: func() any {
		// 池中对象只保存可复用的 Hash；seed 由业务统一设置。
		return new(maphash.Hash)
	},
}

func pooledHash(seed maphash.Seed, text string) uint64 {
	h := hasherPool.Get().(*maphash.Hash)
	defer hasherPool.Put(h)
	// SetSeed 会同时清掉旧数据，适合池对象交接时重新绑定 seed。
	h.SetSeed(seed)
	h.WriteString(text)
	return h.Sum64()
}

先用 go test -bench . -benchmem 对比 maphash.String、复用 Hash 和池化版本的 allocs/op。没有实际逃逸证据时，优先保持代码简单。

相关问题

Reset 会重新生成 seed 吗？

不会。Reset 丢弃已写入的字节并保留原 seed；如果调用 SetSeed，则会改用传入的 seed 并清空旧数据。

多个 goroutine 能共享一个 maphash.Hash 吗？

不能。Hash 不是并发安全类型；可以共享一个 Seed，再让每个 goroutine 持有自己的 Hash。

为什么用了 Reset 仍然看到 allocs/op？

检查字符串到字节的转换、复合 key 拼接、接口参数和返回值是否逃逸。先比较直接的 String/Bytes，再用编译器逃逸报告定位真正的分配来源。