Насколько тяжелы Java-мониторы?

Question

Скажем, у меня есть массив из тысяч объектов и небольшое количество потоков, которые могут получить доступ к каждому из объектов. Я хочу защитить доступ к одному из методов объектов. Самый простой способ - объявить этот метод как synchronized. Однако это может привести к созданию тысяч мониторов, в зависимости от того, как они реализованы. Если бы это был Win32, я бы никогда не создал тысячи объектов ядра, таких как Mutex, но CRITICAL_SECTIONs может быть правдоподобным. Мне интересно, что происходит в Java. Учитывая, что вероятность конфликта мала, будет ли использование мониторов накладывать больше, чем просто объем памяти, который им требуется? Насколько распространена практика использования такой синхронизации с низкой степенью детализации в Java?

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

Answer 1

Вы уже заплатили (большую часть и с низким уровнем конкуренции) штраф за использование мониторов с помощью Java ... нет смысла их не использовать.В частности, в случае низкой конкуренции они очень дешевы (см. пункты 2.1, 2.2, 2.3 здесь и пункт №1 здесь ), и JVM может полностью оптимизировать их дляколичество случаев.Если вы используете монитор объекта только временно, JVM сделает его «достаточно большим» (что означает, что он начинается с переворачивания битов, может расшириться для простых случаев конфликта до атомарного флага, выделенного стеком, и при постоянном конфликте иметь объектный монитор, выделенный дляэто; все они будут развернуты обратно в дело с низкими накладными расходами, поскольку спор уменьшится), и освободят место позже.Поскольку блокировка этих объектов является «правильной вещью» на стороне приложения, я бы сказал, пойти на это.

Тем не менее, здесь есть дизайнерский запах.Блокировка на многих объектах не звучит здорово.Кроме того, если у вас есть какие-либо условия последовательной блокировки, вы не сможете рассуждать о возможных тупиках.Я предлагаю вам дополнить свой вопрос более подробной информацией о приложении, и мы можем спросить, является ли блокировка большого пула объектов правильным решением.

Эта презентация Дейва Дайса дает некоторую полезностьпонимание того, как работает синхронизация Java6, и эта запись в блоге является сокровищницей информации о синхронизации по Java .Если вы действительно, действительно заботитесь о том, как «большой» полный на структуре objectmonitor есть (вступает в игру в утверждало случае), то код здесь .На внутренней странице HotSpot также есть некоторая хорошая углубленная информация .

Answer 2

Java-мьютексы достаточно дешевы, так что вы можете иметь сотни тысяч синхронизированных объектов и не замечать этого.

В неконтролируемом случае мьютекс Java состоит всего из 2 битов в слове флагов.JVM связывает только тяжелый объект блокировки ОС с мьютексом Java, когда мьютекс утверждается, и затем снимает блокировку ОС, когда мьютекс был завершен всеми потоками.

Обзор того, как мьютексы Java являютсяреализовано можно найти на слайдах с 9 по 23 этой презентации от Javaone 2006.

---

Обратите внимание, что реализация и производительность мьютексов могут зависеть от поставщика / выпуска Javaчто вы используете, и платформу, на которой вы работаете.

• В ранних выпусках Java мьютексы были значительно дороже.
• Вполне возможно, что были достигнуты успехи с момента публикации статьи о JavaOne 2006 ... независимо от того, опубликована она или нет.

Answer 3

Я думаю, что Collections.synchronizedCollection позволил одному потоку получить доступ к коллекции. Однако проблема создания мониторов существует.