Is java.util.Hashtable thread safe?

Question

It\'s been a while since I\'ve used hashtable for anything significant, but I seem to recall the get() and put() methods being synchronized.

The JavaDocs don\'t ref

Answer 1

Note, that a lot of the answers state that Hashtable is synchronised. but this will give you a very little. The synchronization is on the accessor / mutator methods will stop two threads adding or removing from the map concurrently, but in the real world you will often need additional synchronisation.

Even iterating over a Hashtable's entries is not thread safe unless you also guard the Map from being modified through additional synchronization.

Answer 2

No. It is 'threadsafe' only to the extent that its methods are synchronized. However it is not threadsafe in general, and it can't be, because classes that export internal state such as Iterators or Enumerations require the use of the internal state to be synchronized as well. That's why the new Collections classes are not synchronized, as the Java designers recognized that thread-safety is up to the user of the class, not the class itself.

Answer 3

For general usage it is thread safe.

But you have to understand that it doesent make your application logic around it thread-safe. For e.g. consider implementing to put a value in a map, if its not there already. This idiom is called putIfAbsent. Its difficult to implement this in a thread-safe manner using HashTable alone. Similarly for the idiom replace(k,V,V).

Hence for certain idioms like putIfAbsent and and replace(K,V,V), I would recommend using ConcurrentHashMap

Answer 4

I'm asking is "Is java.util.Hashtable thread safe?".

Yes Hashtable is thread safe, If a thread safe is not needed in your application then go through HashMap, In case, If a thread-safe implementation is desired,then it is recommended to use ConcurrentHashMap in place of Hashtable.

Answer 5

Yes, Hashtable thread safe, so only one thread can access a hashtable at any time

HashMap, on the other side, is not thread safe (and thus 'faster').

Answer 6

It is threadsafe because the get, put, contains methods etc are synchronized. Furthermore, Several threads will not be able to access the hashtable at the same time, regardless of which entries they are modifying.

edit - amended to include the provisio that synchronization makes the hashtable internally threadsafe in that it is modified atomically; it doesn't guard against race conditions in outside code caused by concurrent access to the hashtable by multiple threads.