El próximo 21 y 22 de mayo se celebrará la Codemotion Madrid 2024, la conferencia más importante del mundo Tech de Europa. Tras el éxito del año pasado, el evento reunirá a desarrolladores y expertos de la industria de todo elmundo para compartir y discutir las últimas tendencias y tecnologías en el ámbito del desarrollo de software.
De entre la gran variedad de charlas y ponencias programadas para la ocasión, hoy queremos destacar la de “Spring MVC vs Spring Webflux vs Spring MVC con Virtual Threads, ¿quién ganará?”. Correrá a cargo de Gabriel Jiménez Peña, Software Architect and Tech Lead at NEXT DIGITAL HUB, que pondrá a prueba el concepto de “Virtual Thread” recientemente añadido a Java.
Contexto de la charla
La versión 21 de Java trajo consigo diferentes novedades centradas en facilitar la escritura de código y aumentar el rendimiento de las aplicaciones que abordan tareas de forma concurrente. En este contexto, Oracle introdujo un nuevo concepto bajo el nombre de Virtual Threads, una nueva instancia que viene, en teoría, a revolucionar nuestras aplicaciones desarrolladas con este lenguaje.
Hasta el momento, los hilos que usábamos en Java se respaldaban en los llamados “hilos de plataforma”. Estos, normalmente mapeados 1:1 con los hilos del Kernel programados por el sistema operativo, ofrecen un buen rendimiento y robustez, lo que los hace adecuados para ejecutar todo tipo de tareas.
Sin embargo, dependiendo del sistema operativo y la configuración, estos hilos pueden consumir cierta memoria por defecto, incluso si la tarea que se va a realizar no es tan pesada. Cuando hablamos de aplicaciones de alto rendimiento que ejecutan tareas de forma concurrente, esto puede provocar problemas de escalabilidad. Se pueden generar cuellos de botella, lo que restringe el número de hilos que podemos crear sin empezar a tener problemas
Para evitar esto, es posible recurrir a la programación asíncrona. Sin embargo, esta metodología tiene una curva de aprendizaje pronunciada que complica la comprensión y el seguimiento del programa. Cada parte de una solicitud puede ejecutarse en un hilo diferente, creando rastros de pila sin un contexto sensato y haciendo que la depuración se convierta en una tarea demasiado ardua.
Virtual Threads, lo nuevo de Java 21
Los hilos virtuales, una nueva variante ligera de java.lang.Thread, no están atados a un hilo de plataforma específico y no vienen con una gran cantidad de memoria preasignada para ellos. Se programan y gestionan en tiempo de ejecución, no en el sistema operativo subyacente. Esto permite la creación de un número significativamente mayor de hilos ligeros.
Gracias a esto, es más eficiente usar el modelo de «un hilo por solicitud» sin preocuparse por cuántos hilos necesitamos en realidad. Si tu código llama a una operación de E/S bloqueante en un hilo virtual, el tiempo de ejecución suspende el hilo virtual hasta que pueda reanudarse más tarde. De esta manera, el hardware se utiliza a un nivel casi óptimo, lo que resulta en altos niveles de concurrencia y, por lo tanto, en un alto rendimiento.
Además, debido a su bajo coste en cuestiones de recursos, los hilos virtuales no se reutilizan ni necesitan ser agrupados. Cada tarea está representada por su propio hilo virtual.
El programador de tareas es responsable de administrar los hilos de soporte, por lo que se requieren ciertos límites y separaciones para garantizar que los hilos virtuales se ejecuten como se pretende. Esto puede marcar un cambio significativo en la forma en la que pensamos y manejamos la concurrencia en Java, abriendo nuevas posibilidades para el desarrollo de aplicaciones altamente concurrentes.
Poniendo a prueba una de las características más importantes de Java 21
Todos sabemos que la teoría es muy bonita, pero en cuanto nos ponemos manos al código, las cosas cambian y las diferencias se vuelven notables. En el caso que nos ocupa, los hilos virtuales de Java parecen ser el santo Grial que todos estábamos esperando. Pero ¿esto es tan bueno como lo pintan? ¿Merece la pena implementarlo o es puro humo?
Esto es lo que trataremos de descubrir en la charla “Spring MVC vs Spring Webflux vs Spring MVC con virtual threads, ¿quién ganará?”. Tras una breve explicación para repasar todos estos conceptos, pasaremos a la práctica para poner a prueba estos modelos de construcción de aplicaciones.
Para ello, implementaremos una API sencilla en directo construyéndola de 3 formas diferentes:
- Primero, emplearemos el método tradicional con Spring MVC, poniendo a prueba el rendimiento y las posibilidades que ofrece la concurrencia de hilos síncronos.
- Para hacer una comparativa realista, a continuación, implementaremos la misma API empleando Spring Webflux, framework conocido por su enfoque reactivo y su capacidad para manejar un gran número de solicitudes simultáneas de manera eficiente.
- Finalmente, volveremos a implementar la API con Spring MVC, pero esta vez utilizando los hilos virtuales de Java 21, para ver si realmente ofrecen todas las ventajas que prometen.
El objetivo de la charla será aprender cómo funcionan todos estos conceptos y conocer sus principales diferencias. De una forma práctica y divertida, nos haremos una idea de su rendimiento y, entre todos los presentes, podremos decidir quién es el ganador y qué arquitectura es más adecuada según las necesidades de cada proyecto.
La charla se realizará el próximo 21 de mayo. Como en todas las charlas de la Codemotion Madrid 2024, los asistentes podrán participar y exponer sus dudas con total libertad, así que esperamos tu participación para hacerlo más interesante. ¿Te apuntas? Tienes toda la info en la web
Ponente: Gabriel Jiménez Peña
La charla correrá a cargo de Gabriel Jiménez Peña, Software Architect and Tech Lead en NEXT DIGITAL. Acumula 13 años de experiencia desarrollando software con el ecosistema Java, aunque también se ha involucrado en otro tipo de proyectos, desde DevOps y Cloud hasta redes y Big Data. También, le apasiona la formación y, en el último año, ha participado como speaker en varios eventos, entre ellos la edición de Codemotion Madrid 2023. Su lema es: “¿Puedes automatizarlo? ¡Hazlo!”.
