E aí, dev que vive de ExecutorServicee CompletableFuture? Já tentou criar 10 mil threads na mão? O OutOfMemoryError vem cantando. Isso porque as threads clássicas do Java (agora chamadas de platform threads) são, basicamente, wrappers finos de threads do sistema operacional. Elas são caras – cada uma consome cerca de 20 MB de memória só de pilha (stack).

Mas a partir do JDK 21, temos as virtual threads – leves, baratas. Vamos entender sem mistério.

⚠️ Qual é o problema das Platform Threads (as de sempre)?

Uma thread de plataforma = uma thread do SO.


Isso é caro em tempo (criação lenta) e espaço (stack enorme: ~20 MB).


O escalonador do SO também tem trabalho para trocar o contexto entre elas.

Faça as contas: numa máquina com 8 GB de RAM, cabem no máximo umas 400 threads (8.000 MB / 20 MB = 400). Se essas threads ficarem a maior parte do tempo esperando I/O (como acesso a banco, chamadas HTTP), o CPU fica ocioso – você mal usa o hardware.

Exemplo: uma thread trabalha 0,001 ms preparando um request, depois espera 100 ms pela resposta da rede. Nesse cenário, ela fica parada 99,99% do tempo. Com 400 threads, o uso de CPU é menor que 1%. Um desperdício.

A solução tradicional? Usar pools de threads, CompletableFuture, programação reativa (Mono/Flux). Mas o código fica mais complexo, cheio de callbacks.

✨ Virtual Threads – a revolução

Virtual threads são leves – cada uma ocupa poucos bytes (não megabytes) e vivem no heap da JVM, não na pilha do SO. Criar uma virtual thread é ~1000 vezes mais barato que uma platform thread. Elas são gerenciadas pelo próprio JVM, não pelo escalonador do SO.

A arquitetura é de muitos para poucos: milhões de virtual threads rodam em cima de um pequeno número de platform threads (as velhas conhecidas). Cada platform thread executa uma virtual thread por vez, e quando a virtual thread bloqueia (ex: aguardando I/O), a JVM desmonta ela dali e a platform thread pega outra virtual thread pronta. Isso chama-se escalonamento cooperativo – ninguém fica parado.

📌 Nota importante:


Virtual threads não devem ser pooladas nem reutilizadas. São descartáveis, baratas, criamos uma para cada tarefa concorrente e pronto.

🛠️ Criando e usando virtual threads na prática

Vamos pegar uma tarefa simples:

Runnable task = () -> System.out.println(

    Thread.currentThread().toString());

1. Criar e já iniciar com startVirtualThread()

Thread vThread = Thread.startVirtualThread(task);

vThread.setName("minhaVirtual");

2. Usando Thread.ofVirtual()

Thread vThread = Thread.ofVirtual().start(task);

// Com nome

Thread vThread = Thread.ofVirtual().name("minhaVirtual").start(task);

3. Usando Thread.Builder (útil para várias)

Thread.Builder builder = Thread.ofVirtual().name("vt-", 1);

Thread t1 = builder.start(task);

t1.join();

Thread t2 = builder.start(task);

t2.join();

4. Criar sem iniciar (unstarted)

Thread vThread = Thread.ofVirtual().unstarted(task);

// depois...

vThread.start();

5. ThreadFactory de virtual threads

ThreadFactory factory = Thread.ofVirtual().name("worker-").factory();

Thread vThread = factory.newThread(task);

vThread.start();

Fácil, né? Você usa a mesma API java.lang.Thread que já conhece. Não precisa aprender CompletableFuture ou reactive streams – o código fica sequencial e legível.

🔍 Detalhes que você precisa saber

• 
  isVirtual() → retorna true.


• É daemon por padrão (isDaemon() = true). Não tente mudar.


• Prioridade sempre NORM_PRIORITY (5). setPriority() não tem efeito.


• Não pertence a ThreadGroup tradicional – o grupo se chama "VirtualThreads".


• 
  toString() mostra algo como: VirtualThread[#22]/runnable@ForkJoinPool-1-worker-1. O ForkJoinPool-1-worker-1 é a carrier thread (platform thread) que está executando sua virtual thread.

🚀 Quantas virtual threads conseguimos criar?

Rode isso (com cuidado, porque ele trava o sistema só depois de milhões):

AtomicLong contador = new AtomicLong();

while (true) {

    Thread.startVirtualThread(() -> {

        long id = contador.incrementAndGet();

        System.out.println("Virtual thread: " + id);

        LockSupport.park(); // trava a thread virtual

    });

}

No meu notebook, depois de 14 milhões de virtual threads o sistema ficou lento (GC atuando forte), mas não estourou memória. Isso é outro patamar de concorrência.

❗ Mitos que você deve esquecer

• 
  "Virtual threads são mais rápidas" – ERRADO. Elas não tornam código computacional mais rápido. Para CPU pesado, use parallel streams. Virtual threads melhoram throughput (você pode ter milhões esperando I/O), mas não latência.


• 
  "Devemos poolá-las" – ERRADO. Nunca crie um pool de virtual threads. Elas são descartáveis, baratas. Cada tarefa ganha a sua.


• 
  "Virtual threads são gratuitas" – ERRADO. Não são de graça, mas são 1000x mais baratas que platform threads.


• 
  "Se bloquear a virtual thread, a carrier thread também trava" – ERRADO. A JVM desmonta a virtual thread bloqueada e a carrier thread pega outra. O bloqueio não afeta outras virtual threads.

🔄 Compatibilidade retrógrada

Virtual threads funcionam com:

• Blocos synchronized
  


• 
  ThreadLocal (mas cuidado com o número excessivo – pode não escalar)


• Thread.currentThread()


• 
  interrupt() e InterruptedException
  

Ou seja, seu código antigo simplesmente roda em virtual threads – sem modificação. Basta mudar de new Thread(...).start() para Thread.startVirtualThread(...).

📌 Quando usar (e quando não usar)

✅ Ótimo para:

• Muitas tarefas de I/O (chamadas HTTP, leitura de banco, acesso a arquivos)


• Servidores web com alta concorrência


• Substituir CompletableFuture e código reativo cheio de callbacks

❌ Não tão útil para:

• Processamento intensivo de CPU (cálculos, criptografia, compressão) – prefira parallel streams ou manter pool de platform threads com tamanho = número de cores

🧠 Exemplo prático: simulando 10.000 chamadas HTTP

Com virtual threads fica limpo:

var httpClient = HttpClient.newHttpClient();

var requests = IntStream.range(0, 10_000)

    .mapToObj(i -> HttpRequest.newBuilder(URI.create("https://api.exemplo.com/users/" + i)).build())

    .toList();



try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {

    var futures = requests.stream()

        .map(req -> executor.submit(() -> httpClient.send(req, BodyHandlers.ofString())))

        .toList();



    for (var future : futures) {

        var response = future.get();

        System.out.println(response.body().length());

    }

}

Criamos 10.000 virtual threads ao mesmo tempo, cada uma esperando I/O. Com platform threads, isso seria impossível sem um pool enorme e OutOfMemoryError. Com virtual threads, roda liso.

🎯 Conclusão

Virtual threads são um divisor de águas para concorrência em Java:

• ✔️ Crie milhões delas sem medo


• ✔️ Código simples e bloqueante (nada de callbacks)


• ✔️ Aproveite ao máximo o hardware em tarefas de I/O


• ✔️ Compatível com todo o ecossistema Java

Então da próxima vez que pensar em CompletableFuture ou reactive streams, pergunte-se: dá pra resolver com virtual threads? Muitas vezes, a resposta é sim – com muito menos neuras.

Gostou? Testa aí no seu código com JDK 21+ e me conta o que achou. E lembre-se: thread virtual não é mais rápida, mas você pode ter tantas que parece mágica. ✨

Java21 #VirtualThreads #Concorrência #ProgramaçãoAssíncrona #JDK

Quer mais? O próximo post vai mostrar como usar virtual threads com Spring Boot e comparar performance com reactive. Até lá!