ConcurrentHashMap возвращает слабо непротиворечивый итератор, зачем нам вообще его использовать?

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

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

ConcurrentHashMap по контракту должен быть потокобезопасным. Однако он не должен быть согласованным между потоками.

Когда вы перебираете ConcurrentHashMap, итератор получает копию хеш-карты в тот момент, когда вы ее запросили (и эта копия создается потокобезопасным способом), и вы перебираете эту копию. И да, ничто не гарантирует вам, что пока вы перебираете эту копию, некоторые элементы карты не будут удалены. Но записи карты, которые будут удалены таким образом, все равно будут существовать в вашем итераторе.

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

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

Таким образом, если все, что вам нужно, это карта, совместно используемая потоками ConcurrentHashMap (скажем, место в театре для человека, бронирующего его), предоставит то, что вам нужно, и это может быть намного быстрее, если у вас много рабочих потоков, поскольку вы избегаете синхронизации мьютексов. С другой стороны, за скорость приходится платить - представление, предоставляемое итератором, не обязательно соответствует состоянию коллекции при его создании, и оно может пропустить некоторые элементы, созданные после слов (в общем, в многопроцессорных системах отношения happens-before сложны).

Правка. Как заметил принц Джон Уэсли, я думал о ConcurrentSkipListMap, когда видел и писал. ConcurrentHashMap. Большинство пунктов остаются в силе, за исключением частей, касающихся отсутствия блокировок (а также всего, что из этого следует, например, гарантированная пропускная способность и т. д.).