DEV Community: Dhellano Castro

Virtual Threads in Real Production: Docker, Kubernetes, and What the Dashboards Don't Tell You

Dhellano Castro — Sun, 22 Feb 2026 19:29:59 +0000

Series: Java in Real Production — This is the second article of the series. If you haven't read the first one yet, it covers the fundamentals of Virtual Threads, Thread Pinning, and the Stampede Effect — concepts we'll build on here. Read Part 1 here — Virtual Threads in Java 21: The End of the Scarcity Era (and the Pitfalls That Can Take You Down).

You read about Virtual Threads. You understood the mental model. You fixed Thread Pinning, put a Semaphore in front of the database. The application is working in development.

Then you deploy.

And the weirdness begins: latency spiking for no apparent reason, container being killed by the kernel at peak hours, dashboards showing low CPU while requests pile up in the queue. Everything seems fine — until it isn't.

This article is about what happens after the deploy. The production environment — Docker, Kubernetes, and observability — has its own pitfalls for Virtual Thread applications, and most of them are invisible until it's too late.

Stack Cost and the OOM Kill Risk in Docker

Let's start with memory, because this is where a risk lives that can literally kill your container — with no stack trace, no warning, no graceful shutdown.

The fundamental difference between the two models:

Platform Thread: ~1MB of stack allocated in the JVM's native space, outside the Heap
Virtual Thread: stack stored as Java objects on the Heap, subject to GC

This migration from "native stack" to "Heap objects" has a direct consequence: the -Xmx that used to be enough may no longer be.

The Equation Changed

With Platform Threads, memory was predictable:

Total Memory ≈ Heap (-Xmx) + MetaSpace + (N_threads × ~1MB native)

With Virtual Threads, the thread stack moved into the Heap:

Total Memory ≈ Heap (includes VT stacks) + MetaSpace + Carrier Thread stacks

When you set --memory=512m in Docker (or resources.limits.memory in Kubernetes), the Linux cgroup applies that limit to the entire process memory. If the JVM exceeds that limit, the kernel sends a SIGKILL. That's the OOM Kill — and it doesn't warn you.

🐳 Golden rule for Docker: Monitor Heap usage with Virtual Threads active. The -Xmx that used to be enough may need a 20–30% increase to accommodate Virtual Thread stacks on the Heap. Adjust the container limit with a safety margin of at least 15% above -Xmx.

# docker-compose.yml — safe configuration for Virtual Threads
services:
  app:
    image: my-app:latest
    environment:
      JAVA_OPTS: >-
        -Xms128m
        -Xmx384m
        -XX:+UseZGC
        -Djdk.virtualThreadScheduler.parallelism=4
    deploy:
      resources:
        limits:
          memory: 512m  # ~33% margin above Xmx — never set Xmx = limit

Note the -Djdk.virtualThreadScheduler.parallelism=4. This parameter controls how many Carrier Threads exist. On a container with 4 CPUs, keeping the default makes sense — but configuring it explicitly ensures the behavior doesn't change if the container's CPU count changes.

Why ZGC?

With high volumes of Virtual Threads, the Heap becomes a high-turnover environment: stack objects being created and destroyed constantly. Garbage collectors with long pauses — like G1 under heavy load — will introduce noticeable latency precisely at peak pressure moments. ZGC (and Shenandoah) were designed for sub-millisecond pauses regardless of Heap size. For Virtual Thread applications in production, they are the safest choice.

CPU Throttling in Kubernetes — The Silent Enemy of Carrier Threads

Kubernetes adds one more layer of complexity. And this one is especially treacherous because it acts completely silently.

The Mechanism

When you set resources.limits.cpu: "2" on your Pod, Kubernetes uses cgroup CPU quotas to ensure your container doesn't use more than 2 cores. If the process tries to use more, the kernel throttles it — literally strangling the process, preventing it from executing for a period proportional to the excess.

Remember the Carrier Threads from the previous article? They are OS threads that run Virtual Threads. If Kubernetes is throttling your container, Carrier Threads can't be scheduled by the OS. The result: even with 1,000,000 Virtual Threads ready to execute, they sit idle waiting for Carrier Threads to get CPU back.

The Misleading Symptom

High latency with apparently low CPU on dashboards.

The process isn't using CPU because it's being throttled — but the graphs show 40% usage (since throttle periods are cycles where the process simply doesn't run, pulling down the measured average). The metric that matters isn't cpu_usage, it's cpu_throttled_seconds_total — available in the cAdvisor of any Kubernetes cluster.

# kubernetes deployment — aware configuration for Virtual Threads
apiVersion: apps/v1
kind: Deployment
spec:
  template:
    spec:
      containers:
        - name: app
          resources:
            requests:
              cpu: "1"
              memory: "256Mi"
            limits:
              cpu: "2"       # Sets the effective ceiling for active Carrier Threads
              memory: "512Mi"
          env:
            - name: JAVA_OPTS
              value: >-
                -Xmx384m
                -XX:+UseZGC
                -Djdk.virtualThreadScheduler.parallelism=2
                -XX:StartFlightRecording=filename=/tmp/jfr/recording.jfr,
                  duration=60s,settings=profile

⚠️ Critical alignment: The value of virtualThreadScheduler.parallelism must be consistent with limits.cpu. If you set a 2 CPU limit but 8 Carrier Threads, the extra Carrier Threads will compete for CPU, increase throttling, and make things worse. Keep both values aligned.

Observability with JDK Flight Recorder (JFR)

JFR is the most powerful observability tool for diagnosing Virtual Thread problems in production. It has native support for Virtual Thread-specific events since Java 21 — and its overhead is so low it can run continuously in production without noticeable impact.

The Events That Matter

JFR Event	What it reveals
`jdk.VirtualThreadPinned`	Active Thread Pinning — `synchronized` + I/O in the critical path
`jdk.VirtualThreadSubmitFailed`	Failures submitting Virtual Threads — signal of scheduler saturation
`jdk.VirtualThreadStart` / `End`	Total volume of VTs created — detects creation explosion
`jdk.ThreadSleep`	Threads in unnecessarily long sleep

Runtime Diagnosis (No Restart Required)

# Start a 2-minute recording without restarting the application
jcmd <PID> JFR.start name=vt-diagnosis \
  settings=profile \
  duration=120s \
  filename=/tmp/vt-diagnosis.jfr

# Analyze pinning events directly in the terminal
jfr print --events jdk.VirtualThreadPinned /tmp/vt-diagnosis.jfr

For a complete visual analysis, JDK Mission Control (JMC) is the official GUI — open the .jfr file and get a full event timeline with drill-down by thread, method, and time.

Prometheus Integration via Micrometer

If you use Spring Boot 3.2+, Virtual Thread metrics are already available via Micrometer. Configure alerts for:

# Alert: Thread Pinning detected in production
- alert: VirtualThreadPinningDetected
  expr: jvm_threads_virtual_pinned_count > 0
  for: 1m
  annotations:
    summary: "Active Thread Pinning — investigate synchronized + I/O"

# Alert: CPU Throttling above acceptable threshold
- alert: ContainerCPUThrottling
  expr: rate(container_cpu_cfs_throttled_seconds_total[5m]) > 0.25
  for: 5m
  annotations:
    summary: "Container being throttled — Carrier Threads impacted"

🔍 Golden tip: If VirtualThreadPinned fires, you have Thread Pinning in production. If CPUThrottling fires alongside high latency, you have Carrier Threads being strangled by the cgroup. These are different problems with different causes — separate alerts prevent investigating in the wrong place.

The Modern Developer's Checklist

Consolidating everything from the series into an operational checklist:

Before Enabling Virtual Threads

[ ] Java 21+ in your environment — don't negotiate this
[ ] Check JDBC driver versions — PostgreSQL ≥ 42.6, MySQL Connector/J ≥ 9.0
[ ] Audit synchronized in critical I/O paths — migrate to ReentrantLock
[ ] Define concurrency limits for scarce resources via Semaphore or Resilience4j Bulkhead

Docker Configuration

[ ] Add 20–30% margin on the container memory limit above -Xmx
[ ] Configure -Djdk.virtualThreadScheduler.parallelism explicitly based on allocated CPUs
[ ] Use ZGC or Shenandoah as GC — shorter pauses, better for high Heap object turnover

Kubernetes Configuration

[ ] Monitor cpu_throttled_seconds_total in cAdvisor — throttling is the silent enemy of Carrier Threads
[ ] Align virtualThreadScheduler.parallelism with resources.limits.cpu
[ ] Enable JFR with Virtual Thread profile in staging before going to production

Production Observability

[ ] Alert for jdk.VirtualThreadPinned — any value above zero deserves investigation
[ ] Alert for container_cpu_cfs_throttled_seconds_total above 25%
[ ] Dashboard with jvm_threads_states_threads_total{state="runnable"} for active VT volume
[ ] Health checks that treat Bulkhead saturation as a degraded health state

Conclusion

The era of thread scarcity is over. The restaurant can have 1 million waiters.

But the database still has 100 tables. Kubernetes still has limited CPU. The container still has memory defined by the cgroup. And the kernel still sends SIGKILL without asking permission.

Virtual Threads solve the thread scarcity problem — and only that. The other problems still exist, and some become even more visible because the accidental handbrake that Platform Threads provided is gone.

The correct mental model isn't "Virtual Threads = free performance". It's: Virtual Threads = I stop worrying about threads and start worrying about the real resources my application consumes.

With that model in mind, the tool is genuinely transformative.

Have a question or want to go deeper on any of the points? Comment below — I answer all of them. 🙌

References

JEP 444 — Virtual Threads (Java 21)
Conceptual foundation for Carrier Thread behavior and the CPU throttling impact discussed in this article.
https://openjdk.org/jeps/444
OpenJDK — JDK Flight Recorder (JFR) Event Reference
Documentation for jdk.VirtualThreadPinned, jdk.VirtualThreadStart, and other Virtual Thread events available via JFR.
https://docs.oracle.com/en/java/javase/21/docs/api/jdk.jfr/jdk/jfr/package-summary.html
Spring Boot 3.2 Release Notes — Virtual Threads
Reference for Virtual Thread configuration with Spring Boot, including Micrometer integration for the metrics cited in the alert configurations.
https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-3.2-Release-Notes
Resilience4j — Official CircuitBreaker Documentation
Reference for failureRateThreshold, slidingWindowSize, and waitDurationInOpenState configuration used in the resilience examples.
https://resilience4j.readme.io/docs/circuitbreaker

Source Code

If you haven't seen the series repository yet, it contains executable demos of the Part 1 concepts — Stampede Effect, Thread Pinning, and Platform vs Virtual Threads benchmark — each with logs that make the behavior visible in real time.

🔗 github.com/DheCastro/java-virtual-threads-pitfalls

Virtual Threads in Java 21: The End of the Scarcity Era (and the Pitfalls That Can Take You Down)

Dhellano Castro — Sun, 22 Feb 2026 19:29:37 +0000

Series: Java in Real Production — This is the first of two articles. Here we cover the fundamentals, the right mental model, and the two pitfalls that silently bring down applications. In the second, we go deeper into Docker, Kubernetes, and observability with JFR.

Imagine a fine-dining restaurant. Every table — an HTTP request — needs a dedicated waiter. The waiter takes the order, walks to the kitchen... and just stands there, waiting for the chef to finish the dish. Meanwhile, new tables keep arriving. But there are no waiters available. The maître d' starts turning customers away at the door.

The restaurant is full of waiters standing idle in the kitchen — and the dining room is empty of service.

This is the classic Platform Threads model in Java. Each thread consumes roughly 1MB of stack in the operating system. On a server with 4GB dedicated to threads, you get at most ~4,000 waiters. Sounds like a lot? For a modern application with heavy I/O — database calls, external HTTP, messaging — it isn't.

Project Loom, introduced as a preview in Java 19 and stable since Java 21, changed the rules of the game. The core idea is elegant: what if the waiter could leave the table in the kitchen, go back to the dining room to serve other tables, and return when the dish was ready?

That's Virtual Threads. Millions of them. With memory cost in the kilobytes range. The restaurant can now have 1,000 real waiters serving 1,000,000 simultaneous tables.

But — and there's always a "but" — a restaurant with 1 million waiters and a single kitchen with 4 stoves will still clog up. This is where the story gets interesting.

The Engine Under the Hood

Before rushing off to create Virtual Threads everywhere, it's worth understanding what's happening under the hood. The JVM manages three distinct concepts that coexist in this ecosystem.

Platform Threads are the old, honest model: a Java thread mapped 1:1 to an operating system thread. The OS schedules it, the OS blocks it, the OS pays the memory bill. They're expensive, powerful, and limited in number.

Virtual Threads are threads managed by the JVM itself, not the OS. They're lightweight, cheap, and can exist in absurd quantities. When a Virtual Thread needs to wait for I/O, it is unmounted from the OS thread and its context is saved on the heap — as regular Java objects, subject to GC.

Carrier Threads are the missing link that most articles ignore. They are OS Platform Threads that the JVM's internal ForkJoinPool uses to run Virtual Threads. Think of them as subway rails: the cars (Virtual Threads) ride on top of the rails (Carrier Threads). You can have 1,000 cars, but if there are only 4 rails, only 4 cars move at a time.

┌─────────────────────────────────────────────────────┐
│                      JVM                            │
│                                                     │
│   Virtual Thread 1  ──┐                             │
│   Virtual Thread 2  ──┤                             │
│   Virtual Thread 3  ──┼──► Carrier Thread 1 ──► OS  │
│   Virtual Thread 4  ──┤                             │
│   Virtual Thread ...──┘                             │
│                        ──► Carrier Thread 2 ──► OS  │
│                        ──► Carrier Thread N ──► OS  │
│                                                     │
│   (N = number of available CPUs, by default)        │
└─────────────────────────────────────────────────────┘

The default number of Carrier Threads equals the number of available CPUs. In production, inside a Docker container with --cpus=2, you have 2 rails for potentially millions of cars. This will matter — a lot — in the second article of this series.

Pitfall 1 — Thread Pinning: The Bolt in the Floor

Remember the waiter who could leave the table in the kitchen and go serve others? Well. There's a situation where they can't leave. Someone bolted their chair to the kitchen floor. That bolt is called synchronized.

When a Virtual Thread enters a synchronized block or method and hits a blocking point — I/O, for example — it cannot be unmounted from the Carrier Thread. It pins. The Carrier Thread gets stuck with it, waiting. If all Carrier Threads get pinned, your application freezes. Completely.

⚠️ Important: synchronized is not inherently a villain. It's perfectly safe to use it to protect fast in-memory operations, like manipulating a shared HashMap. The problem arises when inside the synchronized block there's a slow I/O operation — a database query, an HTTP call, a file read.

See the difference in practice:

// ❌ PROBLEMATIC: synchronized + I/O = Thread Pinning guaranteed
// The Carrier Thread gets stuck while the database responds
public synchronized User findById(Long id) {
    return jdbcTemplate.queryForObject(
        "SELECT * FROM users WHERE id = ?",
        userRowMapper,
        id
    );
}

// ✅ CORRECT: ReentrantLock is "Virtual Thread aware"
// The Virtual Thread can be unmounted while waiting for the database
// The Carrier Thread is free to execute other Virtual Threads
private final ReentrantLock lock = new ReentrantLock();

public User findById(Long id) throws InterruptedException {
    lock.lock();
    try {
        return jdbcTemplate.queryForObject(
            "SELECT * FROM users WHERE id = ?",
            userRowMapper,
            id
        );
    } finally {
        lock.unlock();
    }
}

Why does ReentrantLock solve it? Because it doesn't use native OS object monitors. When a Virtual Thread needs to wait inside a ReentrantLock, the JVM can unmount it from the Carrier Thread normally. The waiter can finally get up from the chair.

To identify pinning in production, enable the JVM diagnostic flag:

-Djdk.tracePinnedThreads=full

💡 Note for framework users: Older JDBC drivers and some DataSource implementations still use synchronized internally. Check your versions. The PostgreSQL driver removed the problematic synchronized usages starting from version 42.6.

📌 Note on Java 24: JEP 491, delivered in Java 24, resolves this limitation in most cases. Starting from Java 24, synchronized with I/O no longer causes pinning. For those still on Java 21/22/23 — which is most production environments today — the pitfall remains valid and migrating to ReentrantLock is still the right recommendation.

Pitfall 2 — The Stampede Effect

You fixed the pinning. Your application is running with Virtual Threads smooth as butter. Requests coming in, threads responding. Then you look at your database and see this:

ERROR: FATAL: remaining connection slots are reserved
       for replication superuser connections
Max connections: 100. Active: 100. Waiting: 4,847.

Welcome to the Stampede Effect.

The problem is subtle and cruel: with Platform Threads, the thread pool was the natural limiter of database connections. If you had 200 threads in the pool, at most 200 simultaneous connections reached the database. It was accidental contention, but it worked as a handbrake.

With Virtual Threads, that handbrake is gone. The JVM can create unlimited Virtual Threads. Each one, upon hitting an I/O point, stays "parked" waiting for the response — but keeps existing and holding an open connection to the database. A flood of 50,000 simultaneous requests can turn into 50,000 connections trying to open on the database at once.

The database collapses. It wasn't the Virtual Thread that was slow — it was the absence of governance over the shared resource.

🎯 The central paradigm shift of Project Loom: With Virtual Threads, control moves away from the thread and toward the resource. You no longer limit threads. You limit access to scarce resources.

Mitigation — The Intelligent Handbrake

Semaphore: The Database Doorman

The most direct solution is to use a Semaphore as an access controller. Think of it as a doorman at the database entrance: regardless of how many clients show up, only N get in at a time.

@Repository
public class ProductRepository {

    // Doorman: maximum 80 simultaneous connections to the database
    private final Semaphore dbGatekeeper = new Semaphore(80);

    public List<Product> findAllByCategory(String category) {
        try {
            dbGatekeeper.acquire(); // Wait for the doorman's permission
            try {
                return jdbcTemplate.query(
                    "SELECT * FROM products WHERE category = ?",
                    productRowMapper,
                    category
                );
            } finally {
                dbGatekeeper.release(); // Release the slot on exit
            }
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
            throw new DatabaseAccessException("Interrupted while waiting for DB slot", e);
        }
    }
}

The beauty here: Semaphore.acquire() is a virtual-thread-friendly blocking point. The Virtual Thread waiting for the doorman's slot is unmounted from the Carrier Thread, which is free to execute other Virtual Threads. Zero CPU waste.

Resilience4j: Mission Control

For real production, a bare Semaphore is the bare minimum. Resilience4j offers a complete set of resilience primitives, all compatible with Virtual Threads.

BulkheadConfig is essentially a Semaphore on steroids: metrics, fallbacks, timeouts, and native integration with Micrometer and Prometheus.

// Bulkhead configuration
@Bean
public BulkheadRegistry bulkheadRegistry() {
    BulkheadConfig config = BulkheadConfig.custom()
        .maxConcurrentCalls(80)                 // Maximum simultaneous calls
        .maxWaitDuration(Duration.ofSeconds(2)) // Queue wait timeout
        .build();

    return BulkheadRegistry.of(config);
}

// Usage in the service
@Service
public class ProductService {

    private final Bulkhead dbBulkhead;
    private final ProductRepository repository;

    public ProductService(BulkheadRegistry registry, ProductRepository repository) {
        this.dbBulkhead = registry.bulkhead("database-bulkhead");
        this.repository = repository;
    }

    public List<Product> getProductsByCategory(String category) {
        return Bulkhead.decorateSupplier(
            dbBulkhead,
            () -> repository.findAllByCategory(category)
        ).get();
    }
}

Combine this with a CircuitBreaker so that if the database starts rejecting connections, the circuit opens automatically — giving the database time to recover before the situation escalates.

@Bean
public CircuitBreakerConfig circuitBreakerConfig() {
    return CircuitBreakerConfig.custom()
        .failureRateThreshold(50)                        // Opens if 50% of calls fail
        .waitDurationInOpenState(Duration.ofSeconds(30)) // Waits 30s before retrying
        .slidingWindowSize(20)                           // Evaluates the last 20 calls
        .build();
}

Want to See the Numbers in Practice?

There's a complete, self-contained demo available in the repository — Java 21, zero dependencies — showing both scenarios running and printing the results. The output is brutal:

SCENARIO 1 — WITHOUT control:
✅ Success:   80 requests
❌ Rejected:  420 requests  ← 84% of requests lost

SCENARIO 2 — WITH Semaphore:
✅ Success:   500 requests
❌ Rejected:  0 requests
📈 Peak:      80 connections (never exceeded the limit)

🔗 github.com/DheCastro/java-virtual-threads-pitfalls

What's Coming in the Next Article

Now that the mental model is correct, let's go deeper into where most Java applications actually live: containers in production.

In the next article of this series, we'll cover:

Stack cost in Docker: why the -Xmx that used to be enough may no longer be — and how to calculate the right margin to avoid OOM Kill
CPU Throttling in Kubernetes: how CPU limits affect Carrier Threads and cause high latency with apparently low CPU on dashboards
Observability with JFR: the exact events to monitor Thread Pinning and saturation in production
Complete checklist for the modern developer for a safe migration

Continue reading: Part 2 — Virtual Threads in Real Production: Docker, Kubernetes, and What the Dashboards Don't Tell You

If this article was helpful, drop a reaction — it really helps to know if the series is worth continuing. 🙌

References

JEP 444 — Virtual Threads (Java 21)
Official Project Loom specification. Documents the mount/unmount model, synchronized behavior, and the role of Carrier Threads.
https://openjdk.org/jeps/444
JEP 491 — Synchronize Virtual Threads without Pinning (Java 24)
The direct evolution of the Thread Pinning pitfall discussed in this article. Starting from Java 24, synchronized with I/O no longer causes pinning in most cases.
https://openjdk.org/jeps/491
Spring Boot 3.2 Release Notes — Virtual Threads
Official documentation for the spring.threads.virtual.enabled property and what it configures automatically (Tomcat, Jetty, @Async, executors).
https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-3.2-Release-Notes
Resilience4j — Official Bulkhead Documentation
Reference for SemaphoreBulkhead and BulkheadConfig used in the mitigation section.
https://resilience4j.readme.io/docs/bulkhead

Source Code

All examples from this article — and more — are available in the repository below.
Each class is self-contained and runs with a single command (java ClassName.java).
No external dependencies, just Java 21.

🔗 github.com/DheCastro/java-virtual-threads-pitfalls

Virtual Threads em Produção de Verdade: Docker, Kubernetes e o que os Dashboards não te Contam

Dhellano Castro — Sun, 22 Feb 2026 15:49:48 +0000

Série: Java em Produção de Verdade — Este é o segundo artigo da série. Se você ainda não leu o primeiro, ele cobre os fundamentos das Virtual Threads, Thread Pinning e o Efeito Manada — conceitos que usaremos aqui como base. Leia a Parte 1 aqui — Virtual Threads no Java 21: O Fim da Era da Escassez (e as Armadilhas que Podem Lhe Derrubar).

Você leu sobre Virtual Threads. Entendeu o modelo mental. Resolveu o Thread Pinning, colocou o Semaphore na frente do banco. A aplicação está funcionando em desenvolvimento.

Aí você faz o deploy.

E começa a estranheza: latência oscilando sem motivo aparente, container sendo morto pelo kernel em hora de pico, dashboards mostrando CPU baixa enquanto as requisições acumulam na fila. Tudo parece bem — até não estar.

Esse artigo é sobre o que acontece depois do deploy. O ambiente de produção — Docker, Kubernetes e observabilidade — tem suas próprias armadilhas para aplicações com Virtual Threads, e a maioria delas é invisível até ser tarde demais.

O Custo do Stack e o Risco de OOM Kill no Docker

Vamos começar com memória, porque aqui mora um risco que pode matar seu container literalmente — sem stack trace, sem aviso, sem graceful shutdown.

A diferença fundamental entre os dois modelos:

Platform Thread: ~1MB de stack alocado no espaço nativo da JVM, fora da Heap
Virtual Thread: stack armazenado como objetos Java na Heap, sujeito ao GC

Essa migração de "stack nativo" para "objetos na Heap" tem uma consequência direta: o -Xmx que era suficiente antes pode não ser mais.

A Equação Mudou

Com Platform Threads, a memória era previsível:

Memória Total ≈ Heap (-Xmx) + MetaSpace + (N_threads × ~1MB nativo)

Com Virtual Threads, o stack das threads entrou na Heap:

Memória Total ≈ Heap (inclui stacks das VTs) + MetaSpace + Carrier Thread stacks

Quando você define --memory=512m no Docker (ou resources.limits.memory no Kubernetes), o Linux cgroup aplica esse limite em toda a memória do processo. Se a JVM ultrapassar esse limite, o kernel envia um SIGKILL. Isso é o OOM Kill — e ele não avisa.

🐳 Regra de ouro para Docker: Monitore o uso de Heap com Virtual Threads ativas. O -Xmx que era suficiente antes pode precisar de um incremento de 20–30% para acomodar os stacks das Virtual Threads na Heap. Ajuste o limite do container com uma margem de segurança de pelo menos 15% acima do -Xmx.

# docker-compose.yml — configuração segura para Virtual Threads
services:
  app:
    image: minha-app:latest
    environment:
      JAVA_OPTS: >-
        -Xms128m
        -Xmx384m
        -XX:+UseZGC
        -Djdk.virtualThreadScheduler.parallelism=4
    deploy:
      resources:
        limits:
          memory: 512m  # ~33% de margem acima do Xmx — nunca coloque Xmx = limite

Note o -Djdk.virtualThreadScheduler.parallelism=4. Esse parâmetro controla quantas Carrier Threads existem. Num container com 4 CPUs, faz sentido manter o padrão — mas configurá-lo explicitamente garante que o comportamento não mude se o número de CPUs do container mudar.

Por Que ZGC?

Com alto volume de Virtual Threads, a Heap vira um ambiente de alta rotatividade: objetos de stack sendo criados e destruídos constantemente. Coletores de lixo com pausas longas — como o G1 em cargas pesadas — vão introduzir latência perceptível justamente nos momentos de maior pressão. O ZGC (e o Shenandoah) foram projetados para pausas sub-milissegundo, independente do tamanho da Heap. Para aplicações com Virtual Threads em produção, são a escolha mais segura.

CPU Throttling no Kubernetes — O Inimigo Silencioso das Carrier Threads

O Kubernetes adiciona mais uma camada de complexidade. E essa é especialmente traiçoeira porque age de forma completamente silenciosa.

O Mecanismo

Quando você define resources.limits.cpu: "2" no seu Pod, o Kubernetes usa CPU quotas do cgroup para garantir que seu container não use mais que 2 cores. Se o processo tentar usar mais, o kernel throttle — literalmente estrangula o processo, impedindo-o de executar por um período proporcional ao excesso.

Lembra das Carrier Threads do artigo anterior? Elas são threads de SO que executam as Virtual Threads. Se o Kubernetes está throttling seu container, as Carrier Threads não conseguem ser agendadas. O resultado: mesmo com 1.000.000 de Virtual Threads prontas para executar, elas ficam paradas esperando que as Carrier Threads ganhem CPU de volta.

O Sintoma Enganoso

Latência alta com CPU aparentemente baixa nos dashboards.

O processo não está usando CPU porque está sendo throttled — mas os gráficos mostram 40% de uso (já que os períodos de throttle são ciclos onde o processo simplesmente não roda, reduzindo a média medida). A métrica que importa não é cpu_usage, é cpu_throttled_seconds_total — disponível no cAdvisor de qualquer cluster Kubernetes.

# kubernetes deployment — configuração consciente para Virtual Threads
apiVersion: apps/v1
kind: Deployment
spec:
  template:
    spec:
      containers:
        - name: app
          resources:
            requests:
              cpu: "1"
              memory: "256Mi"
            limits:
              cpu: "2"       # Define o teto efetivo de Carrier Threads ativas
              memory: "512Mi"
          env:
            - name: JAVA_OPTS
              value: >-
                -Xmx384m
                -XX:+UseZGC
                -Djdk.virtualThreadScheduler.parallelism=2
                -XX:StartFlightRecording=filename=/tmp/jfr/recording.jfr,
                  duration=60s,settings=profile

⚠️ Alinhamento crítico: O valor de virtualThreadScheduler.parallelism deve ser coerente com o limits.cpu. Se você define 2 CPUs de limite mas 8 Carrier Threads, as Carrier Threads extras vão competir por CPU, aumentar o throttling e piorar a situação. Mantenha os dois valores alinhados.

Observabilidade com JDK Flight Recorder (JFR)

O JFR é a ferramenta de observabilidade mais poderosa para diagnosticar problemas com Virtual Threads em produção. Ele tem suporte nativo a eventos específicos de Virtual Threads desde o Java 21 — e tem overhead tão baixo que pode rodar continuamente em produção sem impacto perceptível.

Os Eventos que Importam

Evento JFR	O que revela
`jdk.VirtualThreadPinned`	Thread Pinning ativo — `synchronized` + I/O no caminho crítico
`jdk.VirtualThreadSubmitFailed`	Falhas ao submeter Virtual Threads — sinal de saturação do scheduler
`jdk.VirtualThreadStart` / `End`	Volume total de VTs criadas — detecta explosão de criação
`jdk.ThreadSleep`	Threads em sleep desnecessariamente longo

Diagnóstico em Runtime (Sem Restart)

# Inicia uma gravação de 2 minutos sem reiniciar a aplicação
jcmd <PID> JFR.start name=vt-diagnosis \
  settings=profile \
  duration=120s \
  filename=/tmp/vt-diagnosis.jfr

# Analisa eventos de pinning diretamente no terminal
jfr print --events jdk.VirtualThreadPinned /tmp/vt-diagnosis.jfr

Para uma análise visual completa, o JDK Mission Control (JMC) é a GUI oficial — você abre o arquivo .jfr e tem uma linha do tempo completa de todos os eventos, com drill-down por thread, por método e por tempo.

Integração com Prometheus via Micrometer

Se você usa Spring Boot 3.2+, as métricas de Virtual Threads já estão disponíveis via Micrometer. Configure alertas para:

# Alerta: Thread Pinning detectado em produção
- alert: VirtualThreadPinningDetected
  expr: jvm_threads_virtual_pinned_count > 0
  for: 1m
  annotations:
    summary: "Thread Pinning ativo — investigar synchronized + I/O"

# Alerta: CPU Throttling acima do aceitável
- alert: ContainerCPUThrottling
  expr: rate(container_cpu_cfs_throttled_seconds_total[5m]) > 0.25
  for: 5m
  annotations:
    summary: "Container sendo throttled — Carrier Threads impactadas"

🔍 Dica de ouro: Se VirtualThreadPinned disparar, você tem Thread Pinning em produção. Se CPUThrottling disparar junto com latência alta, você tem Carrier Threads sendo estranguladas pelo cgroup. São problemas diferentes com causas diferentes — os alertas separados evitam a investigação no lugar errado.

Checklist do Desenvolvedor Moderno

Consolidando tudo da série em um checklist operacional:

Antes de Ligar Virtual Threads

[ ] Java 21+ no ambiente — não negocie isso
[ ] Verifique versões de drivers JDBC — PostgreSQL ≥ 42.6, MySQL Connector/J ≥ 9.0
[ ] Audite synchronized em caminhos críticos de I/O — migre para ReentrantLock
[ ] Defina limites de concorrência para recursos escassos via Semaphore ou Resilience4j Bulkhead

Configuração Docker

[ ] Adicione 20–30% de margem no limite de memória do container acima do -Xmx
[ ] Configure -Djdk.virtualThreadScheduler.parallelism explicitamente com base nas CPUs alocadas
[ ] Use ZGC ou Shenandoah como GC — menores pausas, melhor para alta rotatividade de objetos na Heap

Configuração Kubernetes

[ ] Monitore cpu_throttled_seconds_total no cAdvisor — throttling é o inimigo silencioso das Carrier Threads
[ ] Alinhe virtualThreadScheduler.parallelism com resources.limits.cpu
[ ] Ative JFR com perfil de Virtual Threads em staging antes de ir para produção

Observabilidade em Produção

[ ] Alerta para jdk.VirtualThreadPinned — qualquer valor acima de zero merece investigação
[ ] Alerta para container_cpu_cfs_throttled_seconds_total acima de 25%
[ ] Dashboard com jvm_threads_states_threads_total{state="runnable"} para volume de VTs ativas
[ ] Health checks que considerem saturação do Bulkhead como estado de degradação

Conclusão

A era da escassez de threads terminou. O restaurante pode ter 1 milhão de garçons.

Mas o banco de dados ainda tem 100 mesas. O Kubernetes ainda tem CPU limitada. O container ainda tem memória definida pelo cgroup. E o kernel ainda manda SIGKILL sem pedir licença.

Virtual Threads resolvem o problema de escassez de threads — e apenas esse. Os outros problemas continuam existindo, e alguns ficam até mais visíveis porque o freio acidental que as Platform Threads proporcionavam sumiu.

O modelo mental correto não é "Virtual Threads = performance livre". É: Virtual Threads = eu paro de me preocupar com threads e começo a me preocupar com os recursos reais que minha aplicação consome.

Com esse modelo na cabeça, a ferramenta é genuinamente transformadora.

Ficou com alguma dúvida ou quer aprofundar algum dos pontos? Comenta aqui embaixo — respondo todos. 🙌

Referências

JEP 444 — Virtual Threads (Java 21)
Base conceitual para o comportamento das Carrier Threads e o impacto de CPU throttling discutido neste artigo.
https://openjdk.org/jeps/444
OpenJDK — JDK Flight Recorder (JFR) Event Reference
Documentação dos eventos jdk.VirtualThreadPinned, jdk.VirtualThreadStart e demais eventos de Virtual Threads disponíveis via JFR.
https://docs.oracle.com/en/java/javase/21/docs/api/jdk.jfr/jdk/jfr/package-summary.html
Spring Boot 3.2 Release Notes — Virtual Threads
Referência para configuração de Virtual Threads com Spring Boot, incluindo integração com Micrometer para as métricas citadas nas configurações de alerta.
https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-3.2-Release-Notes
Resilience4j — Documentação oficial do CircuitBreaker
Referência para a configuração de failureRateThreshold, slidingWindowSize e waitDurationInOpenState usados nos exemplos de resiliência.
https://resilience4j.readme.io/docs/circuitbreaker

Código-fonte

Se você ainda não viu o repositório da série, ele contém demos executáveis dos conceitos da Parte 1 — Efeito Manada, Thread Pinning e benchmark Platform vs Virtual Threads — cada um com logs que tornam o comportamento visível em tempo real.

🔗 github.com/DheCastro/java-virtual-threads-pitfalls

Virtual Threads no Java 21: O Fim da Era da Escassez (e as Armadilhas que Podem Lhe Derrubar)

Dhellano Castro — Sun, 22 Feb 2026 15:46:51 +0000

Série: Java em Produção de Verdade — Este é o primeiro de dois artigos. Aqui cobrimos os fundamentos, o modelo mental correto e as duas armadilhas que derrubam aplicações silenciosamente. No segundo, descemos para Docker, Kubernetes e observabilidade com JFR.

Imagine um restaurante sofisticado. Cada mesa — uma requisição HTTP — precisa de um garçom dedicado. O garçom anota o pedido, vai até a cozinha... e fica parado lá, esperando o chef terminar o prato. Enquanto isso, novas mesas chegam. Mas não tem garçom disponível. O maître começa a recusar clientes na porta.

O restaurante está cheio de garçons parados na cozinha sem fazer nada — e o salão, vazio de atendimento.

Esse é o modelo clássico de Platform Threads em Java. Cada thread consome cerca de 1MB de stack no sistema operacional. Num servidor com 4GB dedicados a threads, você tem no máximo ~4.000 garçons. Parece muito? Para uma aplicação moderna com alto volume de I/O — chamadas a banco, HTTP externo, mensageria — não é.

O Project Loom, introduzido como preview no Java 19 e estável a partir do Java 21, mudou as regras do jogo. A ideia central é elegante: e se o garçom pudesse largar a mesa na cozinha, voltar ao salão para atender outras mesas, e retornar quando o prato ficasse pronto?

Isso são as Virtual Threads. Milhões delas. Com custo de memória na casa dos kilobytes. O restaurante agora pode ter 1.000 garçons reais atendendo 1.000.000 de mesas simultâneas.

Mas — e sempre tem um "mas" — um restaurante com 1 milhão de garçons e uma única cozinha com 4 fogões ainda vai entupir. É aqui que a história começa a ficar interessante.

O Motor por Baixo do Capô

Antes de sair criando Virtual Threads por aí, vale entender o que está acontecendo embaixo dos panos. A JVM gerencia três conceitos distintos que vivem juntos nesse ecossistema.

Platform Threads são o modelo antigo e honesto: uma thread Java mapeada 1:1 para uma thread do sistema operacional. O SO agenda, o SO bloqueia, o SO paga a conta de memória. São caras, poderosas e limitadas em número.

Virtual Threads são threads gerenciadas pela própria JVM, não pelo SO. São leves, baratas e podem existir em quantidades absurdas. Quando uma Virtual Thread precisa esperar por I/O, ela é desmontada (unmounted) da thread do SO e o seu contexto fica salvo na heap — como objetos Java comuns, sujeitos ao GC.

Carrier Threads são o elo perdido que a maioria dos artigos ignora. São Platform Threads do SO que o ForkJoinPool interno da JVM usa para executar as Virtual Threads. Pense nelas como os trilhos de um metrô: os vagões (Virtual Threads) rodam em cima dos trilhos (Carrier Threads). Você pode ter 1.000 vagões, mas se tiver apenas 4 trilhos, só 4 vagões andam ao mesmo tempo.

┌─────────────────────────────────────────────────────┐
│                      JVM                            │
│                                                     │
│   Virtual Thread 1  ──┐                             │
│   Virtual Thread 2  ──┤                             │
│   Virtual Thread 3  ──┼──► Carrier Thread 1 ──► OS  │
│   Virtual Thread 4  ──┤                             │
│   Virtual Thread ...──┘                             │
│                        ──► Carrier Thread 2 ──► OS  │
│                        ──► Carrier Thread N ──► OS  │
│                                                     │
│   (N = número de CPUs disponíveis, por padrão)      │
└─────────────────────────────────────────────────────┘

O número padrão de Carrier Threads é igual ao número de CPUs disponíveis. Em produção, dentro de um container Docker com --cpus=2, você tem 2 trilhos para potencialmente milhões de vagões. Isso vai importar — muito — no segundo artigo desta série.

Armadilha 1 — Thread Pinning: O Parafuso no Chão

Lembra do garçom que podia largar a mesa na cozinha e ir atender outras? Pois bem. Existe uma situação onde ele não consegue largar. Alguém parafusou a cadeira dele no chão da cozinha. Esse parafuso se chama synchronized.

Quando uma Virtual Thread entra em um bloco ou método synchronized e encontra um ponto de bloqueio — I/O, por exemplo — ela não consegue ser desmontada da Carrier Thread. Ela pina. A Carrier Thread fica presa junto com ela, esperando. Se todas as Carrier Threads ficarem pinadas, sua aplicação congela. Completamente.

⚠️ Importante: synchronized não é vilão por natureza. É perfeitamente seguro usá-lo para proteger operações rápidas em memória, como manipulação de uma HashMap compartilhada. O problema surge quando dentro do bloco synchronized existe uma operação de I/O demorada — consulta ao banco, chamada HTTP, leitura de arquivo.

Veja a diferença na prática:

// ❌ PROBLEMÁTICO: synchronized + I/O = Thread Pinning garantido
// A Carrier Thread fica presa enquanto o banco responde
public synchronized User findById(Long id) {
    return jdbcTemplate.queryForObject(
        "SELECT * FROM users WHERE id = ?",
        userRowMapper,
        id
    );
}

// ✅ CORRETO: ReentrantLock é "Virtual Thread aware"
// A Virtual Thread pode ser desmontada enquanto aguarda o banco
// A Carrier Thread fica livre para executar outras Virtual Threads
private final ReentrantLock lock = new ReentrantLock();

public User findById(Long id) throws InterruptedException {
    lock.lock();
    try {
        return jdbcTemplate.queryForObject(
            "SELECT * FROM users WHERE id = ?",
            userRowMapper,
            id
        );
    } finally {
        lock.unlock();
    }
}

Por que o ReentrantLock resolve? Porque ele não usa monitores de objeto nativos do SO. Quando a Virtual Thread precisa aguardar dentro de um ReentrantLock, a JVM consegue desmontá-la da Carrier Thread normalmente. O garçom finalmente consegue sair da cadeira.

Para identificar pinning em produção, ative o diagnóstico com a JVM flag:

-Djdk.tracePinnedThreads=full

💡 Nota para quem usa frameworks: Drivers JDBC antigos e algumas implementações de DataSource ainda usam synchronized internamente. Verifique suas versões. O driver do PostgreSQL removeu os synchronized problemáticos a partir da versão 42.6.

Armadilha 2 — O Efeito Manada

Você resolveu o pinning. Sua aplicação está rodando com Virtual Threads lisas como manteiga. Requisições entrando, threads respondendo. Aí você olha para o banco de dados e vê isso:

ERROR: FATAL: remaining connection slots are reserved
       for replication superuser connections
Max connections: 100. Active: 100. Waiting: 4.847.

Bem-vindo ao Efeito Manada.

O problema é sutil e cruel: com Platform Threads, o pool de threads era o limitador natural de conexões com o banco. Se você tinha 200 threads no pool, no máximo 200 conexões simultâneas chegavam ao banco. Era uma contenção acidental, mas funcionava como um freio de mão.

Com Virtual Threads, esse freio sumiu. A JVM pode criar ilimitadas Virtual Threads. Cada uma, ao encontrar um ponto de I/O, fica "parada" aguardando a resposta — mas continua existindo e segurando uma conexão aberta com o banco. Uma enxurrada de 50.000 requisições simultâneas pode se transformar em 50.000 conexões tentando abrir no banco ao mesmo tempo.

O banco colapsa. Não foi a Virtual Thread que foi lenta — foi a ausência de governança sobre o recurso compartilhado.

🎯 A mudança de paradigma central do Project Loom: Com Virtual Threads, o controle sai da thread e vai para o recurso. Você não limita mais threads. Você limita acesso a recursos escassos.

Mitigação — O Freio de Mão Inteligente

Semaphore: O Porteiro do Banco

A solução mais direta é usar um Semaphore como controlador de acesso. Pense nele como um porteiro na porta do banco de dados: independente de quantos clientes cheguem, só N entram ao mesmo tempo.

@Repository
public class ProductRepository {

    // Porteiro: máximo 80 conexões simultâneas ao banco
    private final Semaphore dbGatekeeper = new Semaphore(80);

    public List<Product> findAllByCategory(String category) {
        try {
            dbGatekeeper.acquire(); // Aguarda permissão do porteiro
            try {
                return jdbcTemplate.query(
                    "SELECT * FROM products WHERE category = ?",
                    productRowMapper,
                    category
                );
            } finally {
                dbGatekeeper.release(); // Libera a vaga ao sair
            }
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
            throw new DatabaseAccessException("Interrupted while waiting for DB slot", e);
        }
    }
}

A beleza aqui: Semaphore.acquire() é um ponto de bloqueio virtual-thread-friendly. A Virtual Thread que aguarda a vaga do porteiro é desmontada da Carrier Thread, que fica livre para executar outras Virtual Threads. Zero desperdício de CPU.

Resilience4j: O Controle de Missão

Para produção real, o Semaphore puro é o mínimo. O Resilience4j oferece um conjunto completo de primitivas para resiliência, todas compatíveis com Virtual Threads.

O BulkheadConfig é essencialmente um Semaphore com superpoderes: métricas, fallbacks, timeouts e integração nativa com Micrometer e Prometheus.

// Configuração do Bulkhead
@Bean
public BulkheadRegistry bulkheadRegistry() {
    BulkheadConfig config = BulkheadConfig.custom()
        .maxConcurrentCalls(80)                 // Máximo de chamadas simultâneas
        .maxWaitDuration(Duration.ofSeconds(2)) // Timeout na fila de espera
        .build();

    return BulkheadRegistry.of(config);
}

// Uso no serviço
@Service
public class ProductService {

    private final Bulkhead dbBulkhead;
    private final ProductRepository repository;

    public ProductService(BulkheadRegistry registry, ProductRepository repository) {
        this.dbBulkhead = registry.bulkhead("database-bulkhead");
        this.repository = repository;
    }

    public List<Product> getProductsByCategory(String category) {
        return Bulkhead.decorateSupplier(
            dbBulkhead,
            () -> repository.findAllByCategory(category)
        ).get();
    }
}

Combine isso com um CircuitBreaker para que, se o banco começar a rejeitar conexões, o circuito abra automaticamente — dando tempo para o banco se recuperar antes de a situação escalar.

@Bean
public CircuitBreakerConfig circuitBreakerConfig() {
    return CircuitBreakerConfig.custom()
        .failureRateThreshold(50)                       // Abre se 50% das calls falharem
        .waitDurationInOpenState(Duration.ofSeconds(30))// Espera 30s para tentar de novo
        .slidingWindowSize(20)                          // Avalia as últimas 20 chamadas
        .build();
}

Quer Ver os Números na Prática?

Há um demo completo e autocontido disponível no repositório — Java 21, zero dependências — que mostra os dois cenários rodando e imprimindo os resultados. O output é brutal:

CENÁRIO 1 — SEM controle:
✅ Sucesso:    80 requisições
❌ Rejeitadas: 420 requisições  ← 84% das requisições perdidas

CENÁRIO 2 — COM Semaphore:
✅ Sucesso:    500 requisições
❌ Rejeitadas: 0 requisições
📈 Pico:       80 conexões (nunca ultrapassou o limite)

🔗 [https://github.com/DheCastro/java-virtual-threads-pitfalls]

O Que Vem no Próximo Artigo

Agora que o modelo mental está correto, vamos descer para onde a maioria das aplicações Java realmente vive: containers em produção.

No próximo artigo desta série, vamos cobrir:

O custo do Stack em Docker: por que o -Xmx que era suficiente antes pode não ser mais — e como calcular a margem correta para evitar OOM Kill
CPU Throttling no Kubernetes: como limites de CPU afetam as Carrier Threads e causam latência alta com CPU aparentemente baixa nos dashboards
Observabilidade com JFR: os eventos exatos para monitorar Thread Pinning e saturação em produção
Checklist completo do desenvolvedor moderno para uma migração segura

Continue lendo: Parte 2 — Virtual Threads em Produção de Verdade: Docker, Kubernetes e o que os Dashboards não te Contam

Se este artigo foi útil, deixa uma reação — ajuda muito a saber se vale continuar a série. 🙌

Referências

JEP 444 — Virtual Threads (Java 21)
Especificação oficial do Project Loom. Documenta o modelo de mount/unmount, o comportamento do synchronized e o papel das Carrier Threads.
https://openjdk.org/jeps/444
JEP 491 — Synchronize Virtual Threads without Pinning (Java 24)
A evolução direta da armadilha do Thread Pinning discutida neste artigo. A partir do Java 24, o synchronized com I/O deixa de causar pinning na maioria dos casos — relevante se você já está ou planeja estar no Java 24+.
https://openjdk.org/jeps/491
Spring Boot 3.2 Release Notes — Virtual Threads
Documentação oficial da propriedade spring.threads.virtual.enabled e o que ela configura automaticamente (Tomcat, Jetty, @Async, executores).
https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-3.2-Release-Notes
Resilience4j — Documentação oficial do Bulkhead
Referência para o SemaphoreBulkhead e BulkheadConfig usados na seção de mitigação.
https://resilience4j.readme.io/docs/bulkhead

Código-fonte

Todos os exemplos deste artigo — e mais — estão disponíveis no repositório abaixo.
Cada classe é autocontida e roda com um único comando (java NomeClasse.java).
Nenhuma dependência externa, apenas Java 21.

🔗 github.com/DheCastro/java-virtual-threads-pitfalls

Gestão de nodes e pods com Karpenter - Perspectiva do Desenvolvedor

Dhellano Castro — Sat, 18 Oct 2025 21:44:20 +0000

O problema

Recentemente "tive a oportunidade" de passar por um problema envolvendo um deploy de um serviço em estratégia canário (se você não sabe o que é um deploy em canário, pode ler mais sobre isso aqui: Entendendo como funciona o Canary Deployment ) e o autoscaler de nodes Karpenter. Enquanto o canário estava em execução, o Karpenter estava drenando vários pods da aplicação e impactando a latência do serviço.

O que é o Karpenter e o que ele faz?

Imaginem que o Karpenter é o profissional que faz a “faxina inteligente” do cluster (K8s).

Ele fica monitorando constantemente os nós (máquinas EC2) do cluster — e com qual fim?

Basicamente, verificando se as máquinas estão cheias, vazias ou mal utilizadas. Quando identifica que há recursos sobrando, ele pode encerrar máquinas subutilizadas; quando percebe falta de capacidade, ele também pode provisionar novas máquinas.

Ou seja: o Karpenter não só “mata nós”, mas também cria nós novos, conforme a demanda.

Ele é, por definição, um autoscaler de nós — um paralelo ao Keda, que faz autoscaling de pods.

Enquanto o Keda ajusta o número de pods, o Karpenter ajusta o número de máquinas.

E como o cenário de deploy em canário se relaciona com isso?

No canário, acontecem os seguintes passos:

a versão antiga da app ainda fica rodando
a nova versão sobe alguns pods
aos poucos, a nova vai substituindo a antiga — e as duas coexistem por um tempo

Essa coexistência (em vários nós, inclusive novos que foram criados para suportar a nova versão) pode desbalancear o cluster. Por exemplo, alguns pods antigos morrem, outros novos sobem, e alguns nós acabam ficando quase vazios. Quando o Karpenter “vê” esses nós com pouca carga, ele entende que estão subutilizados e começa a agir: drena os pods daquele nó e os realoca em outros nós mais bem aproveitados, para então encerrar a instância EC2.

Mas atenção: o Karpenter não costuma drenar dois nós simultaneamente.
Ele age de forma progressiva, reconhecendo e ajustando o uso à medida que as condições mudam. Um cenário de drenagem em massa só ocorreria se dezenas de pods saíssem ao mesmo tempo, o que é uma situação incomum. Além disso, antes de encerrar o nó, o Karpenter primeiro realoca os pods, o que pode gerar reinícios, mas o serviço tende a continuar ativo durante o processo. Se o comportamento parecer agressivo (muitos pods sendo terminados de uma vez), é sinal de que a configuração está muito sensível e precisa de ajuste.

O papel do PDB (Pod Disruption Budget)

Aqui entra o PDB, que define um “orçamento” de quantos pods podem ser interrompidos ao mesmo tempo. Com ele, você instrui o cluster e o Karpenter a não drenar todos os pods de uma vez.

Ex.: imagine que você tem 10 pods no ar
Sem PDB:

O Karpenter decide apagar 2 nós
Cada nó tem 5 pods
Ele drena ambos ao mesmo tempo
A aplicação pode ficar totalmente fora do ar por alguns segundos

Com PDB definido (ex.: 80% dos pods devem permanecer ativos):

O Karpenter e o K8s drenam no máximo 2 dos 10 pods de cada vez
A app continua disponível e a transição ocorre de forma suave

Assim, o PDB protege a operação e evita alta latência ou indisponibilidade total.

Interação entre Keda e Karpenter

O Keda escala pods (com base em métricas como fila, CPU, etc.)
O Karpenter escala nós (subindo ou encerrando máquinas EC2).

Cenário comum:

O Keda detecta fila cheia e escala de 2 → 10 pods
A fila processa rápido, e o Keda reduz a quantidade de pods novamente
O Karpenter percebe nós quase vazios e começa a drenar e encerrar máquinas

Tudo certo — até aqui.

O problema aparece quando os tempos de reação dos dois não estão bem sincronizados.

Isso pode causar a famosa flutuação de pods:

Keda escala os pods por conta da fila cheia → Karpenter cria novos nós
A fila processa rapidamente e o Keda reduz a quantidade de pods → Karpenter ainda pode está criando máquinas novas
Karpenter detecta baixo uso → começar a drenar e desligar as máquinas
Fila volta a encher → Keda tenta escalar → não há nós disponíveis (Karpenter ainda matando as máquinas)
Pods ficam Pending → Karpenter começa a criar novos nós

E o ciclo se repete até estabilizar.

Por isso, é importante parametrizar um autoscaling menos agressivo, definindo intervalos maiores entre upscale e downscale, e limitando quantos pods podem escalar por vez.

Impactos em aplicações Java

Durante essa flutuação, apps Java sofrem bastante, porque:

Cada novo pod leva um certo tempo para “aquecer” (JIT, cache, pools, conexões...)
Pods sobem e morrem antes de ficarem prontos

Resultado:

Aumento no tempo de resposta da app
Perda de vazão
Mais tempo de GC inicial
É comum muitos logs de started e shutdown

Quando pods novos degradam pods antigos

Mesmo com anti-affinity configurado (o que evita que vários pods do mesmo serviço caiam no mesmo nó), é possível que novos pods subam em nós já ocupados. O K8s agenda pods com base nos requests declarados
— que funcionam como reserva de capacidade. O Karpenter e o K8s garantem essa reserva, ou seja, não realocam mais pods do que cabe nos requests. Se sobrar capacidade, ela pode ser usada sob demanda até o limit configurado.

Ex.: imagine um nó com 4 vCPUs

2 pods limitados (limit, não request) a 2 vCPUs cada
O cluster tenta subir mais um pod no mesmo nó
Agora temos 3 JVMs disputando 4 CPUs

Durante o start do terceiro pod, ele consome muita CPU (JIT, cache, inicialização...), o que afeta o desempenho dos pods antigos. Isso pode aumentar a latência e até induzir o Keda a escalar mais pods (se estiver usando CPU como trigger), piorando ainda mais a situação.

O velho problema do readiness

Se um readiness probe estiver mal configurado, ele pode marcar um pod como “OK” antes de estar realmente pronto.

O resultado: o balanceador envia tráfego para ele, as respostas demoram, surgem picos de latência e, em alguns casos, o próprio K8s começa a matar e recriar pods — um ciclo de degradação.

Outro ponto crítico: conexões de banco

Quando novos pods sobem, eles normalmente criam novas conexões no banco, criam conexões com outros serviços (kafka, rabbitMQ...) e tentam se registrar em um service discovery, entre outras coisas. Se não houver limite de conexões no banco, o mesmo pode ficar sobrecarregado e/ou começar a recusas conexões, afetando assim os pods antigos que já estavam no ar no mesmo nó em que os pods novos subiram.

Para além da configuração de recursos e probes: Graceful shutdown

Um das causas mais comuns para restart de pods por “qualquer motivo", é eles continuarem recebendo requests mesmo quando já estão "morrendo", ou como já falado, quando ainda não estão prontos. Uma solução para o primeiro caso é a configuração do recurso de Graceful Shutdown, que evita que o pod seja terminado enquanto ainda recebe requisições. Isso evita ruídos no processo de check de probes (liveness e readiness) e consequente flutuação de pods subindo e descendo, causando aumento de latência e outros efeitos colaterais já mencionados.

Em resumo

O Karpenter é importante para a gestão funcional e financeira do nodes no cluster.
O Keda é importante para a gestão funcional e financeira dos recursos do cluster.
E a engenharia entender como as ferramentas funcionam é importante para configurar os serviços de maneira sustentável e eficaz, fazendo sentido funcionalmente para os clientes (baseado na necessidade) e financeiramente para nós enquanto plataforma.

DEV Community: Dhellano Castro

Virtual Threads in Real Production: Docker, Kubernetes, and What the Dashboards Don't Tell You

Stack Cost and the OOM Kill Risk in Docker

The Equation Changed

Why ZGC?

CPU Throttling in Kubernetes — The Silent Enemy of Carrier Threads

The Mechanism

The Misleading Symptom

Observability with JDK Flight Recorder (JFR)

The Events That Matter

Runtime Diagnosis (No Restart Required)

Prometheus Integration via Micrometer

The Modern Developer's Checklist

Before Enabling Virtual Threads

Docker Configuration

Kubernetes Configuration

Production Observability

Conclusion

References

Source Code

Virtual Threads in Java 21: The End of the Scarcity Era (and the Pitfalls That Can Take You Down)

The Engine Under the Hood

Pitfall 1 — Thread Pinning: The Bolt in the Floor

Pitfall 2 — The Stampede Effect

Mitigation — The Intelligent Handbrake

Semaphore: The Database Doorman

Resilience4j: Mission Control

Want to See the Numbers in Practice?

What's Coming in the Next Article

References

Source Code

Virtual Threads em Produção de Verdade: Docker, Kubernetes e o que os Dashboards não te Contam

O Custo do Stack e o Risco de OOM Kill no Docker

A Equação Mudou

Por Que ZGC?

CPU Throttling no Kubernetes — O Inimigo Silencioso das Carrier Threads

O Mecanismo

O Sintoma Enganoso

Observabilidade com JDK Flight Recorder (JFR)

Os Eventos que Importam

Diagnóstico em Runtime (Sem Restart)

Integração com Prometheus via Micrometer

Checklist do Desenvolvedor Moderno

Antes de Ligar Virtual Threads

Configuração Docker

Configuração Kubernetes

Observabilidade em Produção

Conclusão

Referências

Código-fonte

Virtual Threads no Java 21: O Fim da Era da Escassez (e as Armadilhas que Podem Lhe Derrubar)

O Motor por Baixo do Capô

Armadilha 1 — Thread Pinning: O Parafuso no Chão

Armadilha 2 — O Efeito Manada

Mitigação — O Freio de Mão Inteligente

Semaphore: O Porteiro do Banco

Resilience4j: O Controle de Missão

Quer Ver os Números na Prática?

O Que Vem no Próximo Artigo

Referências

Código-fonte

Gestão de nodes e pods com Karpenter - Perspectiva do Desenvolvedor

O problema

O que é o Karpenter e o que ele faz?

E como o cenário de deploy em canário se relaciona com isso?

O papel do PDB (Pod Disruption Budget)

Interação entre Keda e Karpenter

Impactos em aplicações Java

Quando pods novos degradam pods antigos

O velho problema do readiness

Outro ponto crítico: conexões de banco

Para além da configuração de recursos e probes: Graceful shutdown

Em resumo

Documentação de apoio