Существует ли связь между размером объекта и производительностью блокировки в Java? - PullRequest
6 голосов
/ 29 декабря 2011

В известном разделе «Параллелизм Java на практике», раздел 2.4, говорится, что подход с внутренней блокировкой, в отличие от явных блокировок, был плохим проектным решением, поскольку его сбивает с толку, а также «... он заставляет разработчиков JVM искать компромисс между размером объекта иблокировка производительности. "Может кто-нибудь объяснить, как размер объекта влияет на производительность блокировки?

Ответы [ 2 ]

5 голосов
/ 29 декабря 2011

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

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

Тогда есть все смещенные / не смещенные блокирующие элементы ... ну, вы можете начать читать об этом здесь . Документация Hotspot - это не то, что я бы назвал обширной, но блокировка и заголовки объектов представлены лучше, чем большинство остальных. Но в сомнении: прочитайте исходный код.

PS: У нас аналогичная проблема с собственным хеш-кодом каждого объекта. «Просто используйте адрес памяти» не очень хорошо, если ваш GC перемешивает объекты вокруг. (Но вопреки блокировке реальной альтернативы нет - если мы хотим эту функциональность)

2 голосов
/ 29 декабря 2011

Наиболее эффективные блокировки используют собственный размер слова, например 32-битные поля. Однако вы не хотите добавлять 4 байта к каждому объекту, поэтому вместо этого используется 1 бит AFAIK, однако установка этого бита более затратна, чем установка размера слова.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...