A JetBrains apresenta, em uma publicação de 27 de agosto de 2026, uma análise prática de três componentes do Project Loom no IntelliJ IDEA: Virtual Threads, Scoped Values e Structured Concurrency. A ideia principal não é adicionar APIs separadas, mas tratar de três problemas interligados em aplicações Java concorrentes: escalabilidade, transmissão de contexto entre tarefas e gerenciamento do ciclo de vida das threads e dos erros.
O artigo explica que escrever código multithread continua sujeito a vazamentos de threads, exceções engolidas, condições de corrida e atrasos no cancelamento. Além disso, a dependência tradicional de pools de threads e do CompletableFuture pode fazer com que a lógica de cancelamento e tratamento de erros fique distribuída por vários ramos, aumentando a probabilidade de não ser atualizada quando uma nova tarefa concorrente é adicionada.
Virtual Threads reduzem o custo da espera
As threads virtuais baseiam-se na JEP 444 e são estáveis desde o Java 21. Ao contrário das threads de plataforma, associadas a threads do sistema operacional, as threads virtuais são gerenciadas pela JVM e podem ser criadas a um custo muito menor. A JetBrains informa que criar uma thread virtual leva microssegundos, em vez de milissegundos, e que a thread libera a thread de plataforma quando fica aguardando um banco de dados, uma conexão de rede, um arquivo ou um mecanismo de sincronização.
Isso as torna especialmente adequadas para cargas de trabalho que dependem de operações de bloqueio, pois reduz a necessidade de ajustar previamente o tamanho dos pools de threads. O artigo também menciona que o Java 24 introduziu, por meio da JEP 491, uma melhoria que permite às threads virtuais bloqueadas dentro de métodos ou instruções synchronized liberar a thread de plataforma, em vez de mantê-la ocupada.
Contexto compartilhado sem os problemas de ThreadLocal
Os Scoped Values, estáveis desde o Java 25 de acordo com a JEP 506, tratam de um problema diferente. As aplicações frequentemente precisam transmitir dados como o identificador da sessão ou o identificador de rastreamento para várias partes da solicitação. Isso normalmente era feito com ThreadLocal, mas seus valores podem ser alterados e permanecem associados ao tempo de vida da thread a menos que sejam removidos manualmente, o que pode causar vazamentos de memória ou problemas de segurança. A JetBrains observa que frameworks como o Spring podem usar ThreadLocal internamente mesmo quando o desenvolvedor não o utiliza diretamente.
ScopedValue oferece um modelo baseado na associação do valor uma única vez dentro de um escopo definido, disponibilizando-o automaticamente ao código executado dentro dele e limpando-o quando o escopo termina. A associação não pode ser alterada de dentro do escopo, e o valor é transmitido às tarefas filhas quando usado com concorrência estruturada, sem a necessidade de passar o contexto explicitamente. Na prática, isso reduz o número de pontos de controle que o desenvolvedor precisa acompanhar ao executar tarefas em paralelo.
Structured Concurrency vincula as tarefas a um ciclo de vida claro
A Structured Concurrency, baseada na JEP 533, tem como alvo os problemas estruturais do código concorrente. No entanto, ela ainda está em sua sétima prévia no Java 27 e, por isso, a JetBrains ainda não recomenda seu uso em ambientes de produção. O conceito consiste em tratar um conjunto de tarefas relacionadas como uma única unidade de trabalho, com proprietário, ciclo de vida e política de falhas claros.
No exemplo apresentado pela JetBrains, a aplicação busca em paralelo o histórico de pedidos do cliente e recomendações de produtos para construir o perfil do cliente. Usando StructuredTaskScope, é possível definir um prazo de dois segundos, exigir o sucesso das duas tarefas e cancelar automaticamente a outra tarefa se uma delas falhar ou se o prazo terminar. Em vez de repetir chamadas a cancel() em ramos de tratamento de exceções, a política de cancelamento passa a fazer parte do escopo da tarefa.
O artigo também explica uma situação diferente, que não exige o sucesso de todas as tarefas: se a aplicação obtém recomendações de dois caches e basta a primeira resposta bem-sucedida, pode-se usar anySuccessfulOrThrow(). Quando um resultado bem-sucedido chega, o escopo é fechado e a outra tarefa é cancelada automaticamente; se ambas falharem, é lançada uma exceção que explica a causa da falha.
O que muda no IntelliJ IDEA?
O benefício não se limita à sintaxe do código. Desde o IntelliJ IDEA 2026.1, as threads virtuais criadas dentro de StructuredTaskScope são agrupadas em contêineres que representam seus escopos, tornando visível no depurador a estrutura da relação entre a tarefa pai e as tarefas filhas. Assim, o dump de threads não exibe apenas uma lista plana de threads de um pool geral, mas oferece um indicador melhor das tarefas que pertencem à mesma solicitação.
Para experimentar esses recursos, o desenvolvedor precisa do Java 27, que era uma versão Early Access de acordo com o artigo, além de definir o nível da linguagem para usar os recursos experimentais. O IntelliJ IDEA oferece o download do JDK nas configurações do projeto e também exibe dicas incorporadas ao usar ferramentas como SDKMAN! ou asdf para gerenciar versões do JDK. É possível criar uma estrutura inicial para StructuredTaskScope usando o live template sts.
A leitura editorial da certi.news
A mudança efetiva é a transferência de parte do gerenciamento da concorrência da responsabilidade manual do desenvolvedor para um modelo no qual a estrutura do código expressa o ciclo de vida da tarefa e sua política de falhas. Virtual Threads tratam do custo de escalabilidade, Scoped Values organizam a transmissão de contexto, enquanto Structured Concurrency tenta tornar o cancelamento e a propagação de erros previsíveis. A combinação desses recursos pode reduzir o código repetido em aplicações que executam várias operações de espera em paralelo.
Mas os limites do desenvolvimento são claros: Structured Concurrency ainda não se tornou estável, e o Java 27 era uma versão de acesso antecipado no momento da publicação do artigo. Portanto, a publicação não demonstra que toda aplicação obterá melhorias automaticamente, nem elimina a necessidade de testar o comportamento das bibliotecas e frameworks usados com esses modelos. O valor atual para os desenvolvedores está em compreender o padrão e experimentá-lo com segurança, mantendo os recursos experimentais fora da produção até que suas APIs se estabilizem e haja experiência operacional suficiente.