HashMap是模拟的，因此可以在GWT客户端代码中使用，而Hashtable不是。

注意，很多答案都表明Hashtable是同步的。在实践中，这几乎不会给你带来什么好处。同步是在访问器/赋值器上进行的。方法将停止同时从映射中添加或删除两个线程，但在现实世界中，您通常需要额外的同步。

一个非常常见的习惯用法是“先检查后放”，即在Map中查找条目，如果它不存在，则添加它。无论使用Hashtable还是HashMap，这都不是原子操作。

可通过以下方式获得等效同步的HashMap：

Collections.synchronizedMap(myMap);

但要正确实现此逻辑，您需要以下形式的额外同步：

synchronized(myMap) {
    if (!myMap.containsKey("tomato"))
        myMap.put("tomato", "red");
}

即使迭代Hashtable的条目（或Collections.synchronizedMap获得的HashMap）也不是线程安全的，除非您还通过额外的同步来防止Map被修改。

ConcurrentMap接口（例如ConcurrentHashMap）的实现通过包括线程安全检查然后动作语义（如：

ConcurrentMap.putIfAbsent(key, value);

HashMap：使用哈希代码对数组进行索引的Map接口的实现。哈希表：嗨，1998年来电话。他们想拿回他们的集合API。

说真的，你最好完全远离Hashtable。对于单线程应用程序，您不需要额外的同步开销。对于高度并发的应用程序，偏执的同步可能会导致饥饿、死锁或不必要的垃圾收集暂停。正如Tim Howland所指出的，您可以使用ConcurrentHashMap。

除了已经提到的差异之外，应该注意的是，自从Java8以来，HashMap动态地用TreeNodes（红黑树）替换每个bucket中使用的Nodes（链表），因此即使存在高哈希冲突，搜索时最坏的情况也是

HashMap的O（log（n））与Hashtable中的O（n）。

*上述改进尚未应用于Hashtable，而仅应用于HashMap、LinkedHashMap和ConcurrentHashMap。

仅供参考，目前，

TREEIFY_THRESHOLD=8：如果存储桶包含8个以上的节点，则链接列表将转换为平衡树。UNTREEIFY_THRESHOLD=6：当存储桶太小（由于删除或调整大小）时，树将转换回链接列表。

HashMap和Hashtable也有显著的算法差异。以前没有人提到过这一点，所以我才提出来。HashMap将构造一个大小为两倍的哈希表，动态地增加它，以便在任何bucket中最多有八个元素（冲突），并且对于一般的元素类型，可以很好地搅拌这些元素。然而，如果你知道你在做什么，Hashtable实现提供了对哈希的更好和更精细的控制，也就是说，你可以使用最接近你的值域大小的素数来固定表大小，这将导致比HashMap更好的性能，即在某些情况下更少的冲突。

除了在这个问题中广泛讨论的明显差异之外，我认为Hashtable是一款“手动驾驶”汽车，您可以更好地控制哈希，而HashMap是“自动驾驶”的对应车型，通常表现良好。

Hashtable是同步的，而HashMap不是。另一个区别是HashMap中的迭代器是故障安全的而Hashtable的枚举器不是。如果您更改地图在迭代时，你会知道。HashMap允许其中包含空值，而Hashtable不允许。