Является ли операция чтения в ConcurrentHashMap надежной относительно возвращаемого значения?

Question

Я читал в книге, которая читается в ConcurrentHashmap, не гарантирует последнее обновленное состояние, и иногда это может дать более близкое значение. Это верно?

Я прочитал его javadocs и многие блоги, которые, кажется, говорят иначе (то есть это точно).

Какое значение верно?

Answer 1

Это характер параллелизма. Любая параллельная коллекция может дать вам старое значение в поле, если текущая незавершенная операция записи не будет выполнена безопасно. Это во всех случаях то, что вы должны ожидать. Коллекции, сделанные для параллелизма, не будут давать вам поврежденные значения или сломаться, если вы получите доступ к ним из нескольких потоков, но они могут дать вам старые значения, если запись не выполняется.

Answer 2

От ConcurrentHashMap javadoc:

операции Retrieval (включая ГЭТ), как правило, не блокируют, поэтому могут перекрываться с операций обновления (в том числе на месте и удалить). Retrievals отражают результаты последних завершенных операций по обновлению с их началом. Для совокупных операций, таких как putAll и clear, одновременное извлечение может отражать вставку или удаление только некоторых записей. Аналогично, итераторы и перечисления возвращают элементы, отражающие состояние хеш-таблицы в какой-то момент времени или после создания итератора/перечисления. Они не выбрасывают ConcurrentModificationException. Однако итераторы предназначены для использования только по одному потоку за раз.

Один пункт, чтобы подчеркнуть это, что Iterator не будет отражать изменения, которые сделаны после того, как Iterator создается. Поэтому, если вам нужно перебирать значения карты, в то время как другие потоки добавляют к карте, и вы заботитесь о самом текущем состоянии карты, то использование ConcurrentHashMap может быть не реализацией нужной вам карты.

Answer 3

Интуитивно, ConcurrentHashMap должен вести себя как набор изменчивых переменных; Ключами карты являются переменные адреса. get(key) и put(key, value) должны вести себя как волатильное чтение и запись.

Это явно не указано в документе. Тем не менее, я твердо верю, что это так. В противном случае будет много неожиданных, удивительных поведений, которые подрывают логику приложения. Я не думаю, что Дуг Ли сделает это с нами. Конечно, кто-то спрашивает его в списке рассылки concurrency-interest.

Пусть он подчиняется летучими семантику, мы можем причине, основанной на Java модели памяти -

Все летучие чтения и записи образуют единый общий порядок. Это можно считать псевдо-временной строкой, где на нее читаются/записываются точки.

Неустойчивое чтение видит непосредственную предшествующую летучую запись и видит только запись. «Предшествующий» здесь соответствует псевдо-временной линии.

Псевдосрочная линия может отличаться от «реальной» линии времени. Однако, теоретически, волатильная запись не может быть бесконечно отложена на псевдо-временной линии. И, по праву, две линии времени довольно близки.

Поэтому мы можем быть уверены, что волатильная запись должна стать видимой «очень быстро» для чтения.