Probably, the ConcurrentHashMap will be faster. Also it offers a richer set of atomic operations, such as putIfAbsent() (which would have required additional synchronization if you tried to do it with a synchronizedMap()).
[nandkishor ra]: The point is if I use the (2) map shall I need to make my get and set methods synchronized that will put and get back the value from HashMap.
No, ConcurrentHashMap is already designed so that get() and put() can be used safely by multiple threads concurrently.
[nandkishor ra]: If I would go with the first one it definitely needs to be synchronized as the javadoc suggests but using synchronized methods will degrade the performance.
I would say it may degrade performance. There are a great many applications where there will be no observable effect at all, because you have a performance bottleneck elsewhere. In general, don't assume that synchronization will be a problem, because it often isn't. Often it's best to just try it and see if the synchronization creates a performance problem or not, rather than making more complex code to avoid a problem that doesn't exist. However in this case, ConcurrentHashMap offers a simple solution that avoids synchronization, and so it's just as easy to not use synchronization as it is to use it. In other cases, if synchronization solves a problem that you can't easily solve another way, don't hesitate to try using synchronization.
You must be aware of �collection framework� that it is better to use over any other mechanism for performing operation on collected of objects.
But think is only that collection framework is not synchronized so obviously will perform faster then expected. But we always need to think in direction of multi threading application where we need to have synchronized data to be used.
For that Collection also has facility to use it while the way you talked about, it in this case it is always good to go with legacy classes like �Vector, Hashtable�, because these are also synchronized and faster the other programmatically synchronized collection objects, So I will prefer you to use Hashtable instead of you given options.
Ashok, does your advice apply at all to ConcurrentHashMap? Are you familiar with it at all? It sounds to me like you're just thinking about differences between Collections.synchronizedMap() and Hashtable. You might want to look into the new classes and interfaces added in JDK 5.
Furthermore, I don't agree at all with this statement: "...in this case it is always good to go with legacy classes like �Vector, Hashtable�, because these are also synchronized and faster the other programmatically synchronized collection objects". Even if we ignore ConcurrentHashMap (which is generally faster), saying "always" here is almost certainly wrong. There are many cases where there is no practical difference in performance, as there's a bottleneck elsewhere. There are many other cases where neither Hashtable nor synchronizedMap() is good, because you need to synchronize at a higher level than is provided by those classes.
Additionally, at this point Vector and Hashtable clutter up the API with unnecessary duplicated functionality and poorly-named methods, and the endless litany of beginning programmers unsure whether to use Vector or ArrayList, which usually just wastes people's time when they're worrying about nothing. And worse, the standard answer they receive creates false confidence in people who think they're writing "thread-safe" code just because they're using Vector or Hashtable.
Personally I'd be happier if Vector and Hashtable were removed from Java entirely. Sadly that will probably never happen, as it breaks backwards compatibility for existing programs. But I advocate avoiding them as much as possible, to minimize the problems they entail. [ July 19, 2007: Message edited by: Jim Yingst ]