Virtual Threads and Structured Concurrency in Java 21 With Loom
HTML-код
- Опубликовано: 5 фев 2025
- Loom brought 2 preview features in Java 19: virtual threads and structured concurrency. Virtual threads are a new model of thread that is compatible with the current platform threads but much lighter. You can easily launch millions of virtual threads on a machine that would only support a few thousand platform threads. Virtual threads should be made final in JDK 21. Structured concurrency leverages this feature to write asynchronous code in a very easy way. It is built on an imperative mono-thread programming model built on top of virtual threads. These elements have been updated in Java 20. Java 20 also has a third preview feature delivered by the Loom project: a new model for ThreadLocal variables called ScopedValues that is meant to work with virtual threads. This presentation shows you how this all works, the new pattern you will be able to use for your asynchronous systems, and the performance you may expect.
Speaker: José Paumard
Join us:
Website: jb.gg/website
Blog: jb.gg/blog
Twitter: / intellijidea
Facebook: / intellijidea
Download IntelliJ IDEA: jb.gg/download...
Top 15 IntelliJ IDEA shortcuts: jb.gg/Top15Int...
#concurrency #virtualthreads #concurrentprogramming
I am a simple Java developer, whenever I see a video with Jose, I like it. 1:14:41
Thanks!
he's the European Venkat :)
Whenever I see his simple, sincere face, I immediately feel the urge to code something concurrent.
This guy is awesome. I like the way he easily explains difficult concepts. @Jose is s a Lengend!
This was a great format! I wish I had watch it live.
good detailed presentation, thanks. internals, guts of the things are especially interesting
Nice. Thx for the video and your contribution to the community
Great video! 🎉
Truly professor explanation😊
Amazing session!
This reminds me of generator functions in Python; great explanation
Awesome feature!
Awesome LTS version
Hi @IntelliJ IDEA, a JetBrains IDE, I want to understand the following -
1. How is it ensured that all the blocking operations invoked by any arbitrary code (excluding native method calls and synchronized blocks) from a virtual thread are managed by the Continuation framework? Have all the potential blocking points in the JDK been identified and adapted to support this?
2. Consider a third-party library that is confirmed not to use native methods or synchronized blocks. While calling it from a virtual thread, is it still necessary to manually verify that it will not accidentally block the underlying platform thread?
Thanks.
at time 20:23, the when the lambda is running the suuplyAsync(), some thread from the pool will be blocked right? I don't think the thread that launches this lambda will be freed up to do other tasks before the lambda returns. Hence this will still not be able to launch a million requests. In other word, this is still a 1 blocking request per thread pattern
WeatherReader::getBodyFrom is blocking call, so a completable future will block.
httpClient.sendAsync must be used with .thenComposeAsync (or .thenCompose)
Kinda a huge mistake in async programming
An it's at 18:19
Révolution!!!!
CompletableFeature in that case just transfer bloking problem from main thread to tread's pool thread. and really getting situation even worse since you have limited theads in pool and it preventing you to schedule to another thread to make something usefule you like forcing your CPU do deal with "waiting" tasks
One more question, if possible. How will virtual thread deal with happens before guarantee? Since context switching will be so much faster, will the compiler need to rearrange code, creating visibility issues?
Can anyone point me to a HttpClient library that supports virtual threads? Does spring's webclient / apache HttpComponents support them?
@Mala you wanted to attach his GitHub link btw
This is in many ways inferior to coroutines in kotlin
but still a huge step for java, nice job.
What are the "many ways"? List them please.
No
It is so cringing when I hear Kotlin trying to sell it does something than Java when the entire life cycle of Kotlin is running on JVM. Kotlin is only useful for code simplicity like Lamda not in anyway performant than Java.
@@encapsulatio 1. Coroutines let you clearly define what's suspending or not, not some magic blocking functions by JDK that are special.
2. Coroutines have context which allows you to carry around a lot of useful information.
3. Coroutine jobs and cancellation mechanics that cascade to other subroutines.
with that said from some basic tests loom is actually faster than coroutines
@@GafarOlanipekun Kotlin does not just run on JVM... and why that even matters, kotlin is simply a better language that forced java team to actually care about their language. They keep releasing features that we had like 10 years ago, with a lag. What stopped them from doing these things before? if they did there would be no need for kotlin