Java 21 introduced virtual threads as a new concurrency model designed to simplify asynchronous programming. Instead of carefully managing thread pools and non-blocking APIs, developers could write straightforward blocking code and still achieve high scalability.

In practice, this works well for many workloads. However, under certain conditions, virtual threads behave very differently than expected. A key issue is pinning, where a virtual thread becomes tied to its underlying platform thread, preventing efficient scheduling.

This article explains why pinning occurs in Java 21, how it affects performance, and what changes in Java 24 through JEP 491.

First, a refresher on Virtual Threads

Virtual threads are scheduled by the JVM rather than the operating system. Multiple virtual threads are multiplexed onto a smaller set of platform threads, often referred to as carrier threads.

This design allows applications to handle a large number of concurrent tasks without requiring a proportional number of OS threads. The key property is that a virtual thread can be suspended during blocking operations, allowing the carrier thread to run other work.

This suspension and remounting behavior is what enables scalability.

The Pinning Problem

In Java 21, virtual threads can become pinned to their carrier threads. When this happens, the virtual thread cannot be unmounted, and the carrier thread remains occupied.

Pinning typically occurs when a virtual thread executes within a synchronized block or method and performs a blocking operation.

At a high level, this breaks the expected behavior of virtual threads. Instead of releasing the carrier thread when blocked, the virtual thread holds onto it, reducing overall concurrency.

Why Pinning Happens

The root cause lies in how synchronized is implemented.

A synchronized block relies on a monitor lock to enforce mutual exclusion. These monitors are managed by the JVM at the platform thread level. When a thread enters a synchronized block, it acquires the monitor, and other threads must wait until the lock is released.

With platform threads, this model works as expected. With virtual threads, the interaction is more subtle.

When a virtual thread enters a synchronized block, the monitor is effectively associated with its carrier thread. If the virtual thread blocks while holding the monitor, the carrier thread is also forced to wait. The JVM cannot safely detach the virtual thread from the carrier in this state.

As a result, the virtual thread remains mounted, and the carrier thread cannot be reused.

A Concrete Example

Consider the following method:

public synchronized String getData(Socket socket) throws IOException {         
    return new String(socket.getInputStream().readAllBytes()); 
}

If a virtual thread executes this method and the socket does not immediately provide data, the call to readAllBytes() blocks.

At this point:

• The virtual thread is waiting on I/O

• The monitor lock is still held

• The carrier thread is also blocked

Because the lock is tied to the carrier thread, the JVM cannot unmount the virtual thread. The carrier thread is effectively pinned until the operation completes and the lock is released.

Impact on Scalability

Pinning reduces the effectiveness of virtual threads in two ways.

First, it prevents carrier threads from being reused. Each pinned virtual thread occupies a platform thread for the duration of the blocking operation.

Second, it limits concurrency under contention. If multiple virtual threads compete for the same monitor and perform blocking operations, the system begins to resemble traditional thread-per-request models.

This is particularly problematic in I/O-heavy systems, where blocking is common and virtual threads are expected to provide the most benefit.

Workarounds in Java 21

To avoid pinning, developers often replaced synchronized with alternatives such as ReentrantLock or redesigned critical sections to avoid blocking operations while holding locks.

These approaches can reduce the likelihood of pinning, but they introduce additional complexity and move away from the simplicity that virtual threads were meant to provide.

The Java 24 Fix: JEP 491

JEP 491 addresses this limitation by changing how virtual threads interact with monitor locks.

In Java 24, virtual threads are no longer pinned when contending for or holding monitors in the same way as before. The JVM allows virtual threads to be unmounted even when synchronization is involved, ensuring that carrier threads can continue executing other tasks.

This change preserves the semantics of synchronized while restoring the scalability benefits of virtual threads.

What This Means in Practice

With the improvements in Java 24:

• Blocking inside synchronized code no longer necessarily ties up a carrier thread

• Virtual threads can be suspended and resumed more freely

• The scheduler can maintain higher throughput under contention

In effect, developers can use synchronized without undermining the core advantages of virtual threads.

Conclusion

Virtual threads simplify concurrent programming, but their behavior depends on subtle interactions within the JVM.

In Java 21, pinning exposed a limitation in how synchronization and scheduling worked together. Under specific conditions, virtual threads could lose their lightweight nature and behave more like traditional threads.

Java 24 resolves this with JEP 491, making virtual threads more predictable and scalable in real-world scenarios.

Understanding these details is important when adopting new concurrency models. The abstraction is simple, but the underlying behavior still matters especially at scale.