I've been reading up on virtual threads, and it seems like they're a great option for handling blocking I/O tasks. But are there any hidden costs to using them? I'd love to know how they stack up against async/await models from other programming languages. Is there a downside to virtual threads that I should be aware of?
5 Answers
Performance can take a hit in certain situations, especially because you lack control over when and where your virtual threads execute. It’s crucial to know the trade-offs involved!
While virtual threads offer some advantages, they don't cover all the capabilities of reactive frameworks. Many use cases for reactive programming still apply here, which makes it a bit of a mixed bag.
Honestly, just move on from reactive frameworks! We adopted them because we had no async/await, and it felt like a prehistoric struggle with those webcontainer threads. Sure, reactive programming served its purpose, but let’s not forget the sanity we sacrificed in the process. Please, can someone just erase that horrific code from existence?
Virtual threads definitely make it easier to scale without diving into a completely different programming model. However, there are some downsides to consider:
1. If you're using ThreadLocals carelessly, it can lead to significant memory usage. Opt for ScopedValues instead.
2. Structured concurrency is still in preview mode, which can be a bit frustrating.
3. If you're deeply into reactive programming, switching over might require quite a bit of refactoring and testing.
4. Although the pinning issue with synchronized is addressed, there are still some edge cases like JNI calls that could cause trouble.
ThreadLocals can work just fine with virtual threads! The trouble starts when you're caching objects in them for sharing across multiple tasks. Virtual threads won't work with that model since they handle one task at a time, and sharing cached objects just becomes a waste. Stick to using ThreadLocal for task-specific info, or go for ScopedValue for a smoother experience.
Are the stack traces from virtual threads any good? That's been a concern for me.
I’m currently using Pekko at work, and I can say that Pekko streams and actors run smoothly with virtual threads. This combination makes for some pretty interesting possibilities!
What are some scenarios, apart from highly concurrent JNI calls, where virtual threads perform poorly?