Do virtual threads change how you use synchronized in library code?

On JDK 21 through 23, blocking inside synchronized pins the carrier thread. A library that wraps its I/O in a monitor (plenty of older JDBC drivers and HTTP clients did) will pin every virtual thread that calls it, and the application's throughput collapses in a way that points at the wrong place.

The guidance for that era: audit your own blocking paths, replace monitors around them with ReentrantLock, and check dependencies with -Djdk.tracePinnedThreads=full, a flag JDK 24 removed along with the problem.

JDK 24's JEP 491 made monitors unmount properly, which retires most of this. Give both halves in an interview: the mechanism, and the version where it stopped mattering, because the answer depends entirely on which JVM the team is on.