Это хорошая практика, чтобы обернуть операции чтения и записи ConcurrentHashMap с ReentrantLock?

Question

Я думаю, что в реализации ConcurrentHashMap ReentrantLock уже использовался.Поэтому нет необходимости использовать ReentrantLock для доступа к объекту ConcurrentHashMap.И это только добавит больше накладных расходов на синхронизацию.Есть комментарии?

Answer 1

Чего бы вы (или кто-либо другой) хотели достичь с этим?ConcurrentHashMap уже поточно-ориентирован как есть.Обертывание его дополнительным кодом блокировки просто значительно замедлит его, поскольку

1. не блокирует чтение как таковое,
2. даже для записи, вы вряд ли сможете имитировать его внутреннюю блокировку блокировкивнешнее поведение.

Другими словами, добавление дополнительной блокировки значительно увеличит вероятность конфликта потоков (а также сделает более строгими гарантии безопасности операций чтения для записи).

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

Из обобщений и коллекций Java,глава 16.4.

Answer 2

Весь смысл ConcurrentHashMap не в том, чтобы ограничивать доступ / изменения к нему.Дополнительная блокировка только добавляет накладные расходы.