为何最终我放弃了 Go 的 sync.Pool

3.1、标准库中的应用

Go 语言标准库大量使用了 sync.Pool，例如 fmt 和 encoding/json。以下是 fmt.Printf 的源代码片段：

// go 1.13.6
// pp is used to store a printer's state and is reused with sync.Pool to avoid allocations.
type pp struct {
	buf buffer
	...
}

var ppFree = sync.Pool{
	New: func() interface{} {
		return new(pp)
	},
}

func newPrinter() *pp {
	p := ppFree.Get().(*pp)
	p.panicking = false
	p.erroring = false
	p.wrapErrs = false
	p.fmt.init(&p.buf)
	return p
}

func (p *pp) free() {
	if cap(p.buf) > 64<<10 {
		return
	}
	p.buf = p.buf[:0]
	p.arg = nil
	p.value = reflect.Value{}
	p.wrappedErr = nil
	tpFree.Put(p)
}

func Fprintf(w io.Writer, format string, a ...interface{}) (n int, err error) {
	p := newPrinter()
	p.doPrintf(format, a)
	n, err = w.Write(p.buf)
	p.free()
	return
}

func Printf(format string, a ...interface{}) (n int, err error) {
	return Fprintf(os.Stdout, format, a...)
}

fmt.Printf 的调用是非常频繁的，利用 sync.Pool 复用 pp 对象能够极大地提升性能，减少内存占用，同时降低 GC 压力。

3.2、Gin 框架的应用 (context)

在 Gin 框架中，Context 对象代表了处理一个 HTTP 请求的上下文。每个请求都需要一个 Context，请求处理完毕，Context 的生命周期也就结束了。

• 高频的创建于销毁：在高并发下，每秒会创建和销毁大量 Context 对象。
• 固定生命周期：Context 的生命周期始于请求到来，止于请求处理完毕，非常短暂。

3.2.1、定义对象池

在 gin.Engine 结构体的定义中，pool 字段就是一个 sync.Pool。

type Engine struct {
	// ...
	pool sync.Pool // context 对象池
}

3.2.2、初始化对象池

在创建 Gin 引擎实例的时候，会初始化 sync.Pool，并指定 New 函数。当池子中无对象可用的时候，会调用此函数创建新的 Context。

func New() *Engine {
	// ...
	engine.pool.New = func() any {
		return engine.allocateContext(engine.maxParams)
	}
	return engine
}

func (engine *Engine) allocateContext(maxParams uint16) *Context {
	v := make(Params, 0, maxParams)
	return &Context{engine: engine, params: &v, skippedNodes: &skippedNodes}
}

3.2.3、从池中获取 Context

当 HTTP 请求到达时，Gin 会从 sync.Pool 中获取一个 Context 对象。

func (engine *Engine) ServeHTTP(w http.ResponseWriter, req *http.Request) {
	c := engine.pool.Get().(*Context)
	c.writermem.reset(w)
	c.Request = req
	c.reset()
	// ...
	handleHTTPRequest(c)
	engine.pool.Put(c)
}

3.2.4、处理请求后放回池中

请求处理完毕后，Gin 会将 Context 重置并放回 sync.Pool 中，以供后面复用。

切记，重点是要重置的，如调用 c.reset()。确保放回的是干净的上下文。

四、我在项目中的实战

4.1、为何最初选择 sync.Pool

我的目的是设计了一个支持多存储驱动的图片上传模块，重点解决了并发性能、资源管理和动态切换的问题。

为了解决所谓的高并发，复用实例的问题，我就自然的想到去使用 sync.Pool，但问题来了！

1. 对象复用：避免频繁创建和销毁对象
2. 并发安全：多个用户可同时使用不同驱动

为此，我还描绘了一个草图：

// 多驱动对象池管理器
type MultiDriverPool struct {
	pools map[string]ObjectPool
	mu    sync.RWMutex
	current string // 当前默认驱动
}

// 对象池接口
type ObjectPool interface {
	Get() (Driver, error)
	Put(Driver) error
	Close()
	Size() int
	Available() int
}

4.2、又为何选择放弃 sync.Pool

4.2.1、存储驱动通常是无状态的

比如七牛云驱动使用相同的 AccessKey 和 SecretKey，每个实例都执行相同的操作，没有必要维护多个实例。实际上，一个驱动实例就可以处理所有请求，而且通常驱动本身是线程安全的（或者可以通过在方法内部分配资源来做到线程安全）。

换句话说就是：认为每个驱动实例需要频繁创建和销毁，但实际上驱动实例是可以复用的，而且创建成本不高，并且'存储驱动是无状态的'！

所以我最终的设计模式是：单例 + 多驱动模式。

五、总结

适合 sync.Pool 的场景：

• 创建成本高 对象初始化有显著开销
• 生命周期短 使用后很快就不再需要
• 使用频率高 大量并发创建销毁
• 可安全重置 能完全清理之前的状态

不适合：

// 1、存储驱动 - 创建成本低，生命周期长
var driverPool = sync.Pool{
	New: func() interface{} {
		return &QiniuDriver{}
	},
}
// 2、数据库连接 - 需要连接池，不是对象池
var dbPool = sync.Pool{
	New: func() interface{} {
		return sql.Open(...)
	},
}
// 3、配置对象 - 长期存在，不需要频繁创建
var configPool = sync.Pool{
	New: func() interface{} {
		return loadConfig()
	},
}

sync.Pool 的核心作用，不是资源管理。而是通过保存和复用临时对象，减少内存分配，降低 GC 压力！

六、sync.Pool 的底层剖析

6.1 底层结构体

type Pool struct {
	noCopy noCopy
	local  unsafe.Pointer // 每个 P 的本地固定大小池，实际类型是 [P]poolLocal
	localSize uintptr
	victim unsafe.Pointer // 上一个周期的本地池
	victimSize uintptr
	New      func() any
}

6.2 重点

在 Pool 的底层，核心有两点：分别是 local 与 victim。

6.2.1 local unsafe.Pointer

local 是一个按 P（GOMAXPROCS）分片的本地对象池。每个 P 都有自己的 poolLocal，无需锁，极快。Get / Put 操作优先访问本地池，不需要加锁。

6.2.2 victim

Go 认为 Pool 内的对象是可丢弃的，所以每次 GC 会清空 pool.local。为了避免冲击（比如刚清空就马上又需要大量对象），Go 引入了：上一 GC 周期的 pool.local 备份。避免 GC 后对象全部被清空导致性能抖动。

七、性能测试

7.1 测试主函数

type User struct {
	ID       int64  `json:"id"`
	Username string `json:"username"`
	Email    string `json:"email"`
	Profile  [512]byte `json:"profile_data"`
}

// 创建 User Pool
var userPool = sync.Pool{
	New: func() interface{} {
		atomic.AddUint64(&poolMisses, 1)
		return new(User)
	},
}

// 创建 Buffer Pool
var bufPool = sync.Pool{
	New: func() interface{} {
		return new(bytes.Buffer)
	},
}

// 调用 Get 的次数
var totalGets uint64

// 必须创建新对象的次数
var poolMisses uint64

// 获取一个 User
func getUser() *User {
	atomic.AddUint64(&totalGets, 1)
	return userPool.Get().(*User)
}

// 放回 User
func putUser(u *User) {
	// 1、清空数据
	u.ID = 0
	u.Username = ""
	u.Email = ""
	for i := range u.Profile {
		u.Profile[i] = 0
	}
	// 2、放回
	userPool.Put(u)
}

// 处理 User
func processUser(data []byte) *User {
	u := getUser()
	_ = json.Unmarshal(data, u)
	return u
}

// 处理 HTTP 请求
func handleProcess(w http.ResponseWriter, r *http.Request) {
	// 1、获取 Buffer
	var b bytes.Buffer
	// 2、获取 User
	_, _ = io.Copy(&b, r.Body)
	// 3、处理 User
	u := processUser(b.Bytes())
	defer putUser(u)
	// ...
}

func handleMetrics(w http.ResponseWriter, _ *http.Request) {
	hits := atomic.LoadUint64(&totalGets) - atomic.LoadUint64(&poolMisses)
	_, _ = w.Write([]byte("sync_pool_gets "+ strconv.FormatUint(atomic.LoadUint64(&totalGets), 10)+"\n"))
	_, _ = w.Write([]byte("sync_pool_misses "+ strconv.FormatUint(atomic.LoadUint64(&poolMisses), 10)+"\n"))
	_, _ = w.Write([]byte("sync_pool_hits "+ strconv.FormatUint(hits, 10)+"\n"))
}

func main() {
	http.HandleFunc("/process", handleProcess)
	http.HandleFunc("/metrics", handleMetrics)
	_ = http.ListenAndServe(":8080", nil)
}

7.2 对象的复用率

func TestHTTPConcurrent(t *testing.T) {
	data := []byte(`{"id":10,"username":"concurrent","email":"[email protected]"}`)
	req := httptest.NewRequest(http.MethodPost, "/process", bytes.NewBuffer(data))
	n := 500
	var wg sync.WaitGroup
	wg.Add(n)
	for i := 0; i < n; i++ {
		go func() {
			defer wg.Done()
			w := httptest.NewRecorder()
			handleProcess(w, req)
			if w.Code != http.StatusOK {
				t.Errorf("bad status")
			}
		}()
	}
	wg.Wait()
	t.Logf("totalGets=%d, poolMisses=%d", totalGets, poolMisses)
}

=== RUN TestHTTPConcurrent pool_test.go:65: totalGets=500（调用 get 的总次数），poolMisses=4（新 new 的次数） — PASS: TestHTTPConcurrent (0.00s) PASS

但若大家自己测，由于处于不同环境，结果应该会有些许波动。

7.3 对象复用性能测试

采用基准测试：用来测性能的测试，包括耗时、内存分配、GC 压力等。 b.N 是测试循环次数（Go 自动调整）。b.ReportAllocs()：显示内存分配次数。b.ResetTimer()：重置计时器（忽略前面初始化的耗时）。

// Benchmark - 无对象池
func BenchmarkWithoutPool(b *testing.B) {
	data := []byte(`{"id":123,"username":"user123","email":"[email protected]"}`)
	b.ReportAllocs()
	b.ResetTimer()
	for i := 0; i < b.N; i++ {
		u := &User{}
		_ = json.Unmarshal(data, u)
	}
}

// Benchmark - 对象池
func BenchmarkWithPool(b *testing.B) {
	data := []byte(`{"id":123,"username":"user123","email":"[email protected]"}`)
	b.ReportAllocs()
	b.ResetTimer()
	for i := 0; i < b.N; i++ {
		u := getUser()
		_ = json.Unmarshal(data, u)
		putUser(u)
	}
}

可以从 B/op（分配内存字节数），近 4 倍的差距，看出性能的差距。当然大家自测时，应该会出现偏差，要以 withoutPool 与 withPool 的差距作为对比标准。

八、自测

1. sync.Pool 的主要作用是什么？为什么它能减少 GC 压力？
2. sync.Pool.New 是在什么情况下被调用的？
3. 为什么从 pool 取出的对象必须重置（reset）？
4. 为什么在你的代码中，putUser() 必须把结构体所有字段清空？
5. 为什么结构体字段清空了却依旧要 Reset()？
6. sync.Pool 为什么不是普通的缓存？它有什么生命周期特性？