1. Parámetros Fundamentales del ThreadPoolExecutor

El constructor de ThreadPoolExecutor en Java proporciona siete parámetros configurables que determinan el comportamiento del pool de hilos:

public ThreadPoolExecutor(int nucleosMinimos,
                          int nucleosMaximos,
                          long tiempoEspera,
                          TimeUnit unidadTiempo,
                          BlockingQueue<Runnable> colaTareas,
                          ThreadFactory factoryHilos,
                          RejectedExecutionHandler estrategiaRechazo)

• nucleosMinimos:
  Este valor define la cantidad permanente de hilos que permanecen activos en el pool, incluso cuando no hay tareas pendientes. Si se establece allowCoreThreadTimeOut como verdadero, estos hilos también pueden expirar. Al enviar una nueva tarea, el executor crea nuevos hilos si la cantidad activa es menor que este valor.
  Recomendación: Para tareas limitadas por CPU, establecer aproximadamente igual al número de núcleos disponibles mediante Runtime.getRuntime().availableProcessors(). Para operaciones con bloqueo de E/S, considerar multiplicar por un factor de 1 a 2 según el coeficiente de bloqueo esperado.
• nucleosMaximos:
  Representa el límite máximo de hilos que el pool puede crear. Cuando la cola de tareas está llena y existen hilos disponibles por debajo de este límite, el executor genera hilos adicionales para procesar la carga acumulada.
  Recomendación: Configurar significativamente superior a nucleosMinimos para absorber picos de carga. Valores excesivamente altos incrementan el consumo de memoria y el coste de cambios de contexto de la CPU.
• tiempoEspera:
  Define el período que los hilos superfluos (aquellos que exceden nucleosMinimos) permanecen inactivos antes de ser terminados. Pasado este tiempo sin recibir nuevas tareas, estos recursos son liberados.
  Recomendación: Aumentar para sistemas con alta variabilidad de carga y reducir para entornos con tráfico constante y predecible.
• unidadTiempo:
  Unidad de medida para tiempoEspera: segundos, milisegundos, microsegundos o nanosegundos.
• colaTareas:
  Estructura de datos que almacena las tareas pendientes de ejecución cuando todos los hilos activos están ocupados. Las opciones principales incluyen:
  • ArrayBlockingQueue: Cola finita con array subyacente, orden FIFO. Ideal cuando el volumen de tareas es predecible.
  • LinkedBlockingQueue: Cola teóricamente ilimitada basada en nodos enlazados. Puede provocar overflow de memoria si la producción supera al consumo.
  • SynchronousQueue: Cola sin almacenamiento real donde cada inserción debe esperar una extracción correspondiente. Útil para ejecución inmediata o rechazo inmediato.
  • PriorityBlockingQueue: Cola infinita que respeta prioridades definidas por Comparable.
• factoryHilos:
  Interfaz para personalizar la creación de nuevos hilos. Permite establecer nombres descriptivos, configurar como daemon threads, asignar prioridades personalizadas, entre otras opciones.
  Recomendación: Utilizar implementaciones como ThreadFactoryBuilder de Guava o CustomizableThreadFactory de Spring para facilitar el debugging.
• estrategiaRechazo:
  Política aplicada cuando tanto el pool como la cola de tareas están saturados y no aceptan nuevas tareas.

2. Estrategias de Rechazo: Cuándo Utilizar Cada Una

Java ofrece cuatro políticas predefinidas más la opción de implementar personalizadas:

• AbortPolicy (configuración por defecto):
  Lanza una excepción RejectedExecutionException inmediatamente. Utilizar cuando no se puede tolerar ninguna pérdida de tarea y se requiere notificación inmediata de sobrecarga. El código cliente debe capturar y manejar la excepción apropiadamente.
• CallerRunsPolicy:
  Ejecuta la tarea rejected en el hilo que intentó submitirla. Esto frena naturalmente la tasa de submissions al bloquear el hilo llamador. Efectivo como mecanismo de back-pressure automático.
• DiscardPolicy:
  Elimina silenciosamente la tarea sin notificación alguna. Apropiado para operaciones de logging, métricas o procesamiento analítico donde pérdida parcial de datos es aceptable.
• DiscardOldestPolicy:
  Elimina la tarea más antigua de la cola y reintenta insertar la actual. Mantiene las tareas más recientes mientras desecha las que han esperado más tiempo.
• Implementación Personalizada:
  Para requisitos específicos, implementar la interfaz RejectedExecutionHandler permitiendo escribir a disco, enviar a colas de mensajes o ejecutar lógica de recuperación compleja.

3. Configuración Recomendada en SpringBoot

3.1 ThreadPoolTaskExecutor de Spring

Spring proporciona ThreadPoolTaskExecutor como wrapper sobre ThreadPoolExecutor con integración al lifecycle del contenedor:

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.scheduling.annotation.EnableAsync;
import org.springframework.scheduling.concurrent.ThreadPoolTaskExecutor;

import java.util.concurrent.Executor;
import java.util.concurrent.ThreadPoolExecutor;

@Configuration
@EnableAsync
public class ConfiguradorAsync {

    @Bean("ejecutorTareas")
    public Executor configurarExecutor() {
        ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
        
        int nucleosCPU = Runtime.getRuntime().availableProcessors();
        
        // Hilos base para mantener activos continuamente
        executor.setCorePoolSize(nucleosCPU);
        
        // Capacidad máxima durante picos de carga
        executor.setMaxPoolSize(nucleosCPU * 2);
        
        // Cola con límite para prevenir consumo excesivo de memoria
        executor.setQueueCapacity(150);
        
        // Duración de vida de hilos auxiliares
        executor.setKeepAliveSeconds(120);
        
        // Prefijo para identificación en logs
        executor.setThreadNamePrefix("ProcesamientoAsync-");
        
        // Política de rechazo según requisitos del negocio
        executor.setRejectedExecutionHandler(
            new ThreadPoolExecutor.CallerRunsPolicy()
        );
        
        // Limpieza ordenada al cerrar el contexto
        executor.setWaitForTasksToCompleteOnShutdown(true);
        executor.setAwaitTerminationSeconds(90);
        
        executor.initialize();
        return executor;
    }
}

3.2 Uso de @Async en Servicios

Una vez configurado el bean, las clases de servicio pueden ejecutar métodos de forma asíncrona:

import org.springframework.scheduling.annotation.Async;
import org.springframework.stereotype.Service;

@Service
public class GestorProcesos {

    @Async("ejecutorTareas")
    public void ejecutarTareaAsincrona(String identificador) {
        String nombreHilo = Thread.currentThread().getName();
        System.out.println("Procesando identificador: " + identificador 
            + " en hilo: " + nombreHilo);
        
        try {
            Thread.sleep(3000);
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        }
    }

    public void invocarProceso() {
        System.out.println("Invocador desde: " + Thread.currentThread().getName());
        ejecutarTareaAsincrona("SOLICITUD-001");
    }
}

3.3 Directrices de Optimización

1. Dimensionamiento según naturaleza de tareas:
   Para operaciones CPU-bound, nucleosMinimos cercano a nucleosCPU con nucleosMaximos similar. Para operaciones I/O-bound, multiplicar nucleosCPU por un coeficiente entre 1.5 y 4 veces según el tiempo de espera de E/S esperado.
2. Capacidad de cola apropiada:
   Utilizar colas delimitadas siempre que sea posible. Capacidad pequeña genera demasiados rechazos; capacidad excesiva oculta problemas de diseño y retrasa respuestas.
3. Selección de estrateiga de rechazo:
   Procesos críticos necesitan AbortPolicy o CallerRunsPolicy con manejo de excepciones robusto. Operaciones secundarias toleran DiscardPolicy o DiscardOldestPolicy.
4. ThreadFactory significativa:
   Asignar prefijos descriptivos que incluyan el contexto del pool para simplificar aálisis de logs y resolución de problemas.
5. Observabilidad:
   Recolectar métricas mediante JMX, Micrometer o herramientas como Prometheus. Monitorear: hilos activos, tamaño de cola, tareas completadas y rechazos. Configurar alertas cuando las métricas se aproximen a umbrales críticos.

El ajuste de thread pools requiere iteración basada en medición real. Sin benchmarks y monitoreo continuo, cualquier configuración permanece como hipótesis. Adaptar estos parámetros al patrón de carga específico de cada aplicación garantiza sistemas responsivos y estables bajo condiciones de producción.