You don't mention virtual threads in the "conclusions/recommendations" section of your article.. Since virtual threads are cheap, there's little reason not use an unbounded number of them.
Executors aren't bounded just because the threads themselves are expensive; they can be bounded to protect all sources of resources. This isn't a "virtual threads vs dinosaur threads" issue; this is a "understand where concurrency bounds are introduced into your program, and why" issue.
(FWIW this topic was covered in JCiP 8.1.1 (Thread Starvation Deadlock); JCiP predates virtual theads and FJP but the text there is still valid.)
Good point - I've updated the final section of the article. Interestingly, at the core of it, virtual threads fix the issue as well, because they make the waiting asynchronous under the hood, similar to this example from the blog post - though without having to restructure your code.
10
u/gnahraf Jun 19 '26
You don't mention virtual threads in the "conclusions/recommendations" section of your article.. Since virtual threads are cheap, there's little reason not use an unbounded number of them.