Go png.Encoder 怎么复用 BufferPool 减少批量编码分配

把实现了 png.EncoderBufferPool 的池赋给 png.Encoder.BufferPool，即可让多次 PNG 编码复用内部临时缓冲状态。池需要提供返回 *png.EncoderBuffer 的 Get 和接收该指针的 Put；用 sync.Pool 做适配是一种简单方式。它复用的是编码工作区，不是最终 PNG 字节，也不能保证每次编码都零分配或更快。

官方地址：https://pkg.go.dev/image/png

基线数据：先明确要测什么

假设一个批处理任务连续编码许多图片，输出交给下游存储。尚未接入池时，可把不设置 BufferPool 的 Encoder 作为基线，观察每次操作耗时、分配字节数和分配次数。本文没有执行本地基准，不提供实测数值；这里给出可重复的对照方法，让结果来自读者实际使用的工具链和图像样本。

测量前先固定输入尺寸、图像类型、像素内容和输出目标。否则两组任务如果一组编码小图、另一组写入较慢的存储，最后的差异就无法归因到缓冲复用。图片创建和读取也应放在计时区域外，避免把输入准备成本算成编码成本。

优化假设：复用工作区，而非缓存成品

Encoder 的 BufferPool 是内部工作区入口。调用者把池配置好后，编码器负责在需要时借出状态，并在使用结束时归还。不要在业务层手动借一个对象、随后又让 Encoder 自己借一次；更不要把同一个指针同时交给两个正在编码的任务。

在当前官方实现中，借不到对象时可以建立新的状态；借用建立后，归还被放在 defer 中。因此池为空是正常情形，不能让 Get 因为没有历史对象而阻塞等待。图片输入、编码工作区和输出 io.Writer 是三类独立对象，池化其中一类不会自动复用另外两类。

改动点：实现一个专用的池适配器

下面把 sync.Pool 封装起来，只允许存放 PNG 编码缓冲指针。零值适配器即可使用：第一次取不到对象时新建，后续有机会复用。这个类型使用后应继续通过指针共享，不要复制包含 sync.Pool 的结构体。

package pngbatch

import (
    "fmt"
    "image"
    "image/png"
    "io"
    "sync"
)

type BufferPool struct {
    pool sync.Pool
}

// 编译期表达接口关系，不改变运行时池的行为。
var _ png.EncoderBufferPool = (*BufferPool)(nil)

func (p *BufferPool) Get() *png.EncoderBuffer {
    if value := p.pool.Get(); value != nil {
        return value.(*png.EncoderBuffer)
    }
    // 缓存为空时立即提供新的工作区。
    return new(png.EncoderBuffer)
}

func (p *BufferPool) Put(buffer *png.EncoderBuffer) {
    if buffer != nil {
        p.pool.Put(buffer)
    }
}

func EncodeBatch(writers []io.Writer, images []image.Image, pool *BufferPool) error {
    if len(writers) != len(images) {
        return fmt.Errorf("写入器与图片数量不一致")
    }
    // 同一次批量任务使用同一个池，不在循环内重建。
    enc := png.Encoder{BufferPool: pool}
    for i, img := range images {
        if img == nil || writers[i] == nil {
            return fmt.Errorf("第 %d 项缺少图片或写入器", i)
        }
        if err := enc.Encode(writers[i], img); err != nil {
            return fmt.Errorf("编码第 %d 项: %w", i, err)
        }
    }
    // 写入器由调用方持有，文件关闭也由调用方负责。
    return nil
}

调用方应传入一个非 nil 的 *BufferPool，例如通过 new(BufferPool) 创建，并让相邻批次也复用它。这里的参数是具体池指针，因此不要把 nil 当作“禁用池”的写法；如果需要无池基线，直接构造未设置 BufferPool 的 Encoder，正如下节示例所示。

示例不替调用者关闭文件或网络响应。编码器返回成功，只表示本次编码写入没有报告错误；持有输出资源的一方仍要处理自己的关闭、刷新和提交逻辑。若 Encode 返回错误，应报告实际失败，池的归还机制不会把不完整输出变成有效 PNG。

压测方法：只改变是否设置 BufferPool

把下面的基准保存为同一包中的 pool_test.go。它使用预先准备的图像和 io.Discard，目的是减少存储干扰，观察编码本身的分配；它不是完整业务吞吐量测试。

package pngbatch

import (
    "image"
    "image/png"
    "io"
    "testing"
)

func BenchmarkPNGBufferPool(b *testing.B) {
    // 计时前创建固定输入，两组使用相同图像。
    img := image.NewRGBA(image.Rect(0, 0, 640, 360))
    for _, usePool := range []bool{false, true} {
        name := "WithoutPool"
        if usePool {
            name = "WithPool"
        }
        b.Run(name, func(b *testing.B) {
            enc := png.Encoder{}
            if usePool {
                enc.BufferPool = new(BufferPool)
            }
            b.ReportAllocs()
            b.ResetTimer()
            for i := 0; i 

# 在已准备好的模块包中运行多轮基准，保留分配指标。
go test -run '^$' -bench '^BenchmarkPNGBufferPool$' -benchmem -count 5

固定图像适合先检查实验结构，但透明、单一内容图片不能代表全部素材。正式评估应加入实际业务中的不同尺寸、颜色模型和像素分布，同时保持两组输入一致。不要在每个计时迭代里主动清空池；如果要研究冷启动，应另建冷启动实验，不与连续批量编码混在一起。

结果对比：让指标回答是否值得保留

如果分配下降而耗时基本不变，可以把收益表述为“减少临时分配压力”，不要扩大成吞吐量翻倍。若结果波动明显，应增加样本并检查背景负载。若只编码一次，池初始化与管理未必能摊薄；对于持续批量任务，复用假设才更值得检验。

边界条件：并发安全与内存保留

sync.Pool 支持多个 goroutine 使用，不代表池中的单个 EncoderBuffer 可以并发使用。自定义池必须保证借出的对象在归还前不再次发给其他调用；业务也不能在 Put 后继续访问该对象。并发任务可以各自创建 Encoder 并共享同一个池，同时使用独立的输出写入器，且输入图像在编码期间保持不变。

池内对象可能被运行时移除，不能依赖固定命中率，也不能把 sync.Pool 当作有确定容量的对象仓库。较大的工作区可能带来额外保留成本；EncoderBuffer 的内部字段没有提供给业务逐一裁剪的公共接口，因此应从负载分组、池寿命和并发规模考虑内存，而不是尝试修改私有字段。

常见问题

复用 Encoder 就会自动复用全部缓冲吗？不能这样假设。应显式设置 BufferPool，让借还关系成为配置的一部分。

把 bytes.Buffer 放进这个池可以吗？不可以。接口要求的是 *png.EncoderBuffer；输出字节缓冲属于另一层复用，应单独管理。

编码报错后要手动 Put 吗？通过配置接入池时由编码器管理借还，调用方不要额外归还同一对象，否则可能重复入池。

接入的关键是专用对象类型、明确的借还所有权和足够长的复用范围。是否保留这项优化，应由相同输入下的分配、耗时及内存表现共同决定。

参考：Go 官方 PNG 缓冲池接口；PNG 编码器官方实现；sync.Pool 官方语义。