如何在 Go 中实现一个高性能的固定长度字节对象池-Golang-PHP中文网

sync.Pool直接用于固定长度字节切片易出问题，因Pool不感知类型与cap，取回切片若未重置len=0或未校验cap，会导致数据残留、越界覆盖或池污染；不同长度切片混用同一池还会引发内存浪费与泄漏。

为什么 `sync.Pool` 直接用在固定长度字节切片上容易出问题

go 的 sync.pool 本身不感知类型，也不限制对象大小或结构；你往里放 []byte，它就原样存着，但不会帮你复用底层 cap 匹配的底层数组。常见错误是：从池中取回一个 []byte，len 是 0，但 cap 很大，结果后续 append 导致意外覆盖旧数据，或者误以为能直接当缓冲区用而没清零。

更隐蔽的问题是：不同长度的切片混入同一个池，会导致内存浪费甚至泄漏——比如你只想要 1024 字节的缓冲区，却从池里拿到一个 cap=4096 的切片，又没重置 len，下次别人取走时可能看到残留数据。

必须确保每次 Get 后都做 buf = buf[:0] 或显式 copy 覆盖
Put 前要检查 cap 是否符合预期，否则丢进去会污染池
不要把不同用途/长度的 []byte 放进同一个 sync.Pool

用 `sync.Pool` + 预分配底层数组实现固定长度池

核心思路是：池中只存 *[]byte（即指向底层数组的指针），每次 Get 返回的是新切片头，指向同一块已分配的内存；Put 时只归还切片头，不释放底层数组。这样避免反复 malloc/free，也杜绝了 cap 不一致问题。

示例：实现一个 1024 字节的池：

var bytePool1K = sync.Pool{
	New: func() interface{} {
		buf := make([]byte, 1024)
		return &buf // 存指针，不是切片值
	},
}

func Get1K() []byte {
	p := bytePool1K.Get().(*[]byte)
	return (*p)[:1024] // 每次返回确定长度的切片
}

func Put1K(buf []byte) {
	if cap(buf) != 1024 {
		return // 长度不对，不放回，防止污染
	}
	p := &buf
	bytePool1K.Put(p)
}

注意 New 返回 *[]byte，不是 []byte
Get1K 必须用 [:1024] 截取，不能直接用 *p（那是 0-len 的）
Put1K 中检查 cap(buf) 是关键防线，漏掉就会让错误长度切片污染池

多个固定长度共用一个池？别这么做

有人想用 map[string]*sync.Pool 或泛型封装来支持多种长度，但实际中这反而降低性能且增加 GC 压力。Go 1.21+ 虽支持泛型池，但 sync.Pool 的内部哈希逻辑对不同类型是隔离的，你声明 sync.Pool[[]byte] 和 sync.Pool[[1024]byte] 是两个完全不同的池实例，无法共享。

更现实的选择是：按真实热点长度单独建池，比如：