Предвзятая блокировка в Java

Question

Я продолжаю читать о том, как смещенная блокировка, используя флаг -XX:+UseBiasedLocking, может улучшить производительность незапланированной синхронизации. Я не смог найти ссылку на то, что он делает и как он улучшает производительность.

Может кто-нибудь объяснить мне, что именно, или может быть, указывают мне на некоторые ссылки / ресурсы, которые объясняют??

Answer 1

По сути, если ваши объекты заблокированы только одним потоком, виртуальная машина может выполнить оптимизацию и "сместить" этот объект к этому потоку таким образом, чтобы последующие элементарные операции над объектом не требовали затрат на синхронизацию. Я предполагаю, что это, как правило, направлено на чрезмерно консервативный код, который выполняет блокировки объектов, не подвергая их воздействию другого потока. Фактические накладные расходы на синхронизацию включатся только тогда, когда другой поток попытается получить блокировку объекта.

Он включен по умолчанию в Java 6.

-XX: + UseBiasedLocking Включает технику для повышения производительности незапланированной синхронизации. Объект "смещен" к потоку, который сначала получает свой монитор через байт-код монитора или синхронизированный вызов метода; последующие операции, связанные с монитором, выполняемые этим потоком, на многопроцессорных машинах относительно быстрее. Некоторые приложения со значительными объемами неконтролируемой синхронизации могут достигать значительных ускорений с включенным этим флагом; в некоторых приложениях с определенными схемами блокировки могут наблюдаться замедления, хотя были предприняты попытки минимизировать негативное влияние.

Answer 2

Разве это не отвечает на ваши вопросы?

http://www.oracle.com/technetwork/java/tuning-139912.html

Включает технику для повышения производительности несанкционированной синхронизации. Объект "смещен" к потоку, который сначала получает свой монитор через байт-код монитора или синхронизированный вызов метода; последующие операции, связанные с монитором, выполняемые этим потоком, на многопроцессорных машинах относительно быстрее. Некоторые приложения со значительными объемами неконтролируемой синхронизации могут достигать значительных ускорений с включенным этим флагом; в некоторых приложениях с определенными схемами блокировки могут наблюдаться замедления, хотя были предприняты попытки минимизировать негативное влияние.

Хотя я думаю, что вы найдете его по умолчанию в 1.6. Используйте диагностическую опцию PrintFlagsFinal, чтобы увидеть эффективные флаги. Убедитесь, что вы указали -server, если исследуете серверное приложение, поскольку флаги могут отличаться:

http://www.jroller.com/ethdsy/entry/print_all_jvm_flags

Answer 3

Я сам задавался вопросом о предвзятых замках.

Однако кажется, что смещенные блокировки java медленнее на процессорах nehalem компании Intel, чем обычные блокировки, и предположительно на двух поколениях процессоров начиная с nehalem. См. http://mechanical-sympathy.blogspot.com/2011/11/java-lock-implementations.html и здесь http://www.azulsystems.com/blog/cliff/2011-11-16-a-short-conversation-on-biased-locking

Также больше информации здесь https://blogs.oracle.com/dave/entry/biased_locking_in_hotspot

Я надеялся, что есть какой-то относительно дешевый способ отозвать предвзятую блокировку для intel, но я начинаю верить, что это невозможно. Статьи, которые я видел о том, как это делается, основаны либо на: 1) использовании os для остановки потока 2) отправке сигнала, т. Е. Запуске кода в другом потоке 3) наличии безопасных точек, которые гарантированно выполняются довольно часто в другой поток и ожидающий его выполнения (именно это делает Java). 4) наличие подобных безопасных точек, которые являются вызовом возврата - и другой поток изменяет код до точки останова...

Answer 4

Стоит отметить, что предвзятая блокировка будет отключена по умолчанию начиная с jdk15.

JEP 374: отключить и отказаться от предвзятой блокировки

Прирост производительности, наблюдаемый в прошлом, сегодня гораздо менее заметен. Многие приложения, которые выиграли от предвзятой блокировки, являются старыми, унаследованными приложениями, которые используют API ранней коллекции Java, которые синхронизируются при каждом доступе (например, Hashtable и Vector). Новые приложения обычно используют несинхронизированные коллекции (например, HashMap и ArrayList), представленные в Java 1.2 для однопоточных сценариев, или даже более производительные параллельные структуры данных, представленные в Java 5, для многопоточных сценариев.

Дальше

Предвзятая блокировка вводит много сложного кода в подсистему синхронизации, а также влияет на другие компоненты HotSpot. Эта сложность является барьером для понимания различных частей кода и препятствием для внесения существенных изменений в конструкцию подсистемы синхронизации. С этой целью мы хотели бы отключить, объявить устаревшей и, в конечном итоге, удалить поддержку предвзятой блокировки.

И я, не более System.identityHashCode(o)магия ;)

Answer 5

Две статьи здесь:

https://cdn.app.compendium.com/uploads/user/e7c690e8-6ff9-102a-ac6d-e4aebca50425/f4a5b21d-66fa-4885-92bf-c4e81c06d916/File/ccd39237cd4dc109d91786762fba41f0/qrl_oplocks_biasedlocking.pdf

https://www.oracle.com/technetwork/java/biasedlocking-oopsla2006-wp-149958.pdf

веб-страница тоже:https://blogs.oracle.com/dave/biased-locking-in-hotspot

Исходный код точки доступа jvm:

http://hg.openjdk.java.net/jdk8/jdk8/hotspot/file/87ee5ee27509/src/share/vm/oops/markOop.hpp