Questão de Programação — Plataforma Java — CESPE / CEBRASPE 2025

Threads virtuais no Java 21

Gabarito: letra C. O trecho de código, ao utilizar Executors.newVirtualThreadPerTaskExecutor(), cria threads virtuais que são automaticamente descartadas após a execução da tarefa. Threads virtuais são uma feature do Java 21 (JEP 444) que permite criar um grande número de threads leves, gerenciadas pela JVM, e não diretamente pelo sistema operacional.

Threads virtuais são uma abstração da JVM que desacopla o ciclo de vida de uma thread do ciclo de vida de uma thread do sistema operacional. Enquanto uma thread tradicional (plataforma) é mapeada 1:1 para uma thread do SO, uma thread virtual é um objeto Java que a JVM agenda sobre um pequeno número de threads do SO (chamadas de carrier threads). Isso permite que uma aplicação crie milhões de threads virtuais sem esgotar os recursos do sistema, pois elas são extremamente leves em termos de memória e overhead de criação.

A principal vantagem é a escalabilidade: em aplicações com muitas operações de I/O (como servidores web), cada requisição pode ser tratada por uma thread virtual dedicada, que fica bloqueada durante a operação de I/O sem consumir uma thread do SO. Quando a operação de I/O é concluída, a thread virtual é retomada. Isso simplifica o modelo de programação concorrente, pois o desenvolvedor pode usar o modelo tradicional de thread-per-request sem se preocupar com o custo de criar threads.

No Java 21, a API Executors foi estendida com métodos que criam executors baseados em threads virtuais. O método newVirtualThreadPerTaskExecutor() cria um ExecutorService que, para cada tarefa submetida, cria uma nova thread virtual. Essa thread virtual executa a tarefa e, ao final, é descartada — não fica em estado de execução contínua nem é reutilizada para outras tarefas. O ciclo de vida é: criar, executar, descartar.

A pegadinha da questão está em confundir threads virtuais com threads do sistema operacional. A alternativa B afirma que as threads serão gerenciadas diretamente pelo SO, o que é falso: threads virtuais são gerenciadas pela JVM. A alternativa E fala em "threads físicas", que é um termo incorreto para threads do SO. A alternativa D afirma que as threads ficarão em execução contínua, o que não ocorre, pois elas são descartadas após a tarefa. A alternativa A fala em "pool fixo de threads virtuais", mas o método newVirtualThreadPerTaskExecutor() não cria um pool fixo — cria uma nova thread virtual para cada tarefa.

Guarde a distinção central: thread virtual = gerenciada pela JVM, leve, descartável após a tarefa; thread de plataforma = gerenciada pelo SO, pesada, reutilizável. É exatamente nessa fronteira que as alternativas se dividem.

Alternativa A — ❌ Incorreta

Afirma que o código cria um ExecutorService com um pool fixo de threads virtuais. O método newVirtualThreadPerTaskExecutor() não cria um pool fixo — ele cria uma nova thread virtual para cada tarefa submetida, sem reutilização. Um pool fixo seria criado com Executors.newFixedThreadPool(n), que mantém um número fixo de threads reutilizáveis. A confusão está em associar o executor a um pool, quando na verdade o comportamento é per-task.

Alternativa B — ❌ Incorreta

Afirma que as threads serão gerenciadas diretamente pelo sistema operacional. Isso é falso para threads virtuais: elas são gerenciadas pela JVM, que as agenda sobre um pequeno número de threads do SO (carrier threads). A gestão direta pelo SO é característica das threads de plataforma (tradicionais), não das virtuais. A banca explora a confusão entre os dois tipos de thread.

Alternativa C — ✅ Correta ⟵ GABARITO

O método newVirtualThreadPerTaskExecutor() cria, para cada tarefa submetida, uma nova thread virtual que a executa e, ao final, é automaticamente descartada. Não há reutilização nem manutenção de um pool. Esse é exatamente o comportamento descrito na alternativa: threads virtuais descartadas após a execução da tarefa.

Alternativa D — ❌ Incorreta

Afirma que as threads virtuais ficarão em estado de execução contínua. Isso é falso: após a execução da tarefa, a thread virtual é descartada e não permanece em execução. A alternativa confunde o ciclo de vida de uma thread virtual (criar-executar-descartar) com um cenário de execução contínua, que não é o caso.

Alternativa E — ❌ Incorreta

Fala em "threads físicas compatíveis com o método submit()". O termo "threads físicas" não é uma nomenclatura padrão; o correto seria "threads de plataforma" ou "threads do sistema operacional". Além disso, o método submit() é compatível com qualquer ExecutorService, mas o código em questão usa threads virtuais, não threads de plataforma. A alternativa mistura conceitos e usa terminologia imprecisa.

Gabarito: letra C