Java virtual threads affect observability and monitoring strategies need to be adjusted to adapt. 1. The thread ID is no longer unique, and traditional tools are difficult to locate problems; 2. The thread name in the log is invalid, and MDC and distributed tracking are required to connect the request link; 3. The existing APM tools are insufficiently supported, so JDK should be upgraded and new tools such as JFR should be used; 4. The framework and community are gradually adapted, and we need to continue to pay attention to progress.

Virtual Threads in Java are one of the key features introduced by Project Loom, which greatly improves Java's performance and scalability in high concurrency scenarios. But at the same time, the introduction of virtual threads has also brought new challenges to observability. Traditional monitoring methods based on operating system threads often seem powerless when facing thousands or even hundreds of thousands of virtual threads.

Let’s take a look at the specific impact of virtual threads on observability and how we should deal with it.

Virtual threads change the thread model

Virtual threads are essentially lightweight threads managed by the JVM. They do not map directly to the threads of the operating system like platform threads, but are reused on a small number of platform threads through a scheduler. This design makes it very easy to create hundreds of thousands of virtual threads, but it also means:

• Thread ID no longer uniquely identifies an execution unit
• Traditional thread name, thread status and other information have become insufficient
• The stack trace may contain a lot of information about virtual thread switching, making it difficult to quickly locate problems.

If you used to checking blocking or deadlocking through jstack or APM tools before checking the thread stack, you may now find that these tools "can't see clearly" the relationship between virtual threads.

Logging requires clearer context

In a multithreaded environment, the thread name is usually recorded in the log to help track the request processing path. However, in virtual thread scenarios, the thread name changes frequently and the life cycle is short, which will make the thread information in the log lose its reference value.

For example: You see a bunch of VirtualThread[#234]/runnable in the log, and you don't know which request or task it belongs to.

Solutions to this problem include:

• Use MDC (Mapped Diagnostic Context) to record unique identifiers at the request level, such as trace ID or request ID
• In conjunction with distributed tracking systems (such as Jaeger and OpenTelemetry), the execution paths of virtual threads are associated
• In asynchronous or structured concurrency, ensure context information is passed between tasks

In this way, even if the thread changes, you can connect the related operations and see the entire calling link clearly.

Monitoring and diagnostic tools require upgrade support

At present, many Java monitoring tools cannot recognize virtual threads well. For example, some APM tools may only count the number of platform threads, and ignore the actual operation of virtual threads.

To improve observability, you can:

• Upgrade to JDK 21 and use the latest version of diagnostic tools that support virtual threads (such as JFR)
• Leverage new APIs provided by the JVM (such as Thread.ofVirtual() ) to clearly distinguish between virtual threads and platform threads
• Pay attention to the progress of community and vendor observation support for virtual threads. For example, frameworks such as Spring, Micronaut, Quarkus have begun to adapt

JFR (Java Flight Recorder) is a good choice in this regard. It can already support event recording and analysis of virtual threads, and can be used to track virtual threads' scheduling, blocking, CPU usage, etc.

Let's summarize

Although Java's virtual threads improve concurrency capabilities, they also break our previous monitoring and debugging methods of threads. To maintain good observability, we need:

• Replace the log policy that depends on the thread name and use the request-level context instead.
• Upgrade your monitoring and tracking system to support virtual threading
• Use JFR and new JDK APIs to gain insight into virtual thread behavior

Basically that's it. After all, virtual threads bring not insurmountable obstacles, but a new normal that requires us to adjust our thinking to adapt.

The above is the detailed content of Java Virtual Threads and Observability. For more information, please follow other related articles on the PHP Chinese website!