More than that (as referenced above), `synchronized` currently pins a virtual thread to its carrier. So if you had 4 carrier threads, you only need to have 4 synchronized methods in flight that depend on the action of a 5th to hang the JVM.
Got it, so for now using `synchronized` actually prevents the concurrency benefits of virtual thread because it pins the carrier thread. Plus, there's also the possibility of deadlock when mixing `synchronized` and `j.c.u.Lock`.
Pretty much. You won't die if you run over some synchronized code (like ConcurrentHashMap) but you do have to think about what's happening when you hold that lock.
From the mailing list it sounds like the plan is to fix this, I hope that happens sooner rather than later.