Threads virtuais em Java em linhas gerais: o que muda e o que não muda

O que é

A JEP 444 descreve uma thread virtual como uma instância de java.lang.Thread que não está ligada de forma um para um a uma thread do sistema operacional. Um escalonador (um ForkJoinPool em modo FIFO, cujo paralelismo padrão é o número de processadores disponíveis) monta a thread virtual em uma thread de plataforma, o seu carrier. Quando a thread virtual bloqueia em E/S ou em outra operação bloqueante do JDK, ela é desmontada e o carrier passa a executar outro trabalho. As pilhas ficam no heap como objetos stack chunk e crescem e encolhem. Thread.ofVirtual(), Thread.startVirtualThread(r) e Executors.newVirtualThreadPerTaskExecutor() criam threads virtuais, que são sempre threads daemon. A JEP deixa claro que threads virtuais não são threads mais rápidas: elas oferecem escala (vazão), não velocidade (latência), e o trabalho limitado por CPU não ganha nada por haver mais threads virtuais do que núcleos.

Por que importa

Para quem vem de Go ou do async do C#, o ponto é que o Java mantém o estilo thread por requisição, com laços, try/catch e chamadas JDBC ou HTTP bloqueantes comuns, e elimina o teto de threads do sistema operacional que empurrava o código para pipelines reativos ou com CompletableFuture. O código baseado em ExecutorService migra trocando o executor, e é por isso que a JEP oferece Executors.newThreadPerTaskExecutor ao lado da fábrica de threads virtuais.

Como aplicar

• Não faça pool de threads virtuais; crie uma por tarefa. Para limitar a concorrência em direção a um recurso downstream, use um Semaphore, que tanto a JEP quanto o guia de bibliotecas centrais indicam como a construção pretendida.
• Revise o uso de ThreadLocal: um cache em thread-local de um objeto caro, sensato num pool de cinquenta threads, passa a ser criado a cada requisição com threads virtuais. A JEP aponta os scoped values como alternativa.
• Verifique o pinning (fixação): no JDK 21, uma thread virtual que bloqueia dentro de um bloco ou método synchronized, ou dentro de um frame nativo, fixa o seu carrier. -Djdk.tracePinnedThreads=full e o evento JFR jdk.VirtualThreadPinned (habilitado por padrão, com limite de 20 ms) mostram onde isso ocorre. A JEP 491 no JDK 24 remove o pinning para synchronized e Object.wait() e elimina a propriedade jdk.tracePinnedThreads (o evento JFR permanece); frames nativos, carregamento de classes e inicializadores de classe ainda fixam o carrier.
• Espere que thread dumps planos sejam inúteis com um milhão de threads; a JEP adiciona jcmd <pid> Thread.dump_to_file -format=json.
• Mantenha threads de plataforma para laços limitados por CPU e para trabalho que nunca bloqueia.

Armadilhas

Algumas operações bloqueantes (muitas chamadas ao sistema de arquivos, Object.wait() antes do JDK 24) capturam a thread do sistema operacional; o escalonador compensa temporariamente, até jdk.virtualThreadScheduler.maxPoolSize. Bibliotecas que mantêm monitores em torno de E/S limitam a escala até serem atualizadas. Os frameworks precisam aderir explicitamente; um servidor que continua com um pool fixo de threads de plataforma não vê mudança alguma. A concorrência estruturada, objeto de uma JEP separada, é a forma prevista de gerenciar grupos de threads virtuais.