What is the difference between a hashmap and a hashtable in Java, and which is more efficient for non-threaded applications?
Hashtable is synchronized, whereas HashMap isn't. That makes Hashtable slower than Hashmap.
For non-threaded apps, use HashMap since they are otherwise the same in terms of functionality.
As I understand it, Hashtable is similar to the HashMap and has a similar interface. It is recommended that you use HashMap unless yoou require support for legacy applications or you need synchronisation - as the Hashtables methods are synchronised. So in your case as you are not multi-threading, HashMaps are your best bet.
For threaded apps, you can often get away with ConcurrentHashMap- depends on your performance requirements.
There are several differences between HashMap and Hashtable in Java:
- Hashtable is synchronized, whereas HashMap is not. This makes HashMap better for non-threaded applications, as unsynchronized Objects typically perform better than synchronized ones.
- Hashtable does not allow null keys or values. HashMap allows one null key and any number of null values.
- One of HashMap's subclasses is LinkedHashMap, so in the event that you'd want predictable iteration order (which is insertion order by default), you could easily swap out the HashMap for a LinkedHashMap. This wouldn't be as easy if you were using Hashtable.
Since synchronization is not an issue for you, I'd recommend HashMap.
HashMap: An implementation of the Map interface that uses a lookup table of hashcodes to locate keys. HashTable: Hi, 1998 called. They want their collections API back.
Seriously though, you're better off staying away from Hashtable altogether. For single-threaded apps, you don't need the extra overhead of syncrhonisation. For highly concurrent apps, the paranoid synchronisation might lead to starvation and deadlocks, especially during garbage collection. Like Tim Howland pointed out, you might use ConcurrentHashMap instead.
Note, that a lot of the answers state that Hashtable is synchronised. In practice this buys you 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.
A very common idiom is to "check then put" - i.e. look for an entry in the Map, and add it if it does not already exist. This is not in any way an atomic operation whether you use Hashtable or HashMap.
An equivalently synchronised HashMap can be obtained by:
Collections.synchronizedMap(myMap);
But to correctly implement this logic you need additional synchronisation of the form:
synchronized(myMap) {
if (!myMap.containsKey("tomato")
myMap.put("tomato", "red");
}
Even iterating over a Hashtable's entries (or a HashMap obtained by Collections.synchronizedMap) is not thread safe unless you also guard the Map from being modified through additional synchronization.
Implementations of the ConcurrentMap interface (for example ConcurrentHashMap) solve some of this by including thread safe check-then-act semantics such as:
ConcurrentMap.putIfAbsent(key, value)
No one's mentioned the fact that Hashtable
is not part of the Java Collections Framework - it just provides a similar API. Also, Hashtable
is considered legacy code. There's nothing about Hashtable
that can't be done using HashMap
or derivations of HashMap
, so for new code, I don't see any justification for going back to Hashtable
.
I have recently had a dilemma whether to use Collections.synchronizedMap(new HashMap) or Hashtable, and a simple benchmark showed that that Hashtable is around 10 times slower. So I decided to use HashMap wrapped as a synchronizedMap. Was this just a lucky situation or the HashMap is so much effiecient even when externally synchronized?