JetBrains explica cómo las funcionalidades de Project Loom combinan los hilos virtuales, los valores con alcance y la concurrencia estructurada para reducir el coste de la concurrencia y la complejidad de su gestión en Java. El artículo aclara que Structured Concurrency sigue siendo una funcionalidad experimental en Java 27, mientras que Virtual Threads es estable desde Java 21 y Scoped Values desde Java 25.
JetBrains ofrece en una entrada publicada el 27 de agosto de 2026 una lectura práctica de tres componentes de Project Loom dentro de IntelliJ IDEA: Virtual Threads, Scoped Values y Structured Concurrency. La idea fundamental no es añadir interfaces de programación separadas, sino abordar tres problemas interrelacionados en las aplicaciones Java concurrentes: la escalabilidad, la transmisión del contexto entre tareas y la gestión del ciclo de vida de los hilos y los errores.
El artículo explica que escribir código multihilo sigue siendo susceptible a fugas de hilos, excepciones absorbidas, condiciones de carrera y retrasos en la cancelación. Además, la dependencia tradicional de los grupos de hilos y CompletableFuture puede hacer que la lógica de cancelación y gestión de errores se distribuya entre varias ramas, lo que aumenta la probabilidad de que no se actualice al añadir una nueva tarea concurrente.
Los hilos virtuales reducen el coste de la espera
Los hilos virtuales se basan en JEP 444 y son estables desde Java 21. A diferencia de los hilos de plataforma vinculados a hilos del sistema operativo, los hilos virtuales son gestionados por la JVM y pueden crearse con un coste mucho menor. JetBrains señala que crear un hilo virtual tarda microsegundos en lugar de milisegundos, y que el hilo libera el hilo de plataforma cuando queda esperando una base de datos, una conexión de red, un archivo o un mecanismo de sincronización.
Esto los hace especialmente adecuados para cargas de trabajo que dependen de operaciones bloqueantes, ya que reduce la necesidad de ajustar de antemano el tamaño de los grupos de hilos. El artículo también menciona que Java 24 introdujo, mediante JEP 491, una mejora que permite que los hilos virtuales bloqueados dentro de métodos o sentencias synchronized liberen el hilo de plataforma en lugar de mantenerlo ocupado.
Contexto compartido sin los problemas de ThreadLocal
Scoped Values, estables desde Java 25 según JEP 506, aborda un problema diferente. Las aplicaciones suelen necesitar transmitir datos como el identificador de sesión o el identificador de seguimiento a varias partes de una solicitud. Normalmente esto se hacía mediante ThreadLocal, pero sus valores se pueden modificar y permanecen vinculados a la vida útil del hilo a menos que se eliminen manualmente, lo que puede provocar fugas de memoria o problemas de seguridad. JetBrains señala que marcos como Spring pueden utilizar ThreadLocal internamente incluso cuando el desarrollador no lo usa directamente.
ScopedValue ofrece un modelo basado en vincular el valor una sola vez dentro de un ámbito concreto y ponerlo después automáticamente a disposición del código que se ejecuta en él, eliminándolo al finalizar el ámbito. El vínculo no puede modificarse desde dentro del ámbito, y el valor se transmite a las tareas hijas al utilizarlo con la concurrencia estructurada sin pasar el contexto explícitamente. En la práctica, esto reduce el número de puntos de control que el desarrollador debe seguir al ejecutar tareas en paralelo.
La concurrencia estructurada vincula las tareas a una vida útil clara
Structured Concurrency, basada en JEP 533, tiene como objetivo los problemas estructurales del código concurrente. Sin embargo, sigue en su séptima vista previa dentro de Java 27, por lo que JetBrains todavía no recomienda utilizarla en entornos de producción. El concepto consiste en tratar un conjunto de tareas relacionadas como una única unidad de trabajo con un propietario, una vida útil y una política de fallos claros.
En el ejemplo que presenta JetBrains, la aplicación obtiene en paralelo el historial de pedidos del cliente y las recomendaciones de productos para crear el perfil del cliente. Mediante StructuredTaskScope, se puede establecer un tiempo de espera de dos segundos, exigir que ambas tareas tengan éxito y cancelar automáticamente la otra tarea si una de ellas falla o se agota el tiempo de espera. En lugar de repetir llamadas a cancel() en las ramas de gestión de excepciones, la política de cancelación pasa a formar parte del ámbito de la tarea.
El artículo también explica un caso diferente que no requiere que todas las tareas tengan éxito: si la aplicación obtiene las recomendaciones de dos cachés y le basta con la primera respuesta correcta, puede utilizar anySuccessfulOrThrow(). Cuando llega un resultado correcto, el ámbito se cierra y la otra tarea se cancela automáticamente; si ambas tareas fallan, se lanza una excepción que explica la causa del fallo.
¿Qué cambia dentro de IntelliJ IDEA?
La utilidad no se limita a la sintaxis del código. Desde IntelliJ IDEA 2026.1, los hilos virtuales creados dentro de StructuredTaskScope se agrupan en contenedores que representan sus ámbitos, lo que hace visible en el depurador la estructura de la relación entre la tarea principal y las tareas hijas. Así, el volcado de hilos no muestra únicamente una lista plana de hilos de un grupo general, sino que ofrece un indicador más claro de las tareas que pertenecen a la misma solicitud.
Para probar estas funcionalidades, el desarrollador necesita Java 27, que según el artículo era una versión Early Access, además de configurar el nivel del lenguaje para utilizar las funcionalidades experimentales. IntelliJ IDEA permite descargar el JDK desde la configuración del proyecto y también muestra sugerencias integradas al utilizar herramientas como SDKMAN! o asdf para gestionar las versiones del JDK. Se puede crear una estructura inicial de StructuredTaskScope mediante la plantilla en vivo sts.
La lectura editorial de certi.news
El cambio real consiste aquí en trasladar parte de la gestión de la concurrencia de la responsabilidad manual del desarrollador a un modelo en el que la estructura del código expresa la vida útil de la tarea y su política de fallos. Virtual Threads aborda el coste de la escalabilidad, Scoped Values regula la transmisión del contexto, mientras que Structured Concurrency intenta hacer predecibles la cancelación y la propagación de errores. La combinación de estas funcionalidades puede reducir el código repetido en aplicaciones que ejecutan varias operaciones de espera en paralelo.
Pero los límites de la evolución son claros: Structured Concurrency todavía no es estable y Java 27 era una versión de acceso anticipado en el momento de publicarse el artículo. Por tanto, la entrada no demuestra que todas las aplicaciones vayan a obtener automáticamente una mejora ni elimina la necesidad de probar el comportamiento de las bibliotecas y los marcos utilizados con estos modelos. El valor actual para los desarrolladores consiste en comprender el patrón y probarlo de forma segura, manteniendo las funcionalidades experimentales fuera de producción hasta que sus interfaces se estabilicen y exista suficiente experiencia operativa.