Pinning — виртуальный поток при блокировке не может отцепиться от несущего, и тот простаивает. До JDK 24 главная причина — блокировка внутри synchronized; JEP 491 (JDK 24) это убрал. Остаются нативные кадры (JNI, вызовы через Foreign API) в стеке.
А ещё Короткий synchronized без блокировок — не проблема
Так подсказку видит пользователь sotto на живом собеседовании — за пару секунд, пока вы думаете вслух.
Обычно виртуальный поток при блокировке отцепляется от несущего платформенного, освобождая его для других задач. Pinning — ситуация, когда отцепиться нельзя, и платформенный поток простаивает вместе с виртуальным; при малом пуле несущих потоков это способно застопорить приложение. Исторически главной причиной был synchronized, из-за чего рекомендовали заменять его на ReentrantLock. JEP 491 в JDK 24 это исправил: владение монитором теперь отслеживается по виртуальному потоку. Остались нативные методы и Foreign Function & Memory API. Знание того, что рекомендация про ReentrantLock устарела, хорошо отличает актуальные знания от прочитанных пару лет назад.
Один верный вариант. Подумайте, потом откройте ответ.
Лёгкие потоки JVM, монтирование на carrier, когда их применять, почему не пулят и проблема pinning.
sotto слышит вопрос интервьюера и показывает короткий ответ и план, как в блоке «Коротко». Оставьте контакт — пришлём доступ и промокод.
sotto