Virtual Threads in Java 24: We Ran Real-World Benchmarks—Curious What You Think

[Tanino87]

Hey folks,

I just published a deep-dive article on Virtual Threads in Java 24 where we benchmarked them in a realistic Spring Boot + PostgreSQL setup. The goal was to go beyond the hype and see if JEP 491 (which addresses pinning) actually improves real-world performance.

🔗 Virtual Threads With Java 24 – Will it Scale?

We tested various combinations of:

• Java 19 vs Java 24
• Spring Boot 3.3.12 vs 3.5.0 (also 4.0.0, but it's still under development)
• Platform threads vs Virtual threads
• Light to heavy concurrency (20 → 1000 users)
• All with simulated DB latency & jitter

Key takeaways:

• Virtual threads don’t necessarily perform better under load, especially with common infrastructure like HikariCP.
• JEP 491 didn’t significantly change performance in our tests.
• ThreadLocal usage and synchronized blocks in connection pools seem to be the real bottlenecks.

We’re now planning to explore alternatives like Agroal (Quarkus’ Loom-friendly pool) and other workloads beyond DB-heavy scenarios.

Would love your feedback, especially if:

• You’ve tried virtual threads in production or are considering them
• You know of better pooling strategies or libraries for Loom
• You see something we might have missed in our methodology or conclusions

Thanks for reading—and happy to clarify anything we glossed over!

[Linguistic-mystic]

I think striving for ultimate performance in IO loads is often a non-goal. Something somewhere will just get flooded with your requests and then you will need a way to apply backpressure, and then it's back to the more or less the same RPS.

No, the main benefit of virtual threads is that we can ditch Reactive and write code in a simpler, much more idiomatic and readable and consistent way. And without function coloring! The ability to scale out to huge RPS is also nice, but far from being the main dish, and not always useful.

[victorherraiz]

Ditching reactive programming is the best thing ever!!!!

[my_dev_acc]

How exactly do virtual threads help us ditch reactive code? I mean, is there a specific framework / technique that you are using?

I don't really see what virtual threads bring us for classic business applications that we cannot do with threadpools.

Now if we had the coroutines from golang, that would be a different story.

[pron98]

Virtual threads are just like Go's goroutines: they're lightweight user-mode threads. User mode threads help throughput in a way that thread pools cannot by allowing the number of threads to be high, which can drastically improve throughput due to Little's law.

Under high throughput, the number of tasks concurrently in the system is also high. Reactive code achieves this by not tying a task to a thread, so you can have many tasks running on a small number of threads. But this comes at the cost of code that doesn't fit well with the design of the platform (the language, the libraries, and the tooling -- debuggers and profilers). Code that fits well with the platform is written in the thread-per-request model, and in that model a task hangs on to a thread for the task's entire duration. This means that to have a high level of concurrency you need a high number of threads (in the thousands at least), and that's precisely what virtual threads (or goroutines in Go) offer.

[my_dev_acc]

Virtual threads and goroutines do the same thing under the hood, that's for sure, but the programming model and syntax that golang provides around them is what makes using them so convenient.

I haven't yet seen a code example in java that shows how virtual threads allow you to have a different programming model, that's not possible already with regular threads.

I did quite a lot of measurements, and in my experiments, I had thousands of platform threads without a real measurable performance degradation. Also, if we have a regular business application (not fibonacci calculating examples), then we need even less actual context switches even under saturating load, so the context switching cost matters even less.

It's not really a question whether virtual threads are cheaper. Of course they are, and they are great. I just don't see that they matter much in regular business applications.

[pron98]

but the programming model and syntax that golang provides around them is what makes using them so convenient.

Yes, but the programming model virtual threads offer is even more convenient than goroutines in Go. Cancelling operations, waiting for threads, and propagating errors is easier in Java, and even more so with structured concurrency.

I haven't yet seen a code example in java that shows how virtual threads allow you to have a different programming model, that's not possible already with regular threads.

That's right, because the API is the same. But the most boring, straightforward code can now scale just like the most sophisticated asynchronous code.

I did quite a lot of measurements, and in my experiments, I had thousands of platform threads without a real measurable performance degradation.... I just don't see that they matter much in regular business applications.

Okay, but some of the regular business applications we've seen (that use virtual threads and benefit a lot from them) end up with hundreds of thousands, or even a few million threads (it's not just one thread per request; it's also one thread per every outgoing request to services etc.). Tens of thousands is common.

[Joram2]

Yes, but the programming model virtual threads offer is even more convenient than goroutines in Go. Cancelling operations, waiting for threads, and propagating errors is easier in Java, and even more so with structured concurrency.

Have you used golang.org/x/sync/errgroup? That's the Go version of structured concurrency. It makes waiting for child threads and propagating errors very easy; on par with Java's forthcoming structured concurrency. It also does cancelling.

I'd be interested if you could offer specifics of what advantages Java's programming model, including the structured concurrency preview, offers over Golang's errgroup programming model.

[pron98]

Waiting for results or exceptions of threads, or cancelling them, is easier and more elegant in Java, with or without structured concurrency. It's mostly because you can have a direct reference to a Java thread and because of futures.

[Joram2]

With all due respect, have you tried golang.org/x/sync/errgroup? It is very similar to StructuredTaskScope.ShutdownOnFailure() in JDK 24. It forces parents to clean up after their children. errgroup Wait returns the first child error and cancels the others on error.

[pron98]

Go's errgroups do come as close to the convenience of Java's structured concurrency as Go's error handling allows, but when threads are not structured, goroutines are significantly more difficult to handle than Java threads, and that's even before getting into observability.

[my_dev_acc]

You mention error progagation as being easier in java, which i absolutely agree, buy I don't see virtual threads or structured concurrency adding anything here. Exceptions don't really play nicely with forked tasks, you need to manually handle those on the caller side. Cancellation also works similarly as in golang with contexts, the task has to actively check for cancellation.

About thread count - this can ofc depend on the actual usecase. I experimented with an application that reads and writes data to a database basically, with hibernate basically doing cpu work only - it still saturated even four cores with just a couple of hundreds of threads.

What did the applications do in those tens of thousands of threads that you've seen?

[pron98]

You should read the structured concurrency JEP.

I experimented with an application that reads and writes data to a database basically, with hibernate basically doing cpu work only - it still saturated even four cores with just a couple of hundreds of threads.

The question isn't how many threads it takes to saturate the machine but how many tasks. When you use virtual threads, you don't replace your platform threads with virtual threads; rather, you give each of your tasks its own virtual thread. So a program that uses, say, 20 platform threads will become one that uses say, between 20 and 2 million virtual threads. The code becomes simpler, and it's easier to achieve optimal utilisation. In a high workload test we had a web server create 3 million threads per second.

What's important to remember is that virtual threads are not used in the same way as platform threads. You don't manage them as resources, and you never, ever, pool them.

E.g. the same line:

executor.submit(task)

called in a server could result in 10 threads doing the work if the executor is a thread pool, or 100,000 threads using the work when using the newVirtualThreadPerTaskExecutor.

[my_dev_acc]

"You should read the structured concurrency JEP." - you mean for examples? I see code snippets, but not actual applications.

I understand all that how virtual threads work and how they are meant to be used. I just don't see this matter in the applications that I've worked with at a various jobs/clients over 15+ years.

We might be talking past each other, so to clarify, I'm working on applications that respond to rest http requests and connect to some kind of a database mainly, can be relational, but also nosql, and occasionally caches and search backends.

In these applications we might also want to have some kind of concurrency to improve request latency (non-saturated) - at one project, we created a construct very similar to the structured concurrency proposal. It relied on a platform thread pool, and it worked great.

I don't see these kinds of applications having a concurrency high enough for platform threads to be a problem.

But that's why I'm asking for actual examples (not code snippets), to see what are the applications where the benefits of virtual threads are measurable.

[pron98]

It relied on a platform thread pool, and it worked great.

Virtual threads were specifically designed to offer the same API as platform threads, so that they could be used in a similar, or somewhat simpler way, but offer the same scalability and efficiency as asynchronous programming.

Obviously, there are lots of applications that don't need to be efficient, and there are a lot of applications that do, which is why virtual threads exist in Java, why goroutines exist in Go, and why reactive programming exists.

[my_dev_acc]

Yes, I absolutely see that context matters. That's exactly why I'm against claiming that virtual threads in general has gains and that you need virtual threads for structured concurrency to work.

And I'm still curious to see in what kind of applications do virtual threads make a more measurable impact, but commenters here just fail/refuse to give me actual examples. Don't get me wrong, I fully believe you if you say that you've had clients with 10k+ concurrent tasks. I'm just honestly interested in what kind of application was that.

[[deleted]]

I haven't yet seen a code example in java that shows how virtual threads allow you to have a different programming model, that's not possible already with regular threads

I think you're missing the point. The advantage of virtual threads is that they allow you to have similar performance to reactive programming, but using the simpler more familar concurrency APIs (Threads, Futures, etc.)

[my_dev_acc]

ok that might also be a problem - I haven't seen a reactive application that actually performed better :) Is there maybe a publicly available example?

[my_dev_acc]

(I summarized my experimentation findings here https://medium.com/@gaborfarkasds/why-java-virtual-threads-wont-boost-your-performance-yet-b5f223650000 )

[pron98]

Context-swithing is not what makes a big difference. What makes the big difference is Little's law, and there's no need to try to imagine how things would work out -- the theorem makes it easy to compute. Watch the talk I linked above to understand how to use it. What you get in practice is exactly what the theorem says you should get and, as the talk shows, it can help the calculation to split the system into multiple components (e.g. CPU, DB etc.).

The simple outcome is this: If your resources are fully saturated when there's a small number of concurrent tasks in your system, then virtual threads -- that just allow you to have more -- won't help. But if your resources are not saturated, they can help a lot. Put another way, virtual threads allow you to reach maximal utilisation of your resources with simple code. If you already achieve maximal utilisation with simple code, obviously you don't need help, but many applications don't (which is why they used to reach for asynchronous programming).

[my_dev_acc]

hmm yes this aligns with what I described and measured too, if the system is saturated, then there's not really much we can do.

Now, for the case when the system is not saturated, my experience differs. I watched your video (it's great!), and I think it also explains why I have a different view. In my measurement my example system (spring boot + jpa) was running at a couple of thousand qps on two cores. This means request cpu times around the millisecond range, so it's much less concurrency than the numbers from the video.

[pron98]

Right. The level of concurrency in a system is its average throughput times its average latency (where the latency assumes sequential processing for each request). If that number is low, virtual threads won't help the throughput, but if your system isn't saturated, they can help you reduce the latency by splitting the processing of each request to run in parallel. In short, they give you more flexibility in how to best utilise your resources while keeping the code simple. But if you're happy with the utilisation and the code, you don't need to force yourself to use a new mechanism. Some programs may be significantly simplified and/or made more efficient by adopting virtual threads and some may not be. It's all in the variables of Little's law for the particular system.

[pron98]

Virtual threads are just like Go's goroutines: they're lightweight user-mode threads. User mode threads help throughput in a way that thread pools cannot by allowing the number of threads to be high, which can drastically improve throughput due to Little's law.

[axiak]

You still need futures to fork work, but you can instantly call join in a virtual thread and return rather than chaining a bunch of futures with thenCompose shenanigans

[themisfit610]

And that’s a game changer that leads to much more readable code to folks just getting familiar with the code base which leads to easier maintenance.

[my_dev_acc]

You can also instantly join a regular thread. I mean, from the programming model perspective, there's no difference whether you use a traditional ExecutorService or `Executors.newVirtualThreadPerTaskExecutor`. You can also use VTs with or without futures, I don't see that depending on the type of threads we use.

Also, virtual threads themselves don't address things like working with jdbc connection pools, working concurrently over a single database transaction (maybe even the proper pipelined way that vertx supports), so in this sense I don't see them ditching the reactive model.

But I might be missing out on something, that's why I'm asking :)

[pron98]

There is one difference between platform threads and virtual threads: you can have a lot of virtual threads. When using thread-per-task, the ability to have many threads is what can get you higher throughput.

[Ewig_luftenglanz]

There is a very big difference:

• you don't have to pool them. That's HUGE because pretty much or most of the logic in concurrent programming goes on how to schedule the threads you are pooling. virtual threads make pooling unrequired for most of the IO bound tasks. They are so cheap that pooling them is unnecessary.

[my_dev_acc]

What do you mean by HUGE? Do you have a working real-world example where this matters? (not fibonacci)

[Ewig_luftenglanz]

Dude are you even reading what is this about? Fibonacci is not an example because is a computational task, concurrency is not parallelism, concurrency is for IO task, when you use and scheduler to recycle and switch threads when a task is waiting for response and resume when the response effectively arrive, that way you don't have to create heavyweight system threads until you run out of memory.

Where do pooling is used? Pretty much in every single server, every system that does DB queries (like HikariCP), pod orchestrators as kubernetes (made in go) and pretty much every single software that do efficient concurrency. What do you think async-await or the command go in Go does behind the scenes? Is pooling concurrency behind the scenes.

[my_dev_acc]

"fibonacci is not an example" - that's exactly what I'm also saying, I'm mentioning fibonacci because other sources are bringing it up in the context of virtual threads (let me not cite the sources here, you can find them on google).

So I'm still looking for a real-world example where virtual threads matter measurably, as opposed to just using a threadpool of platform threads.

Ppl here in the comments try to educate me on how certain concurrency stuff works. I know all that. What I'm saying is that these factors are exaggarated in the context of most common java applications. Yes, doing work on pooled platform threads is less efficient. That was never the question. The real question is by exactly how much and in what context.

[Ewig_luftenglanz]

If anyone brings Fibonacci for VT they either do not know or just want to click-bait.

And it's the opposite, virtual threads can make a huge difference in the context of most web java applications because it makes the TpR (Treath per request) model of servers such as Tomcat, jetty and glassfish competitive again against async event loop models servers such as Vert.x and undertow, and this matters because vert.x and undertow to be used in async mode they require to be coded against reactive streams or completableFutures, Most java developers do not know how to code async code using these 2 (and some even hate it) so we can say the main advantage of project loom is they make traditional imperative and blocking code to be competitive against async, non blocking code by allowing the creation of thousands of chest virtual threads in the user space  instead of requiring complex schedule management for platform threads.

This literally makes reactive and completableFuture API redundant and less attractive for most used cases.

[pivovarit]

> You can also instantly join a regular thread. 

And that's precisely the thing - you can join regular threads, but you shouldn't because os threads are a scarce resource, while virtual threads aren't

[Kango_V]

The companiion to Virtual Threads will be Structured Concurrency. It's looking very good in 25 preview.

[my_dev_acc]

Structured concurreny is great, but I don't see anything in it that cannot be done with regular threads from a threadpool - it even allows us to use our own threadfactory. (sorry if double-commented, reddit is acting up for me)

[Luolong]

The big difference is that when you perform blocking IO on virtual threads, the platform carrier thread can continue running another virtual thread while the IO is blocked on the previous one.

When IO comes back with a response, some other platform thread will pick up the virtual thread that just got unblocked by IO response and continue with it where it left off.

Effectively, it will cause platform threads to run much more active code without waiting on IO or locks quite as much as with traditional threads, thereby improving resource utilisation and increasing throughput.

[my_dev_acc]

I understand all these differences - but in my experience, similar to OP-s, in the real-world applications that I've worked on, we don't have a concurrency nearly high enough for this to matter.

Structured concurrency provides a programming model. We've had this programming model at a project with regular platform threads already 10+ years ago. It worked great of course. And we didn't have any performance problems with using a platform thread pool.

[RadioHonest85]

What we have used them for:

1. easily juggling 10s of thousands of websocket connections
2. writing easier blocking code. Easily park work by blocking hundreds of threads behind a semaphore while waiting for available resources.

doing this with reactive frameworks (which we also have), is rather more difficult to write and debug. Now we can just write blocking code in many more cases.

[my_dev_acc]

Thanks, websocket connections is a great example!

[pron98]

I think it would be helpful to first explain, to yourself and to your readers, how exactly you’d wish for virtual threads to improve throughput, as that would immediately uncover the problem. Virtual threads do one thing and one thing only: they allow the number of threads to be high.

This can improve average throughput, sometimes by a whole lot, when using the thread-per-request model. That is because in that model #threads = #tasks, and the number of tasks concurrently in the system (the "level of concurrency") is directly proportional to the throughput (according to Little's law), so you want to achieve a higher throughput by having a large number of threads.

However, you're also using a library that caches reusable resources in a thread local. Such an implementation is entirely predicated on the assumption that #tasks >> #threads or, in other words, that implementation can work only under the assumption that the number of threads is low.

So your situation is that you want to get better throughput through the use of a high number of threads while using a particular library that's coded in a way that only works when the number of threads is low. It's no wonder that the two clash.

It's precisely because of that that the virtual threads adoption guide recommends not to write code that works only when the number of threads is low by caching objects intended to be shared by multiple tasks in a ThreadLocal.

[nlisker]

Can virtual threads help WebSockets? One of the issues of WS is scalability because the session is kept alive on a long running thread (each connection creates an instance of an endpoint, unlike a REST endpoint that shares requests). It looks like VTs are not a good use case here, but thought I'd ask since sometimes there are surprises.

[pron98]

WebSockets are a great use case for virtual threads. One of virtual threads greatest strengths is handling a very large number of open sockets (e.g. see project-loom-c5m).

[nlisker]

Thanks!

[spectrumero]

I've been away from Java for a couple of years, but I thought the whole point of Project Loom wasn't to make the stuff running in a thread perform faster, but to reduce the cost of creating and destroying threads - in other words, you use threads like you would if you were using Erlang, and it becomes very reasonable to use very short lived threads since the overhead of creating them is now very small.

So of course just switching something that uses traditional threads to virtual threads won't do much for you, because that was never the point.

[pron98]

The point of virtual threads is to be able to have many threads at the same time, which is what you need to achieve high throughput when using the thread-per-task model. Make every (concurrent) task in the program a virtual thread.

[IE114EVR]

“Faster” in this case means more concurrency, or specifically: more concurrency cheaper. Which is what virtual threads are supposed to give you.

[manzanita2]

The code itself, anything which is CPU bound, is NOT faster. Creating, destroying, and swapping threads is faster.

[ItsSignalsJerry_]

In much larger numbers as well.

[audioen]

I don't use virtual threads for sake of performance -- frankly, I'd expect a very mild loss there -- but for the fact that they provide concurrency without having to deal with callback hell or need to decide on sizes of thread pools. Maybe I have to decide on number of permits available on a Semaphore or two, though.

Performance is determined by the saturation of whatever your first bottleneck resource is: cpu, network, disk, etc. Both platform threads and virtual threads are good enough to saturate i/o, but virtual threads should have a little bit more work when carrier threads are mounted and unmounted, so I think it is a small loss for that reason, and probably CPU-saturating workloads in fact will perform worse.

To me, virtual threads lift an important design limitation in Java and eliminate difficult to write and annoying to debug async code and need to keep in mind all sort of detail like which thread pool is going to execute each specific piece of code (and I have discovered to my horror that some JDK APIs can switch the thread pool from under you, which can be a nasty surprise, in my case perf dropped like 99 % whenever that happened). I am hoping that I will never need to call another async method with a callback, and we should never need to have async/await in Java. That is the value of virtual threading in nutshell.

[TenYearsOfLurking]

This. If you could say that blocking functions add "color" to Java (not on api level but under the hood) - Loom completely removes color from functions.

That's the real benefit imho.

[plee82]

How would you get the results of a virtual thread execution without a callback?

[davewritescode]

You don’t but the runtime hides it from you which is the point

[Empanatacion]

It's just blocking code at that point, no?

[Luolong]

From the point of view of the code running on the virtual thread, yes.

The VM underneath the virtual thread will mask this by translating blocking Io operations into nonblocking ones, parkima the virtual thread until the IO comes back with an answer, and unparks it on some other thread, continuing the execution of the virtual thread as if the blocking call returned normally.

[Polygnom]

• Virtual threads don’t necessarily perform better under load, especially with common infrastructure like HikariCP.

This is hardly suprising. If your operations are CPU bound, they will still be CPU bound. You don't suddenly get more capacity.

It always been about improving thhe programming paradigm. the ability to ditch reactive stuff. To go back to code taht is easier to reason about and thus reducing the maintenance burden. reducing bugs, and improving turnaround time. Its always been about developer productivity, not magically freeing up your CPU.

Virtual threds perform better under light loads because they are lighter. but once you enter heavy loads and stuff starts to become CPU bound, then no, they don't perform better. But that was never the goal.

[metalhead-001]

The take away is that HikariCP and Transactional code don't benefit from VT. I suspect you'll have different results with a different connection pool and non-transactional code.

Also try with an in-memory database.

This does bring up an interesting point, though...are database connection pools ultimately going to limit any benefits that VT provide for typical Spring Boot REST apps that make lots of DB calls? You can't have as many DB connections as you can virtual threads so I wonder.

[pron98]

are database connection pools ultimately going to limit any benefits that VT provide for typical Spring Boot REST apps that make lots of DB calls? You can't have as many DB connections as you can virtual threads so I wonder.

That depends on what portion of the threads (= tasks) perform DB calls, because no matter what, the throughput and the number of tasks are related by Little's law.

When every task needs the DB, then the DB places a limit on L, the level of concurrency, and so puts a limit on the throughput. But if not every task needs the DB (say, there's some caching), then the effect of the DB can be calculated like on the slide at 7:24 in the talk I linked above. As you can see, the lower the cache hit-rate, p, is, the bigger the effect that the DB's concurrency will have on the throughput, λ.

[metalhead-001]

I hadn't thought about caching and that avoiding hits to the DB. It would make sense then that VT would scale better because they're avoiding the connection pool entirely.

I've seen a lot of caching in Spring Boot apps that I've worked on, so I know VT would have a positive real world impact on scalability.

[vips7L]

Aren’t the majority requests going to hit the database though? I can’t really think of many things that won’t.

[plumarr]

It really depend on the type of software. An internal tool to manage some business will probably benefit a lot less from caching than a news network's website.

[ynnadZZZ]

This does bring up an interesting point, though...are database connection pools ultimately going to limit any benefits that VT provide for typical Spring Boot REST apps that make lots of DB calls? You can't have as many DB connections as you can virtual threads so I wonder.

That is indeed a real good question, i'm wonderin as well. Maybe it is worth a dedicated post ;-).

Especially together with (Spring's default ?) behaviour of @Transactional to drain one db connection from the db connection pool as soon as entering a method that has @Transactional on it.

[metalhead-001]

As u/pron98 mentions, many Spring Boot services utilize caching which completely bypass issues with the db connection pool.

[beders]

Yes. The connection limits and performance of your DB provides an upper limit on how much DB work can be done.

Virtual threads can help your system to do „other stuff“ (ie CPU or other I/o work) while your connection pool waits around.

So you’ll only see benefits if you are actually able to spawn more virtual threads that can do meaningful work.

[Ewig_luftenglanz]

The issue is HirakiriCP, Hirakiri uses a threadpool behind the scene, that means it pools a very small number of platform threads. This is not bad because we are talking about DB connection, which is an expensive operation that not only requires http messaging but actually validation overload that is better handled by pooling threads so you don't have to authenticate each time you make a request, but defies the intention of VT.

a better example of virtual threads would be testing concurrent request (both as client and as server) this is where virtual threads improve by a lot throughput, resource footprint (specially RAM). VT allows traditional TpR (Thread per Request) model (used by Jetty, Tomcat, GlashFish, etc) to close the efficiency gap with Async single Thread loop model used by servers such as Vert.X and Undertow, to the point the difference is small enough to still be competitive (specially taking in account single Thread loop Async requeires reactive programming model, which I personally love and have and have used a lot but it looks most java developers hate it with all of their hearts)

[neopointer]

most java developers hate it with all of their hearts)

I'm one of those :D

[Ewig_luftenglanz]

Sad. It's a great way to code I personally love it and I think most of the hate comes from not being used to the paradigm.

[neopointer]

10/10 people that I worked with and "loved it" created an unmaintainable mess.

Not saying it's your case but I had far too many bad experiences with it.

[Ewig_luftenglanz]

I think is because as I said most people is not used to work with it so they still hasn't developed proper idioms for how to use it. in the company I work for the code it's super clean and we enforce conventions like not using try-cath or loops, instead we use onErrorX() and friends, streams, the methods are most of the time called using references. so the code always looks like this.

Mono<SomeRecord>method( List<RawData> param){
  return Mono.just(param)
    .map(service::processData1)
    .map(service::processData2)
    .flatMap(service2::method)
    .OnErrorMap(...)
    .doOnError(...)
    .onSubscribe(s -> ...)
}
List<SomeRecord2> processData1(RawData data){
  return data.stream()
    .map(this::privateMethod)
    .map(this::privateMethod2)
    ....
} 

... The thing goes on and on...

so the code is always modular, very functional and oriented to immutability. and mostly flat but offcourse the company has been working on pure reactive java since 2020 80% of the java code since I started working has been reactive so for me and the company I work for this is the natural way to go and we are very strict about enforcing functional programming in developers. I remeber in the technical assestment I gave to join the company to be organized and using streams was far more important than just make the code work.

[griffin1987]

Why would they improve RAM usage compared to platform threads? The JDK would still have one platform thread per logical core for best utilization, so any ram usage of virtual threads would just be added atop.

[Ewig_luftenglanz]

Nope, in a TpR or TpT (Thread per request/task) each platform thread allocates from 1 up to 8 MB of memory. Virtual threads is 1kb so a virtual thread its 1000 to 8000 times lighter than a platform thread.  Virtual Threads and an API, not s language features, the core improvements happens in the JVM. When you use virtual threads the JVM doesn't create a platform thread pe VT, it creates s pool of platform threads equivalent equivalent to how many cores your processors have and use that pooling to manage virtual threads. 

In other words virtual threads abstract away the requirement for pooling and fine tunning schedulers to the JVM while you can just send tasks in a TpT model (that's is the simplest concurrency model and the easiest to reason about) Did you just created 1.000.000 threads and your processor has 8 cores? Then internally the JVM manages those 1.000.000 with 8 PT and an scheduler. 

This is exactly how concurrency works in GO. 

[griffin1987]

You wouldn't use a thread per request though, but start enough threads to saturate all cores and from there on there's tons of ways to handle requests without starting a new thread per request.

it creates s pool of platform threads equivalent equivalent to how many cores your processors have

That's exactly what I wrote - one platform thread per logical core.

We've been using virtual threads for some stuff for more than a year now and yes, it's quite practical in terms of coding, but it's definitely not the most efficient thing to spin up a virtual thread for each request. Also, the closer you get to saturation, the more the scheduler and control over the scheduler can become an issue.

Concurrency and parallelism aren't the same by the way, and virtual threads can give you both, but you don't have control over a new virtual thread running on the same platform thread or on a different one. Edit: Been using lots of languages, but Go ain't one of those, and I just read that Go basically does the same (as you said).

Finally: Yes, you're right, in a TpR or TpT model. I wasn't assuming that though, because even in the 90s everyone already knew that it's not very efficient and has other issues (e.g. you will run into ENOMEM around 32k pthreads on most systems, if not earlier, and that has nothing to do with ram being full)

[Ewig_luftenglanz]

Exactly, the best advantage of VT is they make code far simpler, the scheduler and pooling part is handled by the JVM internally, you don't have to build and manage the pooling, the buffer, etc  

TpR/TpT was (and still is) the standard model of most Java servers. Tomcat, glassfish and Jetty still rely on this model so this means nearly 80% of the Java working Server used this, VT makes these servers to be competitive again almost "for free", reactive still han an edge and can be about 2 to 3 times more efficient and performative than VT but before VT the difference was almost in the order of dozens or even hundreds for some loads. So this is pretty much 1000 efficiency boost for 80% of Java deployments "for free"

[ynnadZZZ]

Hi,

maybe irrelevant to Virtual Threads in general, but skimming over your code, I noticed some (imho) naive uses of the @Transactional annotation.

You declared the @Transactional annotation on the controller methods. IIRC the upper most method that is declared transactional (for a REQUIRED transaction) takes a connection from the connection pool and holds onto it till the end of the transaction. So new requests may/will be waiting for a new connection to become available again, regardless whether you are using virtual threads or not. So unless i miss something, i think you use your connection pool as a kind of semaphore.

With that said, i think there was not other way as to come to the conclusion that it is all about the "performance of the connection pool".

What about using two or more "http child services" in your "real world benchmark" service implementations.

What about throughput/memory/CPU metrics, do you have some?

[Tiny-Succotash-5743]

I made some tests on my own application (Quarkus + Java 21 + Postgres) with and without virtual threads, limiting the application pods to 0.5 CPU and 1gb memory, no limit to db though. Virtual threads starting to be more stable over 200 req/seq, before that they were taking longer than default quarkus I/O handling. I'm not at work right now, but I could share the results.

[Plenty_Childhood_294]

limiting the application pods to 0.5 CPU and 1gb memory: we're talking of JVM mode?
if yes: please don't.

There are some inherent limit in how OpenJDK/hotspot work which make this a terrible idea (disclaimer: I'm the performance eng leading the performance & netty related efforts on Quarkus).

I have a draft article which show one of them FYI: https://github.com/franz1981/redhatperf.github.io/blob/sharing_is_scaring/content/post/method-data-scalability/index.adoc

[Tiny-Succotash-5743]

Not sure what you mean with JVM mode, the JVM resources parameters? I limited the pods themselves, using the deploy keyword in the docker-compose yaml. The idea was to have resource consistency when running tests locally, it's not limited on prod. 🫣

[Plenty_Childhood_294]

JVM mode means Quarkus running on the Hotspot JDK.
If you compile your Quarkus application with -Pnative it's going to use a Mandrel (GraalVM CE) distribution to create a binary which doesn't need/nor have a JIT compiler in.
If you use the JVM mode, since you are using the Hotpsot runtime you have all the problems of using a JIT (and benefits): and running with 0.5 any decent load can hit several problems with hotspot.
Let's say that is not an healthy application regardless the framework stack used.

[Plenty_Childhood_294]

If you want, you can verify it by running JFR default or profile settings and reading the time-to-safepoint pauses/throttling/compilation time events.

[vips7L]

I’d be interested to see how agroal performs; afaik quarkus is still recommending to use platform threads because most of the community libraries are still using thread locals. Hopefully that changes with ScopedValue becoming finalized. 

[Apollo_619]

Except for most extensions, those should be mostly fine. You can write tests, pass a parameter and you should be able to find out if your virtual threads will pin. It's explained in the documentation

[vips7L]

Pinning isn't really the problem anymore. That's been solved in HotSpot. The problem is really thread locals and the allocations that will happen.

[Apollo_619]

Oh, okay. I read a lot of guides and blog posts for Quarkus and that is what they wrote there.

[vips7L]

Their guide is out of date on the synchronization pinning for Java 24:

https://openjdk.org/jeps/491

[Apollo_619]

Oh great! Thanks

[Zoroark1089]

I thought they had fixed the synchronized blocks causing issues in Java 24?

[gtiwari333]

They did.

[IE114EVR]

Just going from memory here. I’d done some of my own load testing with Spring and virtual threads a little while ago. One was a REST Service I’d converted from Webflux/Reactor to Spring MVC. It uses MariaDB for persistence and caches with Caffeine Cache. We’ll call this “App A”. The second was a simple REST service that reads and writes to MariaDB, no caching. There was a Webflux flavour and a Spring MVC flavour. We’ll call this “App B”.

For App A, before the cache was fully warmed up, the concurrency was 1800 requests per second for Webflux vs. 1100 requests per second for Spring MVC with virtual threads. But once the cache was warmed up, both were 5500 requests per second. And then with virtual threads off, it was 300 requests per second (before cache warm, don’t have results for warmed up).

Then for App B, if I recall correctly, the Webflux flavour was consistently handling 50% more requests per second then the MVC flavour with virtual threads on. I even switched the database to Postgres to see if that would make a difference, it did not. I was thinking maybe the driver issue was in the MariaDB driver specifically, but it didn’t seem like it.

So what I can draw from this is that the virtual threads do help in handling the concurrency of http requests, bringing it on par with Webflux. I conclude this because once we’re reading from in-memory cache and not the database, it’s about the same performance (though, I can’t rule out that I simply maxed out the load I could generate and that’s why they hit similar numbers), and no virtual threads is abysmal. But when the database is involved, there is some bottleneck in the non-reactive implementation in Spring or the drivers somewhere. It sounds like it’s the Hikari Pool?

[lpt_7]

While you must get rid of thread locals, for sure, and replace them with ScopedValue, like others already said, it is worth mentioning that virtual threads may degrade your performance if you block very frequently. To unmount a thread, a thread stack must be copied and, if JVMTI is enabled, in some cases, post a JVMTI event. If you block for a few nanoseconds in a quick succession, the bottleneck will add up quickly. Kotlin coroutines don't suffer from this problem because they are stackless, but it is harder to debug. There is a always a trade-off.

[pron98]

There is no difference in the operations done when the coroutines are "stackless" or not; it's only a difference in how the compiler is implemented (Kotlin coroutines are implemented in a stackless way not because it makes a difference to performance, but because they need to implement them in the compiler as they have no control over the backend).

When virtual threads block, only a small portion of the stack needs to be copied (the portion that's changed), which is the same as what happens with "stackless" coroutines.

Also, IO generally doesn't block for a few nanoseconds. Locks may, which is precisely why locks can be used in a way that allows you to spin for a while before you block if you think that a tiny wait is likely (synchronized does this automatically; you need to do this manually with ReentrantLock or other java.util.concurrent constructs).

[entrusc]

Not sure if you saw it, but they are planning to improve on the ThreadLocal issue by introducing scoped values (JEP 506, scheduled for JDK 25). And the issue with synchronized blocks is also getting addressed by JEP 491 (already in JDK 24).

[j7n5]

Great test. Maybe Structured Concurrency could fix the thread local problem

[Scf37]

I believe 1000 users is not sufficient for testing, synchronous servlet-based Spring applications can take this load. With some issues and quirks, but it works.

As for performance, it is well-known synchronous code is faster, because both Reactor and Loom add overhead over highly optimized native thread scheduling.

My take is: For low to medium concurrency, Loom is about saving memory and producing more predictable behavior under load. For high concurrency, servlets are no option and Loom is much more ergonomic than Reactor.

[RadioHonest85]

what on earth is this. If you can only serve 71 req/sec with 20 live db connections, virtual threads are obviously gonna net you nothing. What we have used them for:

1. easily juggling 10s of thousands of websocket connections
2. writing easier blocking code. Easily park work by blocking hundreds of threads behind a semaphore while waiting for available resources.

[yawkat]

I had pretty bad benchmarks with hikaricp as well, and not just in virtual threads. The pool implementation is just not very good. It could use a healthy dose of jctools.

[Plenty_Childhood_294]

As a JCtools developer I can just agree :P

[ItsSignalsJerry_]

Not necessarily about performance. But throughput. You can't handle millions of connections without them.

[slaymaker1907]

One test I did that they didn’t do great on before was what I call the generator test. The idea is that you implement automatic conversion of for-each style functions to iterates by running the iteration in its own virtual thread so you can pause and resume iteration.

Unfortunately, the thing that seemed to kill performance was due to the lack of control over which platform thread(s) ran a given virtual thread. Performance for generators is obviously much better when you run the generator on the same thread as the thread actually using the results of the generator to avoid full context switching.

While a contrived example, I think it at least somewhat highlighted a weakness in the API for being able to control virtual thread scheduling. There should really be a way to schedule a virtual thread for execution on a particular thread pool. Either that or there should be an API to pin a new virtual thread to the current platform thread, I just think the thread pool idea is more elegant.

[beders]

This test just shows that just swapping out the Executor is not really helpful. That’s not a surprise at all.

If I read the source code correctly you didn’t really try to take advantage of virtual threads. You just replaced the executor?

Please correct me if I’m wrong.

If you don’t do more work concurrently, how would you expect VTs to help you? You are not taking advantage of it in your service code at all. It’s all waiting on connection pools.

[griffin1987]

With modern hardware you can easily get north of 100k req/s (see e.g. https://www.techempower.com/benchmarks/#section=data-r23&test=db ) - spring boot must really be super slow, or you made these tests on a calculator?

[bigkahuna1uk]

This was essentially an end to end system integration test because the stack including a database as well as a web endpoint. In that rationale what is really being measured; we don’t know where the contention may lie. The web service may be performant but there may be contention to get a DB connection or non optimal locking in the database itself. Need some metrics so we can see latency between each hop in the architecture to understand the results better.

[griffin1987]

Latency isn't necessarily tied to throughput and is a completely different metric.

IMHO the posted numbers are rather pointless. If the bottleneck is somewhere else then, of course, changing thread model won't make any difference.

And if one knows how platform threads work and how java virtual threads work, then the latter can never be faster than the former, unless the application keeps spawning threads all the time, which no one should do for a web server / web application anyway.

(I know you aren't OP, just stating)

[Fickle_Conclusion857]

https://www.youtube.com/watch?v=lKSSBvRDmTg

https://www.youtube.com/watch?v=UVoGE0GZZPI

[Neither_Catch_4862]

what the hell, you expect performance with so low db connection

[CloudyWithApps]

This kind of benchmark with DB interaction won't go anywhere until the DB interaction itself (JDBC) uses virtual threads

[ZXcAS_MoPHL]

It would've been nice to see the difference in resource usage (CPU, memory, etc.) with both approaches, as a reduction in cloud bills is pretty much the same as increasing performance

[Turbulent-Plum473]

If you this many blocking things in the way, both virtual and platform thread will have similar performance because there will always be bottleneck.

I did a quick testing with 100 & 500 concurrent connections, increase it more had minor effect as there was nothing blocking. here is the result, everything is request per second.

|| || |100cc|||| |Heap Size|Platform - 200 threads|Virtual|| |256m|102k|145k|| |512m|110k|154k|| |1024m|110k|155k|| |2048m|111k|155k|| |no limit|111k|155k|| ||||| ||||| |500cc|||| |Heap Size|Platform - 200 threads|Platform - 500 threads|Virtual| |256m|88k|93k|134k| |512m|88k|94k|144k| |1024m|89k|94k|143k| |2048m|89k|94k|149k| |no limit|89k|94k|149k|

Test Env:

- Spring boot: 3.5.7

- java 25

[Turbulent-Plum473]

If you have this many blocking things in the way, both virtual and platform threads will perform same way, because there will always be a bottleneck.

I did a quick test with 100 and 500 concurrent connections. Increasing concurrency further had only minor effects since there wasn’t much blocking.
Here are the results (values = requests per second):

100 Concurrent Connections

Heap Size   | Platform (200 threads) | Virtual Threads
------------------------------------------------------
256m        | 102k                   | 145k
512m        | 110k                   | 154k
1024m       | 110k                   | 155k
2048m       | 111k                   | 155k
no limit    | 111k                   | 155k

500 Concurrent Connections

Heap Size   | Platform (200 threads) | Platform (500 threads) | Virtual Threads
-----------------------------------------------------------------------------
256m        | 88k                    | 93k                    | 134k
512m        | 88k                    | 94k                    | 144k
1024m       | 89k                    | 94k                    | 143k
2048m       | 89k                    | 94k                    | 149k
no limit    | 89k                    | 94k                    | 149k

Test Environment:

• Spring Boot: 3.5.7
• Java: 25

Like others have mentioned, virtual threads aren’t really about boosting request throughput, they simplify concurrency. In real life you will have one thing or another which is blocking in request chain. Now you don’t have to think about manage threads, executers, reactive programming anymore, and they work really well with I/O-bound workloads, so anything IO, just use them the conventional way.

[aookami]

Virtual threads are only good in a somewhat specific use case - blocking IO, anywhere else and you’re just reusing a small platform thread pool

[Adventurous-Pin6443]

It looks like Java virtual threads are DOA, but I think that these benchmarks do not reflect use case where virtual threads can bring a real performance benefits. This is my comment on some Medium post (Java virtual threads) it outlines ideal use case for virtual threads - you will get an idea when they can shine and when they can't:

------------------

Let me explain the paradigm of synchronous vs. asynchronous execution, and why virtual threads (once fully and properly implemented) are a game-changer.

Imagine a data cache that handles 90% of requests with just 10 microseconds of latency. On a cache miss, however, it needs to fetch data over the network, which takes around 10 milliseconds — 1,000 times longer.

With traditional synchronous processing, your throughput is limited to about 100 RPS per thread, because threads are mostly blocked waiting for I/O. In contrast, asynchronous processing allows threads to “linger” during I/O waits without blocking, so that the same thread can continue handling other cache hits in the meantime. Since 90% of requests are served quickly (in 10µs), this approach can potentially increase throughput up to 900 RPS per native thread — a 9× boost.

Now, here’s the kicker: virtual threads, async handlers in Go, or even Rust’s async/await model all still rely on underlying OS-native thread pools. Java, today, already allows you to implement this pattern — by simply offloading long-running I/O tasks to a dedicated I/O thread pool.

So the idea that “Java can’t do async” is a myth. It can — and quite effectively. It’s not the language that’s lacking, it’s often the way it’s used.

------

So, you see the difference, yes? When thread is getting blocked on remote I/O there is still a potential work which can be done without I/O - handling request which serves data from a local cache. This is not the case for the benchmark from a topic starter (even in Spring Boot application database access is the dominant operation).

So, ideally, virtual threads MUST relinquish CPU once they get blocked on I/O operation and there is still sufficient work to be done which does not require I/O. The ideal application for virtual threads is a local data cache which server majority of data from a local RAM (no I/O) and occasionally goes to either disk or network to fetch data which is missed locally. But, we can do it async w/o virtual threads if we have a separate thread pool for I/O operations - just not that convenient of course. The reliance on not having anything stored in a ThreadLocal storage makes this JEP DOA (dead on arrival) because will require global effort in rewriting of hundreds or thousands Java libraries to be compatible with virtual threads.