JDK 24 Updates Virtual Threads, Shifting Production Risks and Introducing Scoped Values

Virtual Thread Enhancements in JDK 24

JDK 24's JEP 491 eliminates monitor-related carrier pinning, which previously posed risks for synchronized blocking code when deploying Java 21 virtual threads. While some residual pinning remains for native frames, class loading, and local file I/O on Linux, this update significantly improves virtual thread stability. The JDK Flight Recorder (JFR) jdk.VirtualThreadPinned event continues to be a crucial part of the rollout checklist for identifying these remaining pinning instances.

Shifting Production Risks

With the reduction of carrier-thread pinning, the main production risk for virtual thread deployments has moved from carrier-thread starvation to downstream-resource exhaustion. As virtual threads remove the servlet-thread ceiling, concurrency is now limited by factors such as connection pools, rate limits, file descriptors, and the capacity of downstream services. This requires developers to re-evaluate how these resources are managed in high-concurrency environments.

ThreadLocal Caching Issues

Under virtual threads, ThreadLocal caching silently ceases to function as expected. Benchmarks showed a ThreadLocal.withInitial() cache being initialized 2,216 times more frequently under virtual threads compared to platform threads for the same workload. This unexpected behavior initially manifests as unexplained garbage collection pressure, indicating that ThreadLocal is not suitable for caching in virtual thread environments due to its assumption of thread reuse.

Introduction of Scoped Values

Scoped Values, finalized in JDK 25 via JEP 506, are presented as the appropriate replacement for application-owned request context. They address the propagation issues associated with InheritableThreadLocal and automatically propagate into StructuredTaskScope child tasks. A notable API change during finalization is that ScopedValue.orElse(null) is no longer permitted.

Architectural Considerations

Virtual threads simplify blocking request-response services but do not replace the need for reactive backpressure mechanisms. The combination of Spring MVC with virtual threads is recommended as a strong default for services involving blocking I/O. For streaming, Server-Sent Events (SSE), WebSockets, and systems sensitive to backpressure, Spring WebFlux remains the preferred choice.