0

[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?

VB_
  • 45,112
  • 42
  • 145
  • 293

5 Answers5

4

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.

Marko Topolnik
  • 195,646
  • 29
  • 319
  • 436
2

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?

Community
  • 1
  • 1
Yahya Arshad
  • 1,626
  • 2
  • 19
  • 34
1

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.

tbsalling
  • 4,477
  • 4
  • 30
  • 51
  • see injecteer's answer. He said that they are thread safe for writes. Who is right? More explanations please – VB_ Feb 26 '14 at 13:32
1

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.

injecteer
  • 20,038
  • 4
  • 45
  • 89
  • please scenarion when they aren't thread safe. Please. and what about `HashTable`? – VB_ Feb 26 '14 at 13:31
  • I'd say Hashtable as well as pretty much all java basic collection types are thread-safe in context of reading. Only when you write and/or read simultaneously, you can get problems like `ConcurrentModificationException`. – injecteer Feb 26 '14 at 13:40
  • Is there any java map that is safe in context of concurent reading and writing (just like in my context section defined)? – VB_ Feb 26 '14 at 13:42
1

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)

Brett Okken
  • 6,210
  • 1
  • 19
  • 25
  • do you want to say that if I use `puIfAbsent` method will be my scenario thread safe? – VB_ Feb 26 '14 at 14:25
  • There is not nearly enough data to say with certainty that will make entire scenario thread safe. Use of that method for populating the outer map will almost certainly be part of the work required. What must be known is what work must be viewed as atomic. – Brett Okken Feb 26 '14 at 14:44
  • 1
    The use of remove also presents challenges. It would be more or less impossible during a remove to tell if a competing thread was actually manipulating the map at key where you are removing. It would be far simpler to just leave an empty map in the value once a value has been set. – Brett Okken Feb 26 '14 at 14:47