> > However, the observation I wanted to share here is that my first prototype > used Executors.newVirtualThreadPerTaskExecutor() instead, but that caused a > deadlock. > > Is this difference in behavior expected? Is my preloading technique sound? > > Here's a thread dump of the deadlock situation using virtual threads: >
To be completely correct, my initial prototype used Thread.ofVirtual instead of Executors.newVirtualThreadPerTaskExecutor. But the situation is the same, virtual threads get stuck while preloading classes. I find it intriguing that none of the "- locked" or "- waiting to lock" lines in the thread dump seem to refer to the same lock, hence the same class being loaded by different threads. Am I right that for a genuine deadlock we should see one thread waiting for a lock held by another thread? Or is serviceability not showing the full picture here for virtual threads? (Thread dump acquired using jstack) Eirik.
