Hilos Virtuales en Java: Escalabilidad sin Complejidad

El Problema de la Concurrencia Tradicional

Las aplicaciones Java han dependido históricamente de los hilos de plataforma (Platform Threads o hilos tradicionales) para la concurrencia.

Hilos de Plataforma (HT):

• Son wrappers alrededor de los hilos gestionados por el Sistema Operativo (OS) con un mapeo 1
  .
• Son costosos y pesados, ya que cada uno consume ~1-2 MB de memoria y recursos del OS.
• Su número está limitado por los recursos del sistema. Crear demasiados puede llevar a OutOfMemoryError o saturar el contexto switching.
• En aplicaciones web, el modelo "un hilo por solicitud" (Thread-per-Request) es intuitivo, pero no escala bien con alta concurrencia (ej. >10k requests concurrentes).

La Necesidad: En escenarios de alta concurrencia como microservicios, streaming o APIs de trading, se requiere baja latencia y alta escalabilidad. Soluciones como programación reactiva (Project Reactor, RxJava) mejoran el throughput pero complican el código y la depuración.

¿Qué Son los Hilos Virtuales (HV)?

Introducidos por Project Loom y estabilizados en JDK 21 (JEP 444), los Hilos Virtuales son la solución de Java para concurrencia masiva sin programación asíncrona.

Características Clave:

• Hilos Ligeros: Instancias de java.lang.Thread gestionadas por la JVM (~1 KB por hilo).
• Millones de Hilos: Permiten crear millones de hilos sin agotar memoria.
• Escalabilidad I/O-bound: Optimizados para throughput en tareas bloqueantes (no speed-up en CPU-bound).
• Compatibilidad Total: Drop-in replacement para código Thread existente. Similares a goroutines de Go.
• Disponibles en JDK 21+: Estables desde JDK 21; mejoras continuas en JDK 22-25.

Funcionamiento Interno: M

Scheduling

Mapeo M:N: M hilos virtuales (millones) sobre N hilos de plataforma (núcleos CPU).

1. Carriers: Hilo de plataforma que "lleva" un HV.
2. Mount/Unmount: HV se monta en carrier para ejecutar; se desmonta en bloqueos I/O (sleep(), sockets, DB queries).
3. Scheduler JVM: Reasigna carriers dinámicamente. Carrier queda libre durante esperas I/O.
4. Continuación: Al completarse I/O, HV vuelve al scheduler y se remonta en cualquier carrier.

Esto maximiza utilización de CPU: carriers siempre busy.

Actualizaciones Recientes:

• JDK 24 (JEP 491): Eliminó pinning en bloques synchronized (HV se desmontan correctamente).
• JDK 25 (JEP 506): Scoped Values como alternativa inmuntable a ThreadLocal, previniendo memory leaks en HV.

Ejemplos Prácticos

Optimizados para I/O-bound (HTTP, DB, files).

Thread.startVirtualThread(() -> {
    System.out.println("¡Hola desde HV! " + Thread.currentThread());
});

import java.util.concurrent.Executors;
import java.time.Duration;

try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
    // 10k tareas concurrentes
    IntStream.range(0, 10_000).forEach(i ->
        executor.submit(() -> {
            Thread.sleep(Duration.ofSeconds(1)); // Simula I/O
            // Lógica business
        })
    );
} // Auto-awaits completion

@RestController
public class ApiController {
    @GetMapping("/data")
    String getData() {
        // HV maneja request automáticamente en Tomcat/Undertow con config
        return fetchFromDb(); // Bloquea pero escala
    }
}

Consideraciones Avanzadas y Mejores Prácticas

Resumen Final

Metáfora: HT = Ascensores dedicados por persona (caros). HV = Sistema de tubos neumáticos: miles de cápsulas livianas en pocos tubos físicos.

Fuentes: OpenJDK JEPs, benchmarks Spring Boot (Reddit/Java 24), guías RockTheJVM/RabinaNPatra (2025).