Los hilos virtuales: concurrencia sin pool

Un servidor Java clásico procesa cada petición en un hilo tomado de un pool. Ese hilo es un hilo del sistema operativo: cuesta aproximadamente un megabyte de pila reservada, su creación se mide en cientos de microsegundos y el kernel debe planificarlo. Por eso se mantienen pocos (doscientos, cuatrocientos) y se reciclan. Ahora bien, ¿qué hace ese hilo durante la petición? Espera. Espera a PostgreSQL durante ocho milisegundos, luego a un servicio HTTP de terceros durante cien, luego a Redis. En una petición de ciento cincuenta milisegundos, el procesador trabaja quizá tres milisegundos. El resto del tiempo, un recurso escaso y caro permanece inmovilizado sin hacer nada.

Cuando la carga supera el tamaño del pool, las peticiones se acumulan en una cola. El tiempo de respuesta se desploma mientras los procesadores están al diez por ciento de utilización. La respuesta habitual a este muro consiste en pasar a la programación reactiva: nada de bloqueos, callbacks, CompletableFuture o flujos reactivos. Funciona, pero sale caro: el código se da la vuelta, las pilas de llamadas se vuelven inservibles, el depurador ya no las sigue y toda la cadena debe ser no bloqueante, bajo pena de perder todo el beneficio. Los hilos virtuales, estabilizados en Java 21, proponen conservar el código bloqueante, secuencial y legible, haciendo que el propio hilo resulte casi gratuito.