Técnicas para reducir la presión sobre el Garbage Collector

La presión sobre el Garbage Collector (GC) se manifiesta principalmente cuando el runtime pasa demasiado tiempo en la fase de Mark (marcado), recorriendo el grafo de objetos en el heap para determinar qué memoria es reutilizable. El costo real del GC no es solo el tiempo que detiene el mundo (STW), sino el consumo de ciclos de CPU dedicados a la “persecución de punteros” (pointer chasing). Para mitigar esto, debemos reducir la frecuencia de las llamadas a mallocgc y, sobre todo, disminuir la pointer density: la cantidad de punteros que el GC debe seguir en cada ciclo. Esto se logra mediante la reutilización de memoria con sync.Pool, la pre-allocación de colecciones y el diseño de estructuras con tipos de valor en lugar de punteros. Estas técnicas son esenciales en hot paths de alto rendimiento o servicios que procesan ráfagas masivas de datos; de lo contrario, el CPU de tu servicio se agotará intentando limpiar la memoria en lugar de ejecutar tu lógica de negocio.

package main

import (
	"bytes"
	"fmt"
	"sync"
)

// Metadata es una estructura de "baja densidad de punteros".
// Al usar [16]byte en lugar de string, evitamos que el GC tenga que 
// seguir un puntero adicional para cada instancia. Los datos 
// residen directamente dentro del bloque de memoria del struct.
type Metadata [16]byte

// Packet representa una unidad de trabajo.
// Al usar el tipo de valor Metadata en lugar de *Metadata,
// si creamos un slice de []Packet, los datos están contiguos
// en memoria y el GC solo tiene que escanear el slice, no cada elemento.
type Packet struct {
	Header  Metadata
	Payload []byte
}

// Processor gestiona el procesamiento de datos optimizando el uso de memoria.
type Processor struct {
	// bufferPool reutiliza bytes.Buffer para evitar asignaciones en cada paquete.
	bufferPool sync.Pool
}

func NewProcessor() *Processor {
	return &Processor{
		bufferPool: sync.Pool{
			New: func() any {
				// Pre-alocamos una capacidad inicial para evitar re-allocations
				// durante el uso normal del buffer.
				return bytes.NewBuffer(make([]byte, 0, 1024))
			},
		},
	}
}

func (p *Processor) Process(raw []byte) {
	// Obtenemos un buffer de la pool.
	buf := p.bufferPool.Get().(*bytes.Buffer)
	
	// Importante: Limpiamos el buffer antes de usarlo, pero mantenemos 
	// la capacidad de la memoria ya asignada.
	buf.Reset()
	
	// Realizamos la operación sin generar nuevas asignaciones en el heap.
	buf.Write(raw)
	buf.WriteString(": processed")

	// Simulamos procesamiento...
	fmt.Printf("Data: %s\n", buf.String())

	// Devolvemos el buffer a la pool para su reutilización.
	p.bufferPool.Put(buf)
}

func main() {
	p := NewProcessor()
	
	// Pre-alocamos un slice de paquetes con una capacidad conocida.
	// Esto evita que el runtime tenga que copiar el slice a una 
	// nueva ubicación de memoria conforme crece.
	packets := make([]Packet, 0, 10)

	for i := 0; i < 5; i++ {
		// Construcción de un header sin punteros
		var m Metadata
		copy(m[:], fmt.Sprintf("ID-%d", i))

		pkt := Packet{
			Header:  m,
			Payload: []byte("data payload"),
		}
		packets = append(packets, pkt)
		
		p.Process(pkt.Payload)
	}
}

Análisis del diseño

En el ejemplo anterior, la eficiencia se basa en tres pilares:

1. Reutilización con sync.Pool: En Processor.Process, en lugar de dejar que el buffer de bytes.Buffer muera y sea recolectado, lo devolvemos a la bufferPool. Esto transforma una asignación constante en el heap en una operación de recuperación de memoria ya existente. El uso de buf.Reset() es clave: no libera la memoria subyacente, solo reinicia los contadores del buffer, manteniendo la capacidad (cap) para evitar futuras re-allocations.

2. Baja densidad de punteros: La estructura Metadata utiliza un array de bytes [16]byte en lugar de un string. En Go, un string es internamente un puntero a un array de bytes y una longitud. Si tuvieras un millón de Metadata como strings, el GC tendría un millón de punteros más que recorrer. Al usar un array, los datos son “in-place” y el GC los trata como datos primitivos, no como referencias.

3. Pre-alocación y Tipos de Valor: En main, al usar make([]Packet, 0, 10), le decimos al runtime exactamente cuánta memoria reservar de antemano. Esto evita la penalización de CPU de copiar todo el array cada vez que el append supera la capacidad actual. Además, al usar []Packet (un slice de valores) en lugar de []*Packet (un slice de punteros), garantizamos la contigüidad de la memoria, lo que mejora la localidad de caché y reduce drásticamente el trabajo de escaneo del GC.

El error frecuente

Un error clásico al usar sync.Pool ocurre cuando devuelves al pool un slice que ha crecido mucho en una operación específica.

// ERROR COMÚN
func (p *Processor) BadProcess(data []byte) {
    buf := p.bufferPool.Get().(*bytes.Buffer)
    defer p.bufferPool.Put(buf)

    buf.Write(data)
    if len(data) > 1024*1024 { // Si recibes un paquete de 1MB
        buf.Write(make([]byte, 1024*1024)) // El buffer crece a 2MB
    }
    // Al hacer Put(buf), estamos guardando un buffer que ocupa 2MB 
    // en la pool. Si esto pasa frecuentemente, la pool retendrá 
    // mucha memoria "huérfana" que el GC no puede liberar fácilmente,
    // causando un aumento masivo en la RSS de tu proceso.
}

Para evitarlo, si el buffer crece desproporcionadamente, lo ideal es no devolverlo a la pool o crear un mecanismo que limite la capacidad máxima antes de hacer el Put.

N° 174