Optimización de memoria con sync.Pool

sync.Pool es un contenedor thread-safe diseñado para reutilizar objetos temporales y mitigar la presión sobre el Garbage Collector (GC). Su objetivo no es actuar como un cache de datos, sino como un depósito de objetos que se pueden “alquilar” y “devolver” rápidamente para evitar la asignación constante en el heap. Internamente, para evitar la contención de locks cuando muchos hilos intentan acceder al pool, Go implementa una estructura de listas locales por cada procesador lógico (P); esto permite que un hilo busque primero en su propia lista privada antes de intentar realizar un “stealing” (robar) de objetos de otros procesadores. Debes usarlo cuando tengas un flujo de alta frecuencia de objetos con un ciclo de vida corto pero que son costosos de crear o que generan mucha basura, como buffers de bytes, decodificadores JSON o estructuras de serialización. Si intentas usarlo para mantener datos persistentes o como un cache de resultados, tu lógica fallará, ya que el GC puede vaciar el pool por completo en cualquier momento entre ciclos de recolección.

package main

import (
	"bytes"
	"encoding/json"
	"fmt"
	"sync"
)

// UserPayload simula una estructura compleja que se serializa con mucha frecuencia.
type UserPayload struct {
	ID    int    `json:"id"`
	Token string `json:"token"`
	Data  string `json:"data"`
}

// bufferPool gestiona la reutilización de bytes.Buffer para evitar
// la asignación de nuevos slices de bytes en cada petición.
var bufferPool = sync.Pool{
	New: func() any {
		// Se inicializa con una capacidad predefinida para reducir
		// las reasignaciones de memoria durante el crecimiento del buffer.
		return new(bytes.Buffer)
	},
}

func processRequest(id int, payload UserPayload) error {
	// Obtenemos un buffer del pool. Si el pool está vacío, se ejecuta bufferPool.New.
	buf := bufferPool.Get().(*bytes.Buffer)

	// Es crítico resetear el estado del objeto antes de usarlo, 
	// ya que el buffer puede contener datos de una operación anterior.
	buf.Reset()

	// Nos aseguramos de devolver el buffer al pool al finalizar,
	// incluso si ocurre un error durante la serialización.
	defer bufferPool.Put(buf)

	// Usamos el buffer directamente como destino para el encoder.
	// Esto evita que json.Marshal cree un nuevo []byte en cada llamada.
	if err := json.NewEncoder(buf).Encode(payload); err != nil {
		return err
	}

	// Simulamos el envío del payload (ej. a un log o a una red).
	fmt.Printf("Payload serializado: %s", buf.String())
	return nil
}

func main() {
	users := []UserPayload{
		{ID: 1, Token: "abc-123", Data: "Session data A"},
		{ID: 2, Token: "def-456", Data: "Session data B"},
		{ID: 3, Token: "ghi-789", Data: "Session data C"},
	}

	for _, u := range users {
		if err := processRequest(u.ID, u); err != nil {
			fmt.Printf("Error procesando usuario %d: %v\n", u.ID, err)
		}
	}
}

En este ejemplo, el bufferPool es el corazón de la optimización. Cuando llamamos a bufferPool.Get(), el runtime intenta entregarnos un *bytes.Buffer que ya exista en el pool para evitar que el sistema operativo tenga que asignar nueva memoria en el heap.

Es vital la función anónima definida en New: sin ella, Get() devolvería nil si el pool está vacío. Al devolver el objeto con bufferPool.Put(buf), estamos permitiendo que el siguiente Get() lo reutilice. Fíjate en la importancia de buf.Reset(); sin esta llamada, el segundo usuario en el main recibiría un buffer que contiene los datos del primero más los suyos, provocando una corrupción de datos silenciosa. Finalmente, el uso de json.NewEncoder(buf).Encode(payload) es una decisión de rendimiento clave: al pasarle el buffer directamente al encoder, escribimos la salida directamente en la memoria ya asignada, evitando la creación de un slice de bytes temporal que json.Marshal generaría en cada iteración.

El error frecuente

El error más sutil y peligroso al usar sync.Pool es olvidar resetear el estado del objeto devuelto. Como los objetos en el pool conservan su estado interno, si recuperas un buffer o una estructura y no la limpias, estarás trabajando con basura de una operación previa.

// ERROR: El buffer contiene datos viejos
buf := bufferPool.Get().(*bytes.Buffer)
// Olvidar buf.Reset() aquí...
buf.WriteString("Nuevo dato") 
// El contenido real será "Datos anterioresNuevo dato"

Otro error conceptual es tratar al pool como un cache. Si tu lógica depende de que un objeto esté disponible para la siguiente petición (por ejemplo, un objeto que contiene una sesión de usuario), sync.Pool te fallará porque el Garbage Collector puede purgar el pool en cualquier momento para liberar memoria, dejando tus referencias en nil o vacías.

N° 146