Los hilos virtuales de Java en resumen: qué cambia y qué no

Qué es

La JEP 444 describe un hilo virtual como una instancia de java.lang.Thread que no está ligada uno a uno a un hilo del sistema operativo. Un planificador (un ForkJoinPool en modo FIFO cuyo paralelismo por defecto es el número de procesadores disponibles) monta un hilo virtual sobre un hilo de plataforma, su portador (carrier); cuando el hilo virtual se bloquea en una operación de E/S u otra operación bloqueante del JDK, se desmonta y el portador toma otro trabajo. Las pilas residen en el heap como objetos stack-chunk y crecen y se reducen. Thread.ofVirtual(), Thread.startVirtualThread(r) y Executors.newVirtualThreadPerTaskExecutor() los crean, y siempre son hilos daemon. La JEP es explícita en que los hilos virtuales no son hilos más rápidos: ofrecen escala (rendimiento agregado), no velocidad (latencia), y el trabajo limitado por CPU no gana nada al tener más hilos de los que hay núcleos.

Por qué importa

Para quienes llegan desde Go o desde async de C#, el punto es que Java conserva el estilo de un hilo por solicitud, incluidos los bucles, try/catch y las llamadas JDBC o HTTP bloqueantes habituales, a la vez que elimina el límite de hilos del sistema operativo que empujaba el código hacia canalizaciones reactivas o basadas en CompletableFuture. El código construido sobre ExecutorService migra simplemente cambiando el executor, razón por la cual la JEP ofrece Executors.newThreadPerTaskExecutor junto con la fábrica de hilos virtuales.

Cómo aplicarlo

• No agrupar los hilos virtuales en un pool; crear uno por tarea. Para limitar la concurrencia hacia un recurso posterior, usar un Semaphore, que tanto la JEP como la guía de bibliotecas centrales señalan como el mecanismo previsto.
• Revisar el uso de ThreadLocal: una caché local al hilo de un objeto costoso, sensata en un pool de cincuenta hilos, se crea por cada solicitud bajo hilos virtuales. La JEP señala los scoped values como alternativa.
• Comprobar el anclaje (pinning): en JDK 21, un hilo virtual que se bloquea dentro de un bloque o método synchronized, o dentro de un marco nativo, ancla a su portador. -Djdk.tracePinnedThreads=full y el evento JFR jdk.VirtualThreadPinned (activado por defecto con un umbral de 20 ms) muestran dónde. La JEP 491 en JDK 24 elimina el anclaje para synchronized y Object.wait(), y descarta la propiedad jdk.tracePinnedThreads (el evento JFR se mantiene); los marcos nativos, la carga de clases y los inicializadores de clase siguen anclando.
• Hay que esperar que los volcados de hilos planos resulten inútiles con un millón de hilos; la JEP añade jcmd <pid> Thread.dump_to_file -format=json.
• Mantener los hilos de plataforma para bucles limitados por CPU y para trabajo que nunca se bloquea.

Trampas

Algunas operaciones bloqueantes (muchas llamadas al sistema de archivos, Object.wait() antes de JDK 24) capturan el hilo del sistema operativo; el planificador compensa temporalmente hasta jdk.virtualThreadScheduler.maxPoolSize. Las bibliotecas que retienen monitores alrededor de operaciones de E/S limitan la escalabilidad hasta que se actualizan. Los frameworks deben habilitarlo explícitamente (opt in); un servidor que sigue con un pool fijo de hilos de plataforma no ve ningún cambio. La concurrencia estructurada, una JEP aparte, es la forma prevista de gestionar grupos de hilos virtuales.