Правильно ли обрабатывает escape-анализ Thread.holdsLock()?
Этот пример работает нормально (печатает true), когда я запускаю его с -XX:+DoEscapeAnalysis -server
:
final Object lock = new Object();
synchronized (lock) {
System.out.println(Thread.holdsLock(lock)); // prints true
}
С другой стороны, в краткой и не слишком подробной документации по улучшениям производительности виртуальной машины Java HotSpot ™ говорится следующее:
Компилятор сервера также устраняет блокировки для всех не глобально экранирующих объектов.
Таким образом, если escape-анализ устраняет ненужную синхронизацию, он должен напечатать false
,
Я думаю, что побег анализа ручки holdsLock
правильно (устраняет замки, не ломается holdsLock()
) но я хотел бы увидеть официальную ссылку или, возможно, соответствующие фрагменты исходного кода JVM.
1 ответ
Thread.holdsLock
является нативным методом в JDK и не является встроенным в JVM.
Это означает, что реализация Thread.holdsLock
черный ящик для компилятора JIT Так как этот метод принимает lock
в качестве аргумента, lock
больше не может рассматриваться как локальный неэкранируемый объект. JVM точно знает, что lock
действительно избегает, поэтому ни распределение, ни синхронизация не могут быть устранены в этом примере.
Но, как заметил @Holger, даже если holdsLock
была присущей JVM, она никогда не должна возвращаться false
иначе это будет нарушение спецификации. Никакая оптимизация JVM не может нарушить правильность программы.