How do Java 21 virtual threads will compare to Kotlin coroutines?
When coding in Kotlin, is it better to prefer one over the other?
This video: Java 21 new feature: Virtual Threads #RoadTo21 seems to frown upon using virtual threads for non-IO or non-blocking tasks.
I create coroutines right and left even for CPU-intensive tasks in my Kotlin code. Is this not alright anymore?
Is this not alright anymore? It is alright, Java virtual threads won't replace Kotlin coroutines.
There is a presentation by Roman Elizarov that covers the difference.
Short Recap from presentation
Virtual Threads (Project Loom) are good for
Kotlin Coroutines are good for
And, as mentioned by @Slaw in the comment, coroutines can be executed on virtual threads too. Also coroutines can be used with Kotlin/JS and Kotlin/Native.
It is slightly like comparing apples to oranges since the goals are different. Maybe more like comparing peaches to nectarines, because there's a little bit of overlap.
Virtual threads solve the problem of blocking IO tasks taking up an OS thread for their duration. Basically, they reduce the resources necessary to do blocking, synchronous tasks at scale.
Coroutines solve the problems of:
Point 1 is eventually coming to Java as well. You can read about it in JEP 453. I haven't studied it in detail, but I kind of assume that in Kotlin, coroutines will still be the preferred way to write concurrent code, because of point 2 and because it can be used in Kotlin multiplatform.
But basically, as it stands, we are comparing things that solve two different problems. But there's no reason you can't use both:
val virtualThreadDispatcher = ExecutorService.newVirtualThreadPerTaskExecutor()
.asCoroutineDispatcher()
suspend fun foo() = withContext(virtualThreadDispatcher) {
someBlockingIOCode()
}
Now you have a dispatcher that doesn't have to allocate whole platform threads to run blocking IO code, but at the expense of virtual threads' more expensive task switching. This is kind of a tricky tradeoff to have to think about and balance, but the Kotlin designers' plan is to update Dispatchers.IO to take the best of both worlds once the Java API advances to the point to allow enough customization to achieve it.
CompletableFuture, Flow, etc, where you have to chain callbacks which may chain more callbacks, etc, which is hard to read and horribly to debug. With virtual threads, you don’t have to avoid blocking calls, hence, can write an ordinary sequence of statements with ordinary control flow, using blocking waits when necessary. An example has been given already, the I/O background thread can simply wait for the UI thread’s response and proceed, instead of switch back and forth with callbacks. –
Korfonta From this video, we can say that Loom is great. But it's not a replacement for kotlin coroutines. Coroutines are still the recommended thing to use when dealing with concurrent processes in Kotlin. To compare them,
To wrap up, we can say that the best thing Loom has to propose is the virtual threads which can inprove performance, while Kotlin coroutines has more to offer. Why not using both of the features together?
Well, there is a concept introduced by Moskala in his "Kotlin Coroutines: Deep dive" book which is interesting. We can use Loom directly in Kotlin coroutines code and have a better performance while keeping structured concurrency and all the cool stuff we get in coroutines. To do that, we use virtual threads to replace Dispatchers.IO. Below is an example of code that uses virtual thread.
val LoomDispatcher = Executors
.newVirtualThreadPerTaskExecutor()
.asCoroutineDispatcher()
val Dispatchers.Loom: CoroutineDispatcher
get() = LoomDispatcher
suspend fun main() = measureTimeMillis {
coroutineScope {
repeat(100_000) {
launch(Dispatchers.Loom) {
Thread.sleep(1000)
}
}
}
}.let(::println)
Because Dispatchers.IO has just 64 threads, the code above will take over 26 minutes, but we can make use of limitedParallelism to increase the number of thread and get the chance to execute the code fastly. The code using Dispatchers.IO is as follow:
suspend fun main() = measureTimeMillis {
val dispatcher = Dispatchers.IO
.limitedParallelism(100_000)
coroutineScope {
repeat(100_000) {
launch(dispatcher) {
Thread.sleep(1000)
}
}
}
}.let(::println)
I didn't personnally run the code with virtual threads but it's said in the book that it took a bit more than two seconds to execute (This is amzing knowing that we block each of the 100 000 threads for 1 second), but the second code took around 30s to finish executing.
I would say the best way to make the code performant and use some cool stuff that coroutines offer, we can use Loom as a substutition for Dispatchers.IO but keep using coroutines, though there is no any kind of recommendations in the documentations.
© 2022 - 2025 — McMap. All rights reserved.
Dispatchers.IOuse virtual threads whileDispatchers.Defaultuses platform threads. – Gluttony