La semana pasada vimos Project Leyden: 41% más rápido, sin tocar código. Pero tiene un "pero" importante: te pide JDK 24 o más nuevo. Y si trabajas en un banco o una fintech clavados en Java 11 o 17, esa puerta está cerrada por ahora.
Así que hoy te traigo el avance que ya está en tu JDK desde la versión 21, que la mayoría de equipos que he visto ni siquiera conoce, y que te deja borrar la mitad de tu código reactivo con una sola línea de configuración.
Hablo de Virtual Threads. Y para mí es el cambio más importante en cómo escribimos Java en veinte años.
Si alguna vez tocaste Spring WebFlux, conoces el dolor: flatMap, Mono, Flux, stack traces que no dicen nada, juniors que tardan meses en entender el código.
Pero WebFlux no nació por capricho. Nació porque los threads de Java eran caros. Cada thread tradicional cuesta uno o dos megas de stack. Con 200 threads solo atiendes 200 requests, y si una se queda esperando a la base de datos, ese thread queda parado, desperdiciado. WebFlux era la forma de no desperdiciarlos, a costa de reescribir tu código en estilo reactivo.
Virtual Threads atacan el problema de raíz: son threads que cuestan kilobytes, no megabytes. Puedes crear un millón. Y cuando uno se bloquea esperando I/O, la JVM lo aparca y reutiliza el thread real del sistema para otro. Todo transparente, sin que cambies tu forma de escribir.
¿Cómo lo enciendes en Spring Boot? Una línea:
spring.threads.virtual.enabled=true
Sin embargo, no puedo decirte que "virtual threads le gana a WebFlux y se acabó". Para REST APIs normales, con JDBC, con código bloqueante, virtual threads igualan o ganan y te dejan un código muchísimo más simple. Pero si tu stack es 100% reactivo (R2DBC), o haces streaming con WebSockets, o manejas concurrencia extrema, WebFlux todavía tiene la ventaja. En el video lo muestro con los benchmarks y un cuadro de cuándo usar cada uno.
Te digo mi opinión y recomendación personal: si hoy arrancas un proyecto REST nuevo en Spring, no toques WebFlux. Virtual threads te dan el 90% del beneficio con el 10% de la complejidad. WebFlux quedó para streaming y para los casos extremos. Y eso, para mí, no es una optimización más: es un cambio de cómo escribimos Java.
Eso no es todo lo que te voy a dar el día de hoy, acabo de subir un video donde hay mucho más que aquí no cabe.
Por ejemplo, allá te hablo de una mejora de performance exclusiva de AWS que permite mejorar hasta el 94% del startup en Java, y te hablo de algo que puedes aplicar desde Java 12 para mejorar un 25% el startup de tu aplicación.
3 herramientas clave que NO estás usando
La próxima semana cierro la serie con el episodio que más me piden y el más polémico: Java contra Go en 2026, con benchmarks y metodología, sin maquillar dónde Go todavía gana.