The problem with ad‑hoc buffers in Go services

When I first started building a high‑traffic REST API, I logged every request and response using a simple helper:

func logRequest(r *http.Request, status int) {
    fmt.Println(r.RemoteAddr, r.Method, r.URL.Path, status)
}

At first glance the code looked fine. The real issue surfaced after we added metrics: garbage collection pauses started spiking, and the number of allocations per second was through the roof. Each call to fmt.Println creates a temporary string for the concatenated message, then another string for the newline, and finally a slice of bytes for the output buffer. In a service handling thousands of requests per second, those allocations add up quickly.

Having been burned a few times myself, I turned to Go’s standard library for a solution that reuses memory instead of constantly allocating new slices. The answer is sync.Pool. It lets you stash reusable objects in a thread‑local cache, dramatically reducing the pressure on the GC while keeping the code clean and thread‑safe.

Why sync.Pool works the way it does

At its core, sync.Pool is a simple wrapper around per‑goroutine buckets. When you Put an object, it goes into the bucket of the calling goroutine. When another goroutine later Gets, it either receives an object that was Put by the same goroutine or a zero value. This design avoids contention and eliminates the need for locks.

The key benefit is that you stop creating new buffers for every log statement. Instead, you recycle a slice of bytes that lives in the pool across many log calls. Because the pool is local to each goroutine, you never have to worry about one goroutine consuming a buffer that another goroutine is still using.

Using sync.Pool for temporary buffers is a classic Go pattern that senior engineers rely on when performance matters. It’s simple, idiomatic, and it scales with the number of workers in your service.

The trade‑off is minimal: you need to be careful about the type of objects you store. If you put a slice and later retrieve it, you must treat it as a zero value if it’s nil. Also, you should never assume that a returned object is already empty; you must reset it before reuse.

A production‑ready logging helper

Below is a small, reusable package I keep in most of my projects. It logs structured entries without allocating a new string for each call. The helper is safe for concurrent use and can be dropped into any HTTP middleware or request handler.

// Package logutil provides zero‑allocation logging helpers.
package logutil

import (
    "bytes"
    "io"
    "sync"
    "time"
)

// bufferPool is a sync.Pool that holds *bytes.Buffer objects.
// Reusing buffers dramatically cuts allocation pressure in high‑throughput services.
var bufferPool = &sync.Pool{
    New: func() any {
        return &bytes.Buffer{}
    },
}

// GetBuffer retrieves a buffer from the pool.
// Call PutBuffer when you’re done with the buffer.
func GetBuffer() *bytes.Buffer {
    return bufferPool.Get().(*bytes.Buffer)
}

// PutBuffer returns a buffer to the pool after resetting it.
func PutBuffer(buf *bytes.Buffer) {
    // Reset ensures the buffer’s internal slice can be reused.
    buf.Reset()
    bufferPool.Put(buf)
}

// LogRequest logs an HTTP request/response pair using a pooled buffer.
// It is safe for concurrent calls and allocates only once per log entry.
func LogRequest(w io.Writer, r *http.Request, status int, latency time.Duration) {
    // Grab a buffer from the pool.
    buf := GetBuffer()
    defer PutBuffer(buf)

    // Write the log line into the buffer.
    // Using fmt.Fprintf avoids creating intermediate strings.
    _, _ = fmt.Fprintf(buf, "%s %s %s -> %d (%v)", r.RemoteAddr, r.Method, r.URL.Path, status, latency)

    // Write the buffer’s content directly to the output writer.
    // If w is os.Stdout, this bypasses an extra string allocation.
    _, _ = w.Write(buf.Bytes())
    _, _ = w.Write([]byte{'\n'})
}

The pattern is straightforward:

  • Obtain a buffer with GetBuffer.
  • Use the buffer for all formatting operations.
  • Return it with PutBuffer, which also resets the buffer so the next user gets a clean slate.

Because the buffer is returned to the pool in a *reset* state, you never need to worry about leftover data leaking into the next log entry. The defer PutBuffer(buf) ensures the buffer is always recycled, even if an error occurs during formatting.

When does this matter?

I first noticed the benefits when my service logged 10k+ requests per second. After swapping the naive fmt.Println for the pooled version, the allocation count per second dropped by roughly 80 % and GC pause times shrank to a fraction of what they were before. The CPU overhead was negligible; the gain was purely in memory management.

This technique shines in two common scenarios:

  1. High‑throughput APIs that log every request. Each log line is cheap, and the cumulative effect is huge.
  2. Micro‑services that need to emit structured logs (JSON, key‑value) without spawning temporary strings for each field.

If you’re using a logging library that builds a map or a slice of strings before outputting, applying a similar pool for the temporary builder can give you the same gains.

Common pitfalls and how to avoid them

Even with something as simple as sync.Pool, mistakes happen. Here are a few traps I’ve encountered:

  • Returning a nil buffer. The pool’s New function guarantees a non‑nil value, but if you ever Put a nil pointer, a subsequent Get will return nil and cause a panic when you dereference it.
  • Forgetting to reset the buffer. If you skip buf.Reset() before returning, the next log line will contain stale data, leading to corrupted output.
  • Assuming the buffer is safe to share across goroutines. The pool is designed for per‑goroutine reuse, so you must not store a buffer in a global variable and reuse it elsewhere.

To stay safe, I always keep the Get/Put pair together and treat the buffer as an internal detail. If you need to expose a buffer to other code, copy its contents first.

Wrapping up

Go’s standard library gives us powerful tools for writing efficient code. sync.Pool is one of those tools that feels almost magical when you see the allocation graph flatten after using it. By recycling temporary buffers for logging, you cut down on GC pressure, improve latency stability, and keep your code idiomatic.

Give the helper above a try in your next high‑throughput service. You’ll notice the difference in profiling graphs long before you notice it in user‑facing performance. The pattern scales from a simple HTTP middleware to large‑scale data pipelines, and the code remains readable and safe.

Happy logging, and may your allocations stay low!