Object Pool — Optimization¶

1. How to use this file¶

Twelve scenarios where object-pool code is slower, allocates more, or wastes memory it didn't need to. Each entry has a Scenario, a Before (code + benchmark), and a collapsible After (optimized code + benchmark + why + trade-offs + when NOT). Anchored at Go 1.23, amd64. Numbers are reproducible-shape — run go test -bench=. -benchmem on your hardware before quoting them.

Pooling is the rare pattern where the wrong default does worse than no pattern at all. A pool adds ~5 ns per Get/Put, a sync.Pool may evict items every GC cycle, and a poorly-bounded pool can hold tens of MB indefinitely. The trade is one of: code clarity, memory ceiling, or generality. Make it only when a benchmark or a flame graph points at it. Reading order: Exercise 1 (should I pool?), then 2 and 8 (generics + cap), then 5 (sizing), then the rest.

2. Exercise 1 — No pool on a hot allocating path¶

A handler that builds a small response per request allocates a fresh bytes.Buffer every call. At 50k QPS the allocator and the GC do constant work to free memory the next request immediately re-allocates.

Before:

func renderHello(w io.Writer, name string) {
    var buf bytes.Buffer
    buf.WriteString("hello, ")
    buf.WriteString(name)
    buf.WriteString("!\n")
    w.Write(buf.Bytes())
}

BenchmarkNoPool-8    20000000    78 ns/op    64 B/op    1 allocs/op

var bufPool = sync.Pool{New: func() any { return new(bytes.Buffer) }}

func renderHello(w io.Writer, name string) {
    buf := bufPool.Get().(*bytes.Buffer)
    defer bufPool.Put(buf)
    buf.Reset()
    buf.WriteString("hello, ")
    buf.WriteString(name)
    buf.WriteString("!\n")
    w.Write(buf.Bytes())
}

BenchmarkPooled-8    100000000    14 ns/op    0 B/op    0 allocs/op

3. Exercise 2 — Untyped sync.Pool with type assertion on every Get¶

sync.Pool.Get returns any; the classic form casts Get().(*T) on every call. The cast is cheap (~1 ns) but it's a runtime check that can panic on misconfigured New, and it shows up as noise in benchmark histograms.

Before:

var rawPool = sync.Pool{New: func() any { return &Encoder{} }}

func encode(v any) []byte {
    e := rawPool.Get().(*Encoder) // assertion every call
    defer rawPool.Put(e)
    e.Reset()
    return e.Encode(v)
}

BenchmarkUntypedPool-8    50000000    34 ns/op    0 B/op    0 allocs/op

type Pool[T any] struct{ p sync.Pool }

func NewPool[T any](newFn func() *T) *Pool[T] {
    return &Pool[T]{p: sync.Pool{New: func() any { return newFn() }}}
}

func (p *Pool[T]) Get() *T  { return p.p.Get().(*T) }
func (p *Pool[T]) Put(v *T) { p.p.Put(v) }

var encPool = NewPool(func() *Encoder { return &Encoder{} })

func encode(v any) []byte {
    e := encPool.Get()
    defer encPool.Put(e)
    e.Reset()
    return e.Encode(v)
}

BenchmarkTypedPool-8    60000000    28 ns/op    0 B/op    0 allocs/op

4. Exercise 3 — make([]byte, 4096) per request¶

A handler reads a small message into a 4 KB slice sized "big enough for almost all messages", allocated fresh per request.

Before:

func handle(conn net.Conn) error {
    buf := make([]byte, 4096) // 4 KB, every request
    n, err := conn.Read(buf)
    if err != nil { return err }
    return process(buf[:n])
}

BenchmarkAllocSlice-8    5000000    230 ns/op    4096 B/op    1 allocs/op

var bytePool = sync.Pool{New: func() any { b := make([]byte, 4096); return &b }}

func handle(conn net.Conn) error {
    bp := bytePool.Get().(*[]byte)
    defer bytePool.Put(bp)
    buf := (*bp)[:4096] // restore full length
    n, err := conn.Read(buf)
    if err != nil { return err }
    return process(buf[:n])
}

BenchmarkPoolSlice-8    100000000    13 ns/op    0 B/op    0 allocs/op

5. Exercise 4 — bytes.Buffer.Reset() when a slice would do¶

bytes.Buffer carries a lastRead field, an internal offset, and io.Reader/io.Writer boilerplate — overkill for a pure write-then-flush path.

Before:

var bufPool = sync.Pool{New: func() any { return new(bytes.Buffer) }}

type Batch struct{ Body *bytes.Buffer }

func (b *Batch) Append(line string) {
    b.Body.WriteString(line)
    b.Body.WriteByte('\n')
}

func reset(b *Batch) { b.Body.Reset() }

BenchmarkBufferReset-8    80000000    18 ns/op    0 B/op    0 allocs/op

type Batch struct{ Body []byte }

func (b *Batch) Append(line string) {
    b.Body = append(b.Body, line...)
    b.Body = append(b.Body, '\n')
}

func reset(b *Batch) { b.Body = b.Body[:0] }

var batchPool = sync.Pool{New: func() any {
    return &Batch{Body: make([]byte, 0, 4096)}
}}

BenchmarkSliceReset-8    300000000    4.6 ns/op    0 B/op    0 allocs/op

6. Exercise 5 — Undersized chan T connection pool¶

A chan *Conn of size 8 looks reasonable on a laptop but under 200 concurrent requests with a 30 ms downstream call, 192 goroutines line up waiting for a slot.

Before:

type Pool struct{ ch chan *Conn }

func New() *Pool { return &Pool{ch: make(chan *Conn, 8)} } // arbitrary

func (p *Pool) Get(ctx context.Context) (*Conn, error) {
    select {
    case c := <-p.ch: return c, nil
    case <-ctx.Done(): return nil, ctx.Err()
    }
}

BenchmarkChanPool8-8    300000    4800 ns/op   // p99 includes queue wait

func New(arrivalsPerSec, serviceSec float64) *Pool {
    capacity := int(math.Ceil(arrivalsPerSec*serviceSec)) * 2 // peak headroom
    if capacity < 4 { capacity = 4 }
    return &Pool{ch: make(chan *Conn, capacity)}
}

BenchmarkChanPoolSized-8    5000000    240 ns/op   // no queue wait at target load

7. Exercise 6 — Unbuffered worker channel¶

An unbuffered job channel forces the producer to wait for a worker on every job — for short jobs the handshake is most of the cost.

Before:

type Pool struct{ jobs chan func() }

func New(workers int) *Pool {
    p := &Pool{jobs: make(chan func())} // unbuffered
    for i := 0; i < workers; i++ {
        go func() { for f := range p.jobs { f() } }()
    }
    return p
}

func (p *Pool) Submit(f func()) { p.jobs <- f }

BenchmarkUnbufWorkers-8    2000000    580 ns/op    // 4 workers, 1µs job

func New(workers int) *Pool {
    p := &Pool{jobs: make(chan func(), workers*4)}
    for i := 0; i < workers; i++ {
        go func() { for f := range p.jobs { f() } }()
    }
    return p
}

BenchmarkBufWorkers-8    8000000    140 ns/op

8. Exercise 7 — interface{} boxing on Get¶

Pre-generics pools returned interface{} and the caller cast back. Even with any (Go 1.18+) the API signature materializes an eface/iface pair per Put for non-pointer types.

Before:

type Pool struct{ pool sync.Pool }
func (p *Pool) Get() any  { return p.pool.Get() }
func (p *Pool) Put(v any) { p.pool.Put(v) }

BenchmarkAnyPool-8    50000000    32 ns/op    0 B/op    0 allocs/op

0 B/op because *bytes.Buffer is a pointer — its iface fits in registers. Pool a value type and the box allocates.

BenchmarkTypedPool-8    60000000    25 ns/op    0 B/op    0 allocs/op

9. Exercise 8 — Pool with no upper bound on item size¶

A pooled bytes.Buffer that grows to 4 MB during one outlier stays 4 MB forever — 1000 cached buffers × 4 MB = gigabytes pinned.

Before:

var bufPool = sync.Pool{New: func() any { return new(bytes.Buffer) }}

func put(b *bytes.Buffer) {
    b.Reset()
    bufPool.Put(b)
}

BenchmarkPoolUncapped-8    50000000    18 ns/op    0 B/op    0 allocs/op
// memory: heap profile shows 4MB × N pinned in pool

const maxBufCap = 64 << 10 // 64 KiB

func put(b *bytes.Buffer) {
    if b.Cap() > maxBufCap {
        return // let GC reclaim
    }
    b.Reset()
    bufPool.Put(b)
}

BenchmarkPoolCapped-8    50000000    19 ns/op    0 B/op    0 allocs/op
// memory: heap profile stable at 64KB × pool size

10. Exercise 9 — Get() inside a hot loop¶

Borrowing per iteration of a tight loop pays pool overhead N times instead of once.

Before:

func formatLines(out io.Writer, items []Item) {
    for _, it := range items {
        buf := bufPool.Get().(*bytes.Buffer)
        buf.Reset()
        buf.WriteString(it.Name)
        buf.WriteByte('\n')
        out.Write(buf.Bytes())
        bufPool.Put(buf)
    }
}

BenchmarkGetPerIter-8    100000    18000 ns/op    // 1000 items

func formatLines(out io.Writer, items []Item) {
    buf := bufPool.Get().(*bytes.Buffer)
    defer bufPool.Put(buf)
    for _, it := range items {
        buf.Reset()
        buf.WriteString(it.Name)
        buf.WriteByte('\n')
        out.Write(buf.Bytes())
    }
}

BenchmarkGetOnce-8    400000    4200 ns/op

11. Exercise 10 — New JSON encoder per call¶

json.NewEncoder(w) allocates an encoder struct, its scratch buffer, and an *encodeState per call — measurable at high request rates.

Before:

func writeJSON(w io.Writer, v any) error {
    return json.NewEncoder(w).Encode(v)
}

BenchmarkJSONFresh-8    2000000    820 ns/op    480 B/op    7 allocs/op

type jsonScratch struct {
    buf *bytes.Buffer
    enc *json.Encoder
}

var jsonPool = sync.Pool{New: func() any {
    b := &bytes.Buffer{}
    return &jsonScratch{buf: b, enc: json.NewEncoder(b)}
}}

func writeJSON(w io.Writer, v any) error {
    s := jsonPool.Get().(*jsonScratch)
    defer func() {
        if s.buf.Cap() > 64<<10 { return } // cap on return
        s.buf.Reset(); jsonPool.Put(s)
    }()
    if err := s.enc.Encode(v); err != nil { return err }
    _, err := w.Write(s.buf.Bytes())
    return err
}

BenchmarkJSONPooled-8    10000000    310 ns/op    16 B/op    1 allocs/op

12. Exercise 11 — Acquire contention on a single pool¶

sync.Pool shards internally by P, but a custom chan T pool is a single channel — under heavy concurrency every Get takes a turn at the channel lock.

Before:

type ConnPool struct{ ch chan *Conn }

func (p *ConnPool) Get() *Conn { return <-p.ch }
func (p *ConnPool) Put(c *Conn) { p.ch <- c }

BenchmarkSinglePool-8    2000000    580 ns/op   // 32 concurrent borrowers

const shards = 8

type ConnPool struct{ s [shards]chan *Conn }

// Cheap selector — locality, not perfect balance. Production uses
// runtime_procPin via assembly shim or a per-goroutine hash.
func shardIdx() int {
    var x int
    return int(uintptr(unsafe.Pointer(&x))>>4) & (shards - 1)
}

func (p *ConnPool) Get() *Conn { return <-p.s[shardIdx()] }
func (p *ConnPool) Put(c *Conn) {
    select {
    case p.s[shardIdx()] <- c:
    default: c.Close() // shard full
    }
}

BenchmarkShardedPool-8    20000000    62 ns/op

13. Exercise 12 — sync.Pool object with a finalizer¶

A runtime.SetFinalizer on a pooled object is a contradiction: the pool keeps it reachable, the finalizer never runs, and the object spends every life on the GC's slow path.

Before:

type Conn struct{ fd int }

func newConn() *Conn {
    c := &Conn{fd: openSocket()}
    runtime.SetFinalizer(c, func(c *Conn) { syscall.Close(c.fd) })
    return c
}

var pool = sync.Pool{New: func() any { return newConn() }}

BenchmarkPoolWithFinalizer-8    5000000    520 ns/op    72 B/op    1 allocs/op

type ConnPool struct {
    mu   sync.Mutex
    idle []*Conn
    cap  int
}

func (p *ConnPool) Get() *Conn {
    p.mu.Lock(); defer p.mu.Unlock()
    if n := len(p.idle); n > 0 {
        c := p.idle[n-1]; p.idle = p.idle[:n-1]
        return c
    }
    return &Conn{fd: openSocket()}
}

func (p *ConnPool) Put(c *Conn) {
    p.mu.Lock()
    full := len(p.idle) >= p.cap
    if !full { p.idle = append(p.idle, c) }
    p.mu.Unlock()
    if full { syscall.Close(c.fd) }
}

func (p *ConnPool) Close() {
    p.mu.Lock(); defer p.mu.Unlock()
    for _, c := range p.idle { syscall.Close(c.fd) }
    p.idle = nil
}

BenchmarkPoolNoFinalizer-8    20000000    140 ns/op    0 B/op    0 allocs/op

14. When NOT to optimize¶

Most Go programs do not need a pool. The default allocator handles small short-lived objects efficiently; escape analysis places many on the stack. A handler at 100 req/s allocating a 256-byte struct generates 25 KB/s of garbage — noise. A CLI that runs once should never pool.

Profile first. Run go test -bench=. -benchmem and pprof -alloc_objects. If the suspect type isn't in the top 10 by allocation count and not a CPU bottleneck, leave it alone.

Common premature optimizations: pooling structs ≤256 bytes (the allocator wins), pooling objects used once per program lifetime, pooling without Reset (a correctness bug, not a perf win), pooling with no cap (Exercise 8), sharding (Exercise 11) under low contention, and putting back a connection whose health you didn't check. The pool is a hint, not a guarantee — design for the case where New runs every call.

15. Summary¶

Always-ship wins (apply by default in any new hot-path code):

• Use generic typed pool wrappers around sync.Pool (Exercise 2, Exercise 7).
• Cap buffer size on return (Exercise 8).
• Borrow once outside loops, not once per iteration (Exercise 9).
• Never set a finalizer on a pooled object (Exercise 12).
• Use b = b[:0] instead of bytes.Buffer.Reset when you don't need the io.Writer interface (Exercise 4).

Wins behind a profile (do these when measurements justify them):

• Add a pool to a hot allocating path (Exercise 1) — only when allocation shows up in pprof.
• Replace make([]byte, N) with a pooled fixed-size slice (Exercise 3) at 4 KB or larger sizes.
• Pool reusable json.Encoders with shared buffers (Exercise 10) on serialization-heavy endpoints.
• Size connection pools with Little's Law (Exercise 5) when queue waits show up in p99 latency.
• Buffer worker channels (Exercise 6) when Submit throughput matters more than per-job latency.

Specialty:

• Shard a custom pool by P or goroutine ID (Exercise 11) when a flame graph shows acquire contention.
• Build a typed pool with explicit Close for resources with OS handles (Exercise 12).

Object pooling is a precision instrument: bloats memory on the wrong target, cuts GC pressure dramatically on the right one. Measure, profile, then pool.