What is sync.Pool and when should you use it?

// Typical use: expensive-to-allocate, frequently used objects
var bufPool = sync.Pool{
    New: func() any {
        // Called when pool is empty — allocate a fresh object
        buf := make([]byte, 0, 4096)
        return &buf
    },
}

func processRequest(data []byte) string {
    // Get a buffer from the pool (may be a fresh allocation or reused)
    bufPtr := bufPool.Get().(*[]byte)
    buf := (*bufPtr)[:0] // reset length, keep capacity

    // ... use buf for scratch work ...
    buf = append(buf, data...)
    result := string(buf)

    // Return to pool — DON'T use buf after this
    *bufPtr = buf
    bufPool.Put(bufPtr)
    return result
}

// Important constraints:
// 1. The GC MAY clear the pool between any two GC cycles
//    Do NOT rely on objects in the pool surviving across GCs
// 2. Objects must be safe to reset to a clean state before reuse
// 3. Do NOT store pointers to pool objects — return them before the caller returns

// Real-world examples:
// - encoding/json uses sync.Pool for encoder/decoder scratch buffers
// - fmt uses sync.Pool for pp (print state) objects
// - net/http uses sync.Pool for request buffers

// Anti-patterns:
// - Pooling objects that hold open file descriptors or connections
// - Pooling objects that are expensive to validate/clean on reuse
// - Using Pool for long-lived objects (GC will evict them)