CesarLead: Aprende sobre Linux, Desarrollo y Más

Muchachones, hace un tiempo estábamos reventados de latencia en un servicio que procesaba millones de registros JSON al día. Cada vez que entraba un request, se armaba un new ObjectMapper() para serializar, y el GC empezó a pegar jump cuts a cada rato. Después del profiling, la tinta y el café, la solución fue volver a lo básico: el famoso Object Pool Pattern usando ThreadLocal. Con eso, pasamos de ~4.5 segundos a ~0.5 segundos procesando 10 millones de registros. Casi nada jaja jaja la diferencia :P casi 10x

2. El Problema: Crear Objetos Caros a Lo Loco

Muchachones,este es un ejemplo simplificado del problema para fines ilustrativos

package com.cesarlead.pool.problem;

import com.fasterxml.jackson.core.JsonProcessingException;
import com.fasterxml.jackson.databind.ObjectMapper;
import java.util.List;

public class ProcesadorRegistrosLento {

    public String procesarRegistro(RegistroDatos data) {
        // Aquí se arma un ObjectMapper nuevo en cada llamada
        ObjectMapper mapper = new ObjectMapper();
        try {
            // El mapeo a JSON implica reflexión, introspección y cachés internos.
            return mapper.writeValueAsString(data);
        } catch (JsonProcessingException e) {
            throw new RuntimeException("Error serializando JSON", e);
        }
    }
}

Y RegistroDatos era un DTO simple:

package com.cesarlead.pool.problem;

import java.util.List;

public class RegistroDatos {
    private int id;
    private String mensaje;
    private double valor;
    private List<String> etiquetas;

    public RegistroDatos(int id, String mensaje, double valor, List<String> etiquetas) {
        this.id = id;
        this.mensaje = mensaje;
        this.valor = valor;
        this.etiquetas = etiquetas;
    }

    // Getters y setters básicos
    public int getId() { return id; }
    public String getMensaje() { return mensaje; }
    public double getValor() { return valor; }
    public List<String> getEtiquetas() { return etiquetas; }
}

Entonces que ocurre aquí? Cada vez que procesarRegistro(...) se invoca:

Se crea un nuevo ObjectMapper.
Jackson tiene que cargar metadata, introspección de clases, configurar módulos, etc.
Al final, se serializa el DTO a JSON.

Para unos 10 millones de registros, el overhead de “new ObjectMapper()” se convierte en una locura: presión brutal al GC, consumo alto de CPU y latencias inaceptables.

3. El Patrón Object Pool con ThreadLocal

La idea es sencilla: reutilizar la instancia de ObjectMapper en lugar de crearla cada vez. Para ello, usamos

ThreadLocal<ObjectMapper>

Cada hilo del pool tiene su propia instancia de ObjectMapper.
Nunca hay las benditas racing conditions porque cada hilo accede a su propia copia.
Eliminamos la sobrecarga de reconstruir metadata internas de Jackson.

Veamos cómo implementarlo.

3.1. MapperPool: la Clase de Pool

package com.cesarlead.pool.solution;

import com.fasterxml.jackson.databind.ObjectMapper;
import com.fasterxml.jackson.databind.SerializationFeature;

/**
 * Clase singleton que maneja un ThreadLocal de ObjectMapper.
 * 
 * Ventajas:
 * - Cada hilo obtiene su propia instancia.
 * - Reutilizamos la configuración sin overhead.
 * 
 * Desventajas:
 * - Si no se limpia el ThreadLocal, puede haber memory leaks en entornos con pool de hilos.
 */
public final class MapperPool {

    // 1. ThreadLocal con inicialización perezosa
    private static final ThreadLocal<ObjectMapper> pool = ThreadLocal.withInitial(() -> {
        System.out.println("Creando ObjectMapper para el hilo: " + Thread.currentThread().getName());
        ObjectMapper objectMapper = new ObjectMapper();
        // Configuraciones recomendadas (ajusta según tus necesidades):
        objectMapper.disable(SerializationFeature.WRITE_DATES_AS_TIMESTAMPS);
        objectMapper.findAndRegisterModules(); // Carga módulos automáticos (ej. Java Time)
        return objectMapper;
    });

    // 2. Constructor privado para evitar instanciación
    private MapperPool() { }

    /**
     * Obtiene un ObjectMapper configurado para el hilo actual.
     * Si es la primera vez en el hilo, se crea con la configuración inicial.
     * @return instancia de ObjectMapper lista para usar
     */
    public static ObjectMapper get() {
        return pool.get();
    }

    /**
     * Limpia la instancia del ThreadLocal para el hilo actual.
     * PRIORITARIO!!! Para evitar memory leaks en entornos con pool de hilos (ExecutorService,
     * servidores de aplicaciones, etc.). Debe llamarse en un bloque finally.
     */
    public static void remove() {
        pool.remove();
    }
}

Explicación SOLID/DRY:

Single Responsibility (S): MapperPool solo se encarga de gestionar el pool de ObjectMapper.

Open/Closed (O): Si en un futuro necesito otra configuración de Jackson, puedo extender este pool sin modificar los consumidores.

Dependency Inversion (D): Los consumidores no dependen de la implementación concreta de ObjectMapper, sino que obtienen la instancia desde el pool (aunque no es exactamente un “puerto/Adaptador”, sigue el principio de separar la creación del uso).

3.2. ProcesadorRegistros Rápido: Reemplazando la Creación Loca!!!

package com.cesarlead.pool.solution;

import com.cesarlead.pool.problem.RegistroDatos;
import com.fasterxml.jackson.core.JsonProcessingException;
import com.fasterxml.jackson.databind.ObjectMapper;

/**
 * Variante optimizada: reutiliza el ObjectMapper del ThreadLocal.
 */
public class ProcesadorRegistrosRapido {

    public String procesarRegistro(RegistroDatos data) {
        // Obtenemos la instancia reutilizable
        ObjectMapper mapper = MapperPool.get();
        try {
            return mapper.writeValueAsString(data);
        } catch (JsonProcessingException e) {
            throw new RuntimeException("Error serializando JSON", e);
        }
        // OJO!!! Si este método se ejecuta en un hilo de un pool (ExecutorService,
        // servlet container, etc.), debes limpiar el ThreadLocal en un bloque finally:
        //
        // finally {
        //     MapperPool.remove();
        // }
    }
}

Para los que tienen dudas:
“Por qué no uso un static final ObjectMapper y ya?”
Sí, en muchos casos un static final basta. Jackson 2.x ya es thread-safe para operaciones de lectura (serialización/deserialización) después de su configuración inicial.

Pero: si tu configuración de módulos, mixins o filtros es compleja o cambia en runtime, ThreadLocal te aísla de posibles efectos secundarios. Además, no dependes de asegurar que ningún desarrollo futuro modifique la configuración global.
Muchos frameworks (Spring Boot) usan de hecho un solo bean de ObjectMapper, pero debes asegurarte de no reconfigurarlo en caliente. Con
ThreadLocal
evitas esta preocupación.

Advertencia de Memory Leak:

En un servidor de aplicaciones (Tomcat, WildFly) o un pool de hilos (ExecutorService), los hilos se reutilizan. Si no llamas a MapperPool.remove() al final de la tarea, el ThreadLocalMap mantendrá la referencia a ObjectMapper, impidiendo que se recolecte la instancia cuando el hilo termine.

Solución: Siempre limpia en un finally o en un interceptor/filtro que envuelva la lógica. Ver más abajo cómo integrarlo en Spring Boot.

4. Integración en un Proyecto

4.1.

pom.xml

(fragmento clave)

<project xmlns="http://maven.apache.org/POM/4.0.0" 
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
                             http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>com.cesarlead.pool</groupId>
    <artifactId>object-pool-demo</artifactId>
    <version>1.0.0</version>
    <packaging>jar</packaging>
    <name>Object Pool Demo</name>

    <properties>
        <java.version>17</java.version>
        <!-- Versión de Jackson que soporte Java Time y módulos modernos -->
        <jackson.version>2.14.2</jackson.version>
        <!-- JMH para benchmarks -->
        <jmh.version>1.36</jmh.version>
    </properties>

    <dependencies>
        <!-- Jackson -->
        <dependency>
            <groupId>com.fasterxml.jackson.core</groupId>
            <artifactId>jackson-databind</artifactId>
            <version>${jackson.version}</version>
        </dependency>
        <dependency>
            <groupId>com.fasterxml.jackson.datatype</groupId>
            <artifactId>jackson-datatype-jsr310</artifactId>
            <version>${jackson.version}</version>
        </dependency>

        <!-- Spring Boot (opcional, para exponer un endpoint REST) -->
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
            <version>3.0.6</version>
        </dependency>

        <!-- JUnit 5, Mockito, AssertJ para tests -->
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-test</artifactId>
            <version>3.0.6</version>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>org.mockito</groupId>
            <artifactId>mockito-junit-jupiter</artifactId>
            <version>4.8.0</version>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>org.assertj</groupId>
            <artifactId>assertj-core</artifactId>
            <version>3.24.2</version>
            <scope>test</scope>
        </dependency>

        <!-- JMH para benchmarks -->
        <dependency>
            <groupId>org.openjdk.jmh</groupId>
            <artifactId>jmh-core</artifactId>
            <version>${jmh.version}</version>
        </dependency>
        <dependency>
            <groupId>org.openjdk.jmh</groupId>
            <artifactId>jmh-generator-annprocess</artifactId>
            <version>${jmh.version}</version>
            <scope>provided</scope>
        </dependency>
    </dependencies>

    <build>
        <plugins>
            <!-- Plugin para Java 17 -->
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>3.10.1</version>
                <configuration>
                    <source>${java.version}</source>
                    <target>${java.version}</target>
                </configuration>
            </plugin>

            <!-- Plugin JMH para facilitar compilación de benchmarks -->
            <plugin>
                <groupId>org.openjdk.jmh</groupId>
                <artifactId>jmh-maven-plugin</artifactId>
                <version>${jmh.version}</version>
                <executions>
                    <execution>
                        <id>benchmark</id>
                        <goals>
                            <goal>benchmark</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>
        </plugins>
    </build>
</project>

5. Benchmark con JMH: “Números No Mienten”

Para demostrar la mejora, usaremos JMH y compararemos el enfoque “new ObjectMapper()” vs. “ThreadLocal ObjectPool”.

5.1. Clase de Benchmark

package com.cesarlead.pool.benchmark;

import com.cesarlead.pool.problem.RegistroDatos;
import com.cesarlead.pool.problem.ProcesadorRegistrosLento;
import com.cesarlead.pool.solution.MapperPool;
import com.cesarlead.pool.solution.ProcesadorRegistrosRapido;
import com.fasterxml.jackson.core.JsonProcessingException;
import com.fasterxml.jackson.databind.ObjectMapper;
import org.openjdk.jmh.annotations.*;

import java.util.List;
import java.util.concurrent.TimeUnit;

/**
 * Benchmark para comparar:
 * - Creación de ObjectMapper en cada llamada
 * - Reutilización via ThreadLocal (MapperPool)
 */
@BenchmarkMode(Mode.Throughput)
@OutputTimeUnit(TimeUnit.SECONDS)
@State(Scope.Benchmark)
public class ObjectPoolBenchmark {

    private RegistroDatos registroEjemplo;
    private ProcesadorRegistrosLento lento;
    private ProcesadorRegistrosRapido rapido;

    @Setup(Level.Trial)
    public void setup() {
        registroEjemplo = new RegistroDatos(1, "Benchmark", 123.45, List.of("tag1", "tag2"));
        lento = new ProcesadorRegistrosLento();
        rapido = new ProcesadorRegistrosRapido();
    }

    @Benchmark
    public String testProcesadorLento() {
        return lento.procesarRegistro(registroEjemplo);
    }

    @Benchmark
    public String testProcesadorRapido() {
        // Aseguramos limpiar al finalizar cada llamada de benchmark
        try {
            return rapido.procesarRegistro(registroEjemplo);
        } finally {
            MapperPool.remove();
        }
    }
}

Explicación:

@State(Scope.Benchmark): compartimos datos de estado entre iteraciones.

@Benchmark: métodos medidos.

MapperPool.remove(): eliminamos la instancia del ThreadLocal para simular el comportamiento real cuando el hilo finaliza su trabajo.

5.2. Ejecutar el Benchmark

Desde la línea de comandos, en la carpeta del proyecto:

mvn clean install
mvn jmh:benchmark

Resultados Típicos (números aproximados)
Enfoque Throughput (ops/sec)
ProcesadorRegistrosLento
~1,900
ProcesadorRegistrosRapido
~19,080

Enfoque	Throughput (ops/sec)
`ProcesadorRegistrosLento`	~1,900
`ProcesadorRegistrosRapido`	~19,080

Njda casi 10× de diferencia, mis Bros!!! Estos números varían según CPU, RAM y configuración, pero en cualquier máquina moderna la mejora es evidente. Incluso reducimos la presión del GC y el uso de CPU se desploma.

6. Integración en Spring Boot: Evitando Memory Leaks

Si vas a exponer esto en un servicio REST con Spring Boot, probablemente procesarás peticiones concurrentes en el servlet container (Tomcat, Undertow, etc.). Para no olvidar llamar a MapperPool.remove(), podemos usar un Filter o un AOP Aspect. Aquí un ejemplo con un filtro:

6.1. DemoApplication.java

package com.cesarlead.pool.rest;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;

@SpringBootApplication
public class DemoApplication {
    public static void main(String[] args) {
        SpringApplication.run(DemoApplication.class, args);
    }
}

6.2. MapperPoolFilter.java

package com.cesarlead.pool.rest;

import com.cesarlead.pool.solution.MapperPool;
import jakarta.servlet.FilterChain;
import jakarta.servlet.ServletException;
import jakarta.servlet.http.HttpFilter;
import jakarta.servlet.http.HttpServletRequest;
import jakarta.servlet.http.HttpServletResponse;
import org.springframework.stereotype.Component;

import java.io.IOException;

/**
 * Este filtro se encarga de limpiar el ThreadLocal de MapperPool
 * al final de cada petición HTTP. Así prevenimos memory leaks.
 */
@Component
public class MapperPoolFilter extends HttpFilter {

    @Override
    protected void doFilter(HttpServletRequest request,
                            HttpServletResponse response,
                            FilterChain chain)
                            throws IOException, ServletException {
        try {
            chain.doFilter(request, response);
        } finally {
            // Limpiamos el ObjectMapper del ThreadLocal
            MapperPool.remove();
        }
    }
}

Explicación DRY:

El filtro se declara una sola vez y se aplica a todas las rutas. No necesitas repetir MapperPool.remove() en cada controlador.

Si en el futuro cambias de patrón, solo modificas este filtro y el resto del código permanece intacto.

6.3. RegistroController.java

Un endpoint simple que recibe datos y devuelve JSON:

package com.cesarlead.pool.rest;

import com.cesarlead.pool.problem.RegistroDatos;
import com.cesarlead.pool.solution.ProcesadorRegistrosRapido;
import org.springframework.http.MediaType;
import org.springframework.web.bind.annotation.*;

import java.util.List;

/**
 * Controlador REST para probar el procesamiento.
 */
@RestController
@RequestMapping("/api/registros")
public class RegistroController {

    private final ProcesadorRegistrosRapido procesador = new ProcesadorRegistrosRapido();

    @PostMapping(consumes = MediaType.APPLICATION_JSON_VALUE,
                 produces = MediaType.APPLICATION_JSON_VALUE)
    public String procesar(@RequestBody RegistroDatos data) {
        // Procesamos y devolvemos el JSON serializado
        return procesador.procesarRegistro(data);
    }

    @GetMapping("/demo")
    public String demo() {
        // Ejemplo rígido para probar sin cuerpo
        RegistroDatos sample = new RegistroDatos(999, "Demo", 42.0, List.of("x", "y"));
        return procesador.procesarRegistro(sample);
    }
}

Con esto, cualquier llamada a POST /api/registros terminará pasando por el MapperPoolFilter, y nos aseguramos de limpiar el ThreadLocal sin olvidos.

7. Pruebas Unitarias y de Integración

7.1. Prueba Unitaria de ProcesadorRegistrosRapido

En src/test/java/com/cesarlead/pool/ProcesadorRegistrosRapidoTest.java

package com.cesarlead.pool;

import com.cesarlead.pool.problem.RegistroDatos;
import com.cesarlead.pool.solution.MapperPool;
import com.cesarlead.pool.solution.ProcesadorRegistrosRapido;
import org.junit.jupiter.api.AfterEach;
import org.junit.jupiter.api.Test;

import static org.assertj.core.api.Assertions.*;

class ProcesadorRegistrosRapidoTest {

    private final ProcesadorRegistrosRapido procesador = new ProcesadorRegistrosRapido();

    @AfterEach
    void cleanup() {
        // Limpia el ThreadLocal después de cada test para no contaminar otros tests
        MapperPool.remove();
    }

    @Test
    void procesarRegistro_deberiaRetornarJsonValido() {
        // Arrange
        RegistroDatos datos = new RegistroDatos(5, "Hola Mundo", 99.99, List.of("test", "junit"));

        // Act
        String resultado = procesador.procesarRegistro(datos);

        // Assert
        assertThat(resultado)
            .startsWith("{")
            .contains("\"id\":5", "\"mensaje\":\"Hola Mundo\"", "\"valor\":99.99", "\"etiquetas\":[\"test\",\"junit\"]")
            .endsWith("}");
    }

    @Test
    void procesarRegistro_conNull_deberiaLanzarException() {
        // Arrange
        RegistroDatos datosNull = null;

        // Act & Assert
        assertThatThrownBy(() -> procesador.procesarRegistro(datosNull))
            .isInstanceOf(NullPointerException.class);
    }
}

Notas de Testing:

AssertJ nos da código más legible (assertThat(...)).

Limpieza en @AfterEach con MapperPool.remove() es fundamental para no retener instancias entre tests.

7.2. Prueba de Integración REST con MockMvc

En src/test/java/com/cesarlead/pool/RegistroControllerIntegrationTest.java:

package com.cesarlead.pool;

import com.cesarlead.pool.rest.DemoApplication;
import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.autoconfigure.web.servlet.AutoConfigureMockMvc;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.http.MediaType;
import org.springframework.test.web.servlet.MockMvc;

import static org.springframework.test.web.servlet.request.MockMvcRequestBuilders.*;
import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.*;

/**
 * Pruebas de integración para los endpoints REST.
 */
@SpringBootTest(classes = DemoApplication.class)
@AutoConfigureMockMvc
class RegistroControllerIntegrationTest {

    @Autowired
    private MockMvc mvc;

    @Test
    void postProcesarRegistro_deberiaRetornarJson() throws Exception {
        String requestJson = "{\"id\":7,\"mensaje\":\"Test\",\"valor\":11.11,\"etiquetas\":[\"a\",\"b\"]}";

        mvc.perform(post("/api/registros")
                .contentType(MediaType.APPLICATION_JSON)
                .content(requestJson))
            .andExpect(status().isOk())
            .andExpect(content().contentType(MediaType.APPLICATION_JSON))
            .andExpect(jsonPath("$.id").value(7))
            .andExpect(jsonPath("$.mensaje").value("Test"))
            .andExpect(jsonPath("$.valor").value(11.11))
            .andExpect(jsonPath("$.etiquetas[0]").value("a"))
            .andExpect(jsonPath("$.etiquetas[1]").value("b"));
    }

    @Test
    void getDemo_deberiaRetornarJsonDemo() throws Exception {
        mvc.perform(get("/api/registros/demo"))
            .andExpect(status().isOk())
            .andExpect(content().contentType(MediaType.APPLICATION_JSON))
            .andExpect(jsonPath("$.id").value(999))
            .andExpect(jsonPath("$.mensaje").value("Demo"));
    }
}

Con estas pruebas, cubrimos la serialización rápida y la integración con Spring Boot.

8. Consideraciones Avanzadas y Mejores Prácticas

Memory Leaks y ThreadLocal
- Problemática: Si ejecutas en un servidor con pool de hilos (Tomcat, Undertow, Jetty, o un ExecutorService), los hilos no mueren al procesar una petición; se reutilizan. Si no limpias el ThreadLocal, ese ObjectMapper queda “cacheado” en el hilo, ocupando memoria.
- Solución:
  - Filtros o Interceptors en frameworks (Spring MVC, JAX-RS).
  - Un bloque finally explícito en cada tarea de un ExecutorService.
  - AOP: crear un aspecto que envuelva métodos y haga MapperPool.remove() al salir.
Static final vs. ThreadLocal
- Static final:
  - Si tu configuración de Jackson es sencilla y no cambia en runtime, usar @Bean ObjectMapper en Spring Boot (o static final ObjectMapper) es suficiente y suele ser más simple.
  - Ventajas: Menor complejidad, menos lines of code, menos riesgo de memory leaks.
- ThreadLocal:
  - Útil cuando:
    1. Tu configuración de Jackson es compleja, con módulos y mixins que alguien pudiera reconfigurar dinámicamente.
    2. Quieres aislar el estado de cada hilo (por ejemplo, si en un hilo se registran módulos distintos según el tipo de petición).
  - Desventaja: Debes gestionar limpieza en cada hilo.
Aplicabilidad Más Allá de ObjectMapper

Cualquier objeto costoso de crear y thread-safe (o confinable a un hilo) es candidato:
- Conexiones a bases de datos (DataSource pool).
- Clientes HTTP pesados (ej. HttpClient con pools internos).
- Buffers o ByteBuffer directos (NIO).
- StringBuilder en loops masivos (aunque el JIT a veces lo optimiza).
- Validadores de Bean Validation (ValidatorFactory-based).
¿Cuándo NO usar Object Pool?
- Objetos ligeros (DTO simples, strings, wrappers). El overhead del pool supera el beneficio.
- Objetos usados muy esporádicamente. Mantenerlos en memoria no vale la pena.
- Si no estás en una ruta crítica de rendimiento. No optimices prematuramente: perfila primero.
Soluciones Alternativas
- Apache Commons Pool: Para pools genéricos con tamaño máximo, validación de objetos o recuperación de conexiones.
- Caffeine o Guava Cache: Si tu problema es más de “caching” que de pooling en sí, un cache con expiración y máximos puede servir.
- Frameworks modernos: Si usas Spring Boot, puedes usar un solo "@Bean ObjectMapper" y confiar en que Jackson es thread-safe para serialización.

9. Reflexiones

Mis bros, Vamos a despejar los comentarios más frecuentes:

“Eso del Object Pool ya está obsoleto!!!”
- Respuesta: Los patrones clásicos perduran por algo. Tal como una buena palanca, sigue siendo efectivo cuando encaja. A veces buscamos “frameworks nuevos” y olvidamos que una solución simple funciona de maravilla.
“No, mejor metes @Bean de ObjectMapper en Spring y ya.”
- Respuesta: Cierto, si tu API de Jackson es sencilla y nunca reconfiguras el ObjectMapper en runtime, el bean singleton es suficiente. Pero si en tu equipo alguien empezara a manipular módulos, mixins o cambiar configuración por request (ej. diferentes formatos de fecha según región), un solo bean puede enredarse. Con ThreadLocal, aislas el estado por hilo.
“Pero eso de limpiar el ThreadLocal es un bardo.”
- Respuesta: No hay magia sin costo. Cualquier técnica de pooling o cache requiere limpiar recursos. Con un Filter o un Interceptor, la limpieza es una sola línea y en un solo lugar—bien DRY. Prefiero un filtro limpio a llenar clases de try/finally.
“Tus benchmarks son muy sencillos; en producción todo será distinto.”
- Respuesta: El benchmark es ilustrativo. En un entorno real, tendrás concurrencia real, GC pausas, etc. Sin embargo, si crear un ObjectMapper cuesta ~200–300 μs y procesas decenas de miles por segundo, ese overhead se vuelve el cuello de botella. Muchas empresas (p. ej., servicios de mensajería, pipelines big data) usan pooling para objetos caros y logran mejoras de dos dígitos.
“¿Qué tal la memoria? ¿No aumentan las instancias en cada hilo?”
- Respuesta: Sí, cada hilo en ThreadLocal.withInitial() crea un ObjectMapper. Si tienes 200 hilos, serán 200 instancias. Pero es mejor tener 200 instancias en memoria que crear cientos de miles durante picos de carga. Además, ObjectMapper no es tan grande comparado con un heap de 32 GB.
“Cuándo usaría Apache Commons Pool en lugar de ThreadLocal?”

Cuando necesitas un pool compartido con tamaño limitado, validación de objetos en checkout/checkin, gestión de timeouts o recuperación automática de objetos inválidos. Por ejemplo, conexiones a Redis, sockets o componentes que no son thread-safe.
“Como testeo performance en mi CI/CD?”

Integra JMH en tu pipeline. Por ejemplo, utiliza el plugin de Maven para JMH y define metas de rendimiento. Si tu throughput cae por debajo de X ops/sec, haz que el build falle.
“Qué pasa si quiero configurar el ObjectMapper de forma diferente según el endpoint?”

Puedes parametrizar el ThreadLocal pasando un Supplier<ObjectMapper> que lea una configuración por request (p. ej., un parámetro en el header). Ten cuidado: si varía por request, las instancias se mezclarían en el mismo hilo si no limpias correctamente entre peticiones.
“Como evito memory leaks con pools de hilos en contenedores?”

Siempre llama a remove() en un finally o usa un filtro/global interceptor. Jamás confíes en que el thread “morirá” al terminar la request—en un contenedor, los hilos viven eternamente, y el ThreadLocalMap retiene referencias.

Muchachones, ya tienen un arma potente: Pooling de objetos caros con ThreadLocal. No hay excusas para esas latencias elevadas si tu análisis de profiling apunta a creación masiva de instancias. Implementen, prueben, profilen y confirmen.

Tip Final: Antes de aplicar esta técnica, mide. Usa un profiler (VisualVM, YourKit) y verifica que la creación de instancias es tu cuello de botella. Si no lo es, busca en otro lado. Optimizar sin datos es optimización prematura (KISS + YAGNI en acción).

Optimiza tu Código con el Patrón Object Pool en Java 17