Is map.keySet().iterator() threadsafe?

[NikNik77771]

Is map.keySet().iterator() threadsafe?

[Ben Manes]

The iterator behaves the same as ConcurrentHashMap's iterator. From CHM's documentation:

"Similarly, Iterators and Enumerations return elements reflecting the state of the hash table

at some point at or since the creation of the iterator/enumeration. They do <em>not</em> 

throw {@link ConcurrentModificationException}. However, iterators are designed to be used 

by only one thread at a time."

You can safely iterate a map being concurrently operated on, but the iterator should not be shared between threads.

On Wednesday, March 28, 2012 1:21:31 PM UTC-7, NikNik77771 wrote:

Is map.keySet().iterator() threadsafe?

[NikNik77771]

Thank you Ben. I want to iterate ConcurrentLinkedHashMap keys and
share iterations between threads. Is it possible?

[Ben Manes]

Not without additional safety. A similar question was asked on Doug Lea's concurrency-interest mailing list, so it may offer some ideas. If you provide more information I'd be happy to offer a few ideas.

[NikNik77771]

My issue is very simple.

I want to treat key objects in map in parallel. During this procudure
map is immutable. Map is created in advance in parallel as well, so I
think that ConcurrentLinkedHashMap is best choise. It allows to create
map in paralle and iterate throw keys fast.

So, I create some threads that share map iterator.

On 29 мар, 01:22, Ben Manes <Ben.Ma...@gmail.com> wrote:
> Not without additional safety. A similar question<http://cs.oswego.edu/pipermail/concurrency-interest/2012-February/009...>was asked on Doug Lea's concurrency-interest mailing list, so it may offer

[Ben Manes]

If the map is treated as immutable, then you can take a snapshot copy of the keys. An easy way to do this is to use CopyOnWriteArrayList or Guava's ImmutableList. You could either give each thread a subList view or share an AtomicInteger for acquiring an index location if shared iteration.

Note that unlike LinkedHashMap, ConcurrentLinkedHashMap does not provide predictable iteration order. This is because its intended use-case is as a cache (an optional capability of LHM) and not ordered traversal (concurrency means ordering is non-deterministic). So if you aren't using CLHM as a cache, it may not be what you want. If you need an ordered hashmap you might choose between a ConcurrentHashMap + ConcurrentLinkedQueue or a synchronized LinkedHashMap.

[Nikolay Rychkov]

Thank you Ben very much.

But in case of snapshot copy ordinary Concurrent Map is better.

2012/3/29 Ben Manes <Ben....@gmail.com>: