Virtual threads finally exited their development and preview phases and with JVM 21 are available as a stable and supported Java feature. During the latest Devoxx edition I started exploring the characteristics of virtual threads and their performance implications putting them at work, with a funny but practical example, using a Conway's Game of Life implementation based on Project Loom. Starting from the same playground this time we will explore more in depth the internal implementation details of virtual threads, trying to answer to some interesting questions. What does it mean in practice that virtual threads aren't preemptive? Are scoped values enough to replace ThreadLocals in all possible scenarios? What does it happen if you try to replace the fork/join pool, used as default carrier thread pool, with something different? At the end we will conclude this exploration trying to experience the multithreaded programming equivalent of the sound of one hand clapping or how virtual threads make it possible to cause a deadlock using one single lock.
Mario Fusco
Red Hat
Mario is a senior principal software engineer at Red Hat working as Drools project lead. Among his interests there are also functional programming and Domain Specific Languages. He is also a Java Champion, the JUG Milano coordinator, a frequent speaker and the co-author of "Modern Java in Action" published by Manning.