CODEWITHSUNDEEP
javacollectionsdictionaryconcurrency
VB_
VB_

Reputation: 45702

One concurrent collection inside another: is it thread safe

[Question]: Is it thread safe to use ConcurrentHashMap<Object, ConcurrentHashMap<Object, Object>> or not.

[Optional to answer]: Also what about another concurrent maps types? And what about concurrent collections?

P.S. I'm asking only about java.util.concurrent package.

Specific Usage Context:

//we have
ConcurrentHashMap<Object, ConcurrentHashMap<Object, Object>> map = new ConcurrentHashMap<Object, ConcurrentHashMap<Object, Object>>();
//each string can be executed separately and concurently
ConcurrentHashMap<Object, Object> subMap = new ConcurrentHashMap<Object, Object>()
map.put(key, subMap);
map.remove(key);
map.get(key);
map.get(key).put(key, ref);
map.get(key).remove(key);

Maybe my solution lays around Guava HashBasedTable?

Upvotes: 0

Views: 1415

Answers (5)

Marko Topolnik
Marko Topolnik

Reputation: 200196

You can't define thread safety without the specific context in which you plan to use your collections.

The concurrent collections you have named are thread-safe on their own in the sense that their internal invariants will not be broken by concurrent access; however that's just one bullet point on the thread safety checklist.

If you perform anything more than a single operation on your structure, which must be atomic as a whole, then you will not get thread safety just by using these classes. You will have to resort to classic locking, or some quite elaborate, and usually unmotivated, lock-free updating scheme.

Using the examples from your question, consider the following.

Thread 1 executes

map.get(mapKey).put(key, value);

At the same time, Thread 2 executes

map.remove(mapKey);

What is the outcome? Thread 1 may be putting something to a map which has already been removed, or it may even get a null result from get. In most cases more coordination will be needed for correctness.

Upvotes: 4

Brett Okken
Brett Okken

Reputation: 6306

In general the classes which are part of java.util.concurrent provide additional performance at the (potential) penalty of additional coding complexity.

The issue that I see with nesting ConcurrentMap instances is managing the populating the outer map with values at given keys. If all the keys are known upfront and values placed in the map in some sort of initialization phase, there are no issues (but you also likely would not need to have the outer map be a ConcurrentMap). If you need to be able to insert new maps into the outer map as you go, the work becomes a bit more complicated. When creating a new map to insert into the outer map, you would need to use the putIfAbsentmethod[1] and pay attention to the returned value to determine what instance to add data to.

[1] - http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/ConcurrentMap.html#putIfAbsent(K,%20V)

Upvotes: 1

injecteer
injecteer

Reputation: 20699

this is what the javadoc of ConcurrentHashMap says:

However, even though all operations are thread-safe, retrieval operations do not entail locking, and there is not any support for locking the entire table in a way that prevents all access

So, they ARE thread-safe in terms of modifying it.

UPDATE

same javadoc http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/ConcurrentHashMap.html says:

Retrieval operations (including get) generally do not block, so may overlap with update operations (including put and remove). Retrievals reflect the results of the most recently completed update operations holding upon their onset. For aggregate operations such as putAll and clear, concurrent retrievals may reflect insertion or removal of only some entries. 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 not throw ConcurrentModificationException. However, iterators are designed to be used by only one thread at a time.

Upvotes: 1

Yahya Arshad
Yahya Arshad

Reputation: 1626

Concurrent Collections means multiple thread could perform add/remove operation on collection same time, No it is not thread safe

More Detail:

for further please read

What's the difference between ConcurrentHashMap and Collections.synchronizedMap(Map)? Is ConcurrentHashMap totally safe?

Upvotes: 2

tbsalling
tbsalling

Reputation: 4545

The concurrent collections are thread safe for reads; but you must expect ConcurrentModificationException in case of competing concurrent updates or when modifying a Collection while another thread is iterating over it.

Upvotes: 1

Related Questions