Hacker News Reader

`synchronized` is a lock without any ordering/fairness guarantee. Therefore, with the increased concurrency caused by Virtual Threads, there's higher chances for starvation.

`ReentrantLock` pretty much replaces every use case of `synchronize` and also supports `fairness`. The only downside of `ReentrantLock` is making the code more verbose, and inexperienced programmers might forget to release the lock.

View on HN

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.

Reply on news.ycombinator.com