Each map is synchronized separately, and the method calls you show are not different than handling the calls on different lines:
So getting the Map from a is thread safe in that a will not be modified while the get() occurs. Similarly getting the String from the second map is safe in that the second map can not be modified while the get() operation occurs. However, when the a.get() method returns, the lock on a is released, so a may be modified before/while the second map is being accessed.
Similarly the below code does not prevent the outer map from being modified or read while the inner map is modified.
This would be relatively safe, since the maps are independent, removing the inner map from the outer map while modifying the inner map would not leave either map in an inconsistent state - at least for general purposes. If you have a specific need to make sure that the outer map is not modified while the inner map is accessed then you would need to manually lock on the outer map.
A hash table supporting full concurrency of retrievals and adjustable expected concurrency for updates. This class obeys the same functional specification as Hashtable, and includes versions of methods corresponding to each method of Hashtable. 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. This class is fully interoperable with Hashtable in programs that rely on its thread safety but not on its synchronization details.
So getting the Map from a is thread safe in that a will not be modified while the get() occurs.
Just to clarify something here, the ConcurrentHashMap retrieval operations do NOT entail locking
it based on a volatile variable of the Value in the Map.Entry as below which make the changes visible to any other thread trying to read the value.
In general, I do not think the below is thread safe since the data may get corrutped and may result in something which is not requested
String value = a.get("key1").get("key2");
Imagine the scenario that a thread A tryies to obtain the Map based on the given Key2 while thread B changes the value for the key2
Okay, the statement is true -- the concurrent hashmap does not use synchronization. It is based on volatile variables.... But ... if the definition of thread safe, means that you will not get a corruption, when two threads try to use the concurrent hashmap at the same time, then it is thread safe.
The concurrent hashmap does use the atomic libraries. And as such, it uses optimistic locking.... but it does use locking. This means that many threads can put and get from the hashmap concurrently, and no corruption should result. In fact, it should behave just like a regular synchronized hashmap -- except that it is has higher performance.