Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency

The biggest win by far IMHO is a performant alternative for io intensive applications for async frameworks. Not using an async framework tremendously simplifies your code. Code complexity has an enormous projection on everything else, especially when talking on the business level. First and foremost the cost of development and time to market rises. And then comes the cost of maintenance.

While this is definitely a good new, we need to be very careful. Why? Those new fancy threads are stored on heap and need to be garbage collected. If you buy into ads and believe that you can create for free millions of threads, then, well, it is not gonna work on production.<p>Because of this server based on new threads does not need to be more performant, Jetty server guys tested this and they were not that happy: <a href="https:&#x2F;&#x2F;webtide.com&#x2F;do-looms-claims-stack-up-part-1&#x2F;" rel="nofollow">https:&#x2F;&#x2F;webtide.com&#x2F;do-looms-claims-stack-up-part-1&#x2F;</a><p>Before getting too excited I advise to watch Tomasz Nurkiewicz lecture on the subject - <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=n_XRUljffu0">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=n_XRUljffu0</a>, it explains what are the trade-offs here.<p>No silver bullet, again.

Are these green threads?<p>-- edit myself: no, it can&#x27;t be. JVM had green threads since eons ago, according to wikipedia.<p>-- edit again: this SO thread --pun intended!-- explains it<p><a href="https:&#x2F;&#x2F;stackoverflow.com&#x2F;questions&#x2F;74639116&#x2F;what-is-the-difference-between-green-threads-and-virtual-threads" rel="nofollow">https:&#x2F;&#x2F;stackoverflow.com&#x2F;questions&#x2F;74639116&#x2F;what-is-the-dif...</a>

I really hope this is the end of complicated reactive frameworks! I love the old blocking spring controller paradigm, thread local and so on. It makes things much easier. Never liked webflux, so complicated and hard to debug. Simple things become a project!<p>Virtual threads to the rescue!

NIO solved the problems with threads on the network in Java 1.5 (seminal cornerstone API that also had the concurrency package and rewrote the entire JVM memory model), but only in 1.7 the epoll solution became stable.<p>2004 -&gt; 2011, 7 years!<p>Now they hopefully can work around the kernel for file descriptors (network and disk) saving 30% CPU globally on all Java servers.<p>Many nuclear power plants wasted on the kernel.

&gt; Virtual threads offer a more efficient alternative to platform threads, allowing developers to handle a large number of tasks with significantly lower overhead.<p>they should have just called them &quot;Tasks&quot; leaving the already overloaded term &quot;virtual&quot; out of the conversation.

So with this, the last thing Go had going for it over Java is gone, right?<p>Java has an obviously better type system, while Java originated the billion dollar mistake, Java also at this point has much better practices around handling nulls than Go, Java&#x27;s jars are more portable than go&#x27;s binaries, Java&#x27;s GC performs better, Java has a more mature ecosystem and more libraries... Java has better IDE support and comparable compile times.<p>I guess at this point the only major difference is that you can teach a 3 year old to write Go more easily, so ChatGPT produces correct Go more easily than Java, and the dependency management story differs a little (though I don&#x27;t think you can really call a winner or loser on that one, it&#x27;s just different)

The top comment in this thread [1] highlights (potential) problems with virtual threads, referring to this PDF [2]. Does anyone know if these actually manifest in the way they are implemented?<p>[1] <a href="https:&#x2F;&#x2F;www.reddit.com&#x2F;r&#x2F;rust&#x2F;comments&#x2F;xrrjec&#x2F;virtual_threads_in_rust&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.reddit.com&#x2F;r&#x2F;rust&#x2F;comments&#x2F;xrrjec&#x2F;virtual_thread...</a><p>[2] <a href="https:&#x2F;&#x2F;www.open-std.org&#x2F;JTC1&#x2F;SC22&#x2F;WG21&#x2F;docs&#x2F;papers&#x2F;2018&#x2F;p1364r0.pdf" rel="nofollow">https:&#x2F;&#x2F;www.open-std.org&#x2F;JTC1&#x2F;SC22&#x2F;WG21&#x2F;docs&#x2F;papers&#x2F;2018&#x2F;p13...</a>

I haven&#x27;t touched Java since school and never worked in it professionally and that&#x27;s been well over a decade. Is there a resource that people recommend that gives a good introduction to modern Java? Preferably succinct but doesn&#x27;t need to be.

If you need a video explanation of virtual threads this might help: <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=4mf24mzm0ks">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=4mf24mzm0ks</a>

Next stop, tail calls plz.

Using virtual threads only, can one make a non-blocking UI application? Or do you still need to fall back to Promises or callbacks?

Is this the equivalent for the .NET TPL (task parallel library), which exists for over a decade now?

What are these things? It sounds like it is a time-sliced sharing that offers only concurrency and not parallelism. In other words, it&#x27;s a userland construct and not a kernel thread. Sounds more like GO coroutines but do we really need another name for them?

&gt; However, due to the large number of virtual threads that can be created, developers should use thread-local variables with caution.<p>What is the problem here? Just the per-virtual-thread memory consumption by the variable when it is used (which would be expected)?

Are we dropping the &quot;in&quot; from &quot;to usher in&quot; now?<p>Or is this just an incorrect headline?

How are Java virtual threads compared to C# tasks? To me, they seem very similar.

`Executors.newVirtualThreadPerTaskExecutor()`.<p>Java verbosity is alive and well.

The issue I see is some companies&#x27; reluctance to even shift from Java 8 or move away from legacy.<p>I guess that will be the biggest impediment to adoption of new features.

How is a system of virtual threads different from typical &quot;a pool of tasks and a pool of threads to perform them on&quot; systems like e.g. the .NET TPL?

Well it&#x27;s not really ushering it in, given that this is what Haskell has had for a decade at least.

Anyone familiar with Java and Kotlin, please expand on how close is Java in feature parity with Kotlin?

It seems that everyone is learning from Erlang and the BEAM!

What will this mean for Kotlin and concurrency I wonder

Are these like javascript promises or goroutines?

hopefully this will mean the end of Reactor Core and all that craziness

New Era of concurrency? It began in arguably better languages a decade ago.

Every time something show up about anything related to Java, the discussions turn to this flame war about what language are better or worse than Java. Why can’t we just discuss the article at hand?<p>In this case, I’d love to hear more from experienced Java developers, with existing code-bases, who have tested these new virtual threads out.

&gt; Platform threads are a one-to-one wrapper over operating system threads, while virtual threads are lightweight implementations provided by the JDK that can run many virtual threads on the same OS thread. Virtual threads offer a more efficient alternative to platform threads, allowing developers to handle a large number of tasks with significantly lower overhead.<p>&gt; The JDK can now run up to 10,000 concurrent virtual threads on a small number of operating system (OS) threads, as little as one<p>OK, but why bother with virtual threads if the JVM could just magically decide to run all my virtual threads on one thread? I guess &quot;efficient&quot; in this context doesn&#x27;t mean &quot;fast&quot;. I want my code to run on all available cores, and not be hobbled by a JVM that decided to hate me today.