Prior to Java 5, the only way to concurrently access a HashMap was to synchronize the entire map. In case of high contention, this solution would fail as most of the threads would be waiting for other thread to release the lock on Map. Java 5 brings ConcurrentHashMap, in which only a part of the Map is locked, such that many threads can access different parts simultaneously. This optimization is possible, since HashMap stores their data in buckets. This optimization is known as lock striping.
I don't think you can say that categorically, because it will depend a lot on Shanky's pattern of use. ConcurrentSkipListMap, for example, is supposedly faster than a synchronized TreeMap under multitasking load, but it's quite a bit slower under normal (ie, uncontested) use; and where the 'crossover' comes can only be determined by testing.
I suspect that all you can definitely say is that the performance of ConcurrentHashMap is likely to scale better as load increases, because that's what it was designed for. The class can also be tuned for expected numbers of 'writers'; HashMap can't.
Prior to Java 5, the only way to concurrently access a HashMap was to synchronize the entire map. In case of high contention, this solution would fail as most of the threads would be waiting for other thread to release the lock on Map.
This claim also cannot be made without knowing a lot more about the OP's requirements, operating environment, and usage pattern. Lots of multithreaded programs used this approach successfully for over about a decade before Java 5 came along.
Shanky Sohar wrote:In the case of multithreading,,, we have four option for a map to use...
Can anybody Know which one to consider so that we can have a better performance/////
1. No, we can't without knowing more details about your situation, and probably not without testing your actual code in your actual environment with your actual usage patterns.
2. There's a fair chance that you won't be able to tell the difference among any of those approaches.
Unless you have a specific, measurable reason to know that some of them will fail to meet your performance requirements and others will succeed, the correct approach is to use the one that's easiest to use--that fits in best with your design, is easiest to write, test, debug and maintain--and then test its performance. If it's good enough for your current and expected future needs, then, by definition, there's no benefit to making it any faster.