The solution isn't stated specifically, but either the underlying lock primitives need to be changed to address the synchronization block pinning of virtual threads in their selection of which lock requester wins, or the application developer needs to avoid obtaining a contentious lock within a synchronized block.

>the application developer needs to avoid obtaining a contentious lock within a synchronized block.

The promise of virtual threads was that you could use existing libraries and mostly have things "just work", so relying on the developer to know about the internal synchronization behavior of all transitive libraries used seems risky. Is the former something that is being worked on for jdk23 (the article only vaguely suggests that they will "hopefully addresses the integration between virtual threads and locking primitives.")

Yeah, currently you have to be really careful about what you do in virtual threads. However, they are actively working on a solution to the issue with synchronized blocks. Once that's been solved, they should be a lot easier to use. Unfortunately, many of us will be stuck on 21 for some time now, and will need to continue to worry about synchronized blocks.