views:

33933

answers:

10

What is the difference between a hashmap and a hashtable in Java, and which is more efficient for non-threaded applications?

+1  A: 

Based on the info here, I'd recommend going with HashMap. I think the biggest advantage is that Java will prevent you from modifying it while you are iterating over it, unless you do it through the iterator.

pkaeding
+1  A: 

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.

izb
+1  A: 

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.

Miles D
+5  A: 

In addition to what izb said, HashMap allows null values, whereas the Hashtable does not.

Also note that Hashtable extends the Dictionary class, which as the Javadocs state, is obsolete and has been replaced by the Map interface.

matt b
+1  A: 

For threaded apps, you can often get away with ConcurrentHashMap- depends on your performance requirements.

Tim Howland
+42  A: 

There are several differences between HashMap and Hashtable in Java:

  1. Hashtable is synchronized, whereas HashMap is not. This makes HashMap better for non-threaded applications, as unsynchronized Objects typically perform better than synchronized ones.
  2. Hashtable does not allow null keys or values. HashMap allows one null key and any number of null values.
  3. 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.

Josh Brown
This statement "unsynchronized Objects typically perform better than synchronized ones" isn't always true anymore with modern compilers. The key point is that the HashMap must be externally synchronized rather than relying on the internal synchronized methods.
Bob Cross
@Bob What's the case of false?
Eonil
@Eonil, could you rephrase the question? I'm not sure I understand what you're asking.
Bob Cross
A: 

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.

Apocalisp
+36  A: 

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)
serg10
Also note that if a HashMap is modified, iterators pointing to it are rendered invalid.
Chris Kaminski
+11  A: 

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.

aberrant80
From Hashtable javadoc (emphasis added): "As of the Java 2 platform v1.2, this class was retrofitted to implement the Map interface, **making it a member of the Java Collections Framework**." However, you are right that it is legacy code. All the benefits of synchronization can be obtained more efficiently with Collections.synchronizedMap(HashMap). (Similar to Vector being a legacy version of Collections.synchronizedList(ArrayList).)
Kip
A: 

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?

leden