Является ли итератором KeySet ConcurrentHashMap потокобезопасным?

Question

Я просто пытаюсь исследовать Что такое ThreadSafe?

Ниже мое понимание:

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

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

Если мое заявление выше false; просто прочитать ниже JAVA DOC для `ConcurrentHashMap:

Keyset: итератор мнение, является«слабо согласуется»итератор, который никогда не бросит ConcurrentModificationException и гарантии для обхода элементов, как они существовали на строительство итератора, и может (но не гарантируется) отражать любые изменения после строительства.

В приведенном выше заявлении говорится, что итератор keySet не гарантирует целостность данных; в то время как многопоточность изменяет коллекцию.

Не могли бы вы ответить на меня, * Является ли итератором KeySet ConcurrentHashMap потоковым?

И мое понимание по потоку безопасно правильно?

Answer 1

Keyset: итератор мнение, является «слабо согласуется» итератор, который никогда не бросит ConcurrentModificationException, и гарантирует перемещение элементов, как они существовали на строительство итератора, и может (но не гарантируется) отражать любые изменения после строительства

Это само объясняет, что Иконтер KeySet ConcurrentHashMap является потокобезопасным.

Answer 2

Общая идея пакета java.util.concurrent представляет собой набор структур данных, обеспечивающих поточно-безопасный доступ без сильной согласованности. Таким образом, эти объекты обеспечивают более высокий уровень параллелизма, чем правильно заблокированные объекты.

Быть потокобезопасным означает, что даже без какой-либо явной синхронизации вы никогда не повреждаете объекты. В HashTable и HashMap некоторые методы представляют собой потенциальные проблемы для многопоточного доступа, такие как метод remove, который сначала проверяет, существует ли элемент, а затем удаляет его. Эти методы реализуются как атомарные операции в ConcurrentHashMap, поэтому вам не нужно бояться, что вы потеряете некоторые данные.

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

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

Это отличное от надежного потока. Несмотря на то, что результаты могут вас удивить, вы уверены, что ничто не потеряно или случайно не перезаписано, элементы добавляются и удаляются с вашего объекта без каких-либо проблем. Если этого достаточно для ваших требований, вам рекомендуется использовать классы java.util.concurrent. Если вам нужна более согласованность, вам нужно использовать синхронизированные классы от java.util или использовать синхронизацию самостоятельно.

Answer 3

По вашему определению Set, возвращенный ConcurrentHashMap.keySet()is thread safe.

Однако он может действовать очень странно, как указано в приведенной цитате.

1. В Set, записи может появляться и/или исчезает в случайном порядке. То есть если вы назовете contains дважды на том же объекте, два результата могут отличаться.
2. В качестве Iterable вы можете начать две итерации своих базовых объектов в двух разных потоках и обнаружить, что две итерации перечисляют разные записи.
3. Дальше, contains и итерация может не совпадать.

Эта деятельность не будет происходить, однако, если вы каким-то образом зафиксировать, лежащий в основе Map от модификации в то время как у вас есть захват вашего Set, но необходимость делать это вовсе не означает, что структура не поточно.