關于兩者的區別，轉載內容如下：

1、Hashtable是Dictionary的子類，HashMap是Map接口的一個實現類；

2、Hashtable中的方法是同步的，而HashMap中的方法在缺省情況下是非同步的。即是說，在多線程應用程序中，不用專門的操作就安全地可以使用Hashtable了；而對于 HashMap，則需要額外的同步機制。但HashMap的同步問題可通過Collections的一個靜態方法得到解決：
Map Collections.synchronizedMap(Map m)
這個方法返回一個同步的Map，這個Map封裝了底層的HashMap的所有方法，使得底層的HashMap即使是在多線程的環境中也是安全的。

3、在HashMap中，null可以作為鍵，這樣的鍵只有一個；可以有一個或多個鍵所對應的值為null。當get()方法返回null值時，即可以表示 HashMap中沒有該鍵，也可以表示該鍵所對應的值為null。因此，在HashMap中不能由get()方法來判斷HashMap中是否存在某個鍵， 而應該用containsKey()方法來判斷。

4、其底層的實現機制不同，HashMap的訪問速度要快于Hashtable，因為它不需要進行同步檢驗，建議在非多線程環境中使用HashMap代替Hashtable

補充：
5、HashMap的默認初始容量是16；Hashtable的默認初始容量是11
6、keySet()、values() 、entrySet() 支持元素的刪除，但是不支持元素的添加

==================== 分割線：JDK5幫助文檔的描述 ==================

HashMap:

基于哈希表的 Map 接口的實現。此實現提供所有可選的映射操作，并允許使用 null 值和 null 鍵。（除了不同步和允許使用 null 之外，HashMap 類與 Hashtable 大致相同。）此類不保證映射的順序，特別是它不保證該順序恒久不變。 

此實現假定哈希函數將元素正確分布在各桶之間，可為基本操作（get 和 put）提供穩定的性能。迭代集合視圖所需的時間與 HashMap 實例的“容量”（桶的數量）及其大?。ㄦI-值映射關系數）的和成比例。所以，如果迭代性能很重要，則不要將初始容量設置得太高（或將加載因子設置得太低）。

HashMap 的實例有兩個參數影響其性能：初始容量和加載因子。容量是哈希表中桶的數量，初始容量只是哈希表在創建時的容量。加載因子 是哈希表在其容量自動增加之前可以達到多滿的一種尺度。當哈希表中的條目數超出了加載因子與當前容量的乘積時，通過調用 rehash 方法將容量翻倍。

通常，默認加載因子 (.75) 在時間和空間成本上尋求一種折衷。 加載因子過高雖然減少了空間開銷，但同時也增加了查詢成本（在大多數 HashMap 類的操作中，包括 get 和 put 操作，都反映了這一點）。在設置初始容量時應該考慮到映射中所需的條目數及其加載因子，以便最大限度地降低 rehash 操作次數。如果初始容量大于最大條目數除以加載因子，則不會發生 rehash 操作。

如果很多映射關系要存儲在 HashMap 實例中，則相對于按需執行自動的 rehash 操作以增大表的容量來說，使用足夠大的初始容量創建它將使得映射關系能更有效地存儲。

注意，此實現不是同步的。如果多個線程同時訪問此映射，而其中至少一個線程從結構上修改了該映射，則它必須保持外部同步。（結構上的修改是指添加或刪除一個或多個映射關系的操作；僅改變與實例已經包含的鍵關聯的值不是結構上的修改。）這一般通過對自然封裝該映射的對象進行同步操作來完成。如果不存在這樣的對象，則應該使用 Collections.synchronizedMap 方法來“包裝”該映射。最好在創建時完成這一操作，以防止對映射進行意外的不同步訪問，如下所示：

 Map m = Collections.synchronizedMap(new HashMap(...));
 由所有此類的“集合視圖方法”所返回的迭代器都是快速失敗的： 在迭代器創建之后，如果從結構上對映射進行修改，除非通過迭代器自身的 remove 或 add 方法，其他任何時間任何方式的修改，迭代器都將拋出 ConcurrentModificationException。因此，面對并發的修改，迭代器很快就會完全失敗，而不冒在將來不確定的時間任意發生不 確定行為的風險。

注意，迭代器的快速失敗行為不能得到保證，一般來說，存在不同步的并發修改時，不可能作出任何堅決的保證。快速失敗迭代器盡最大努力拋出 ConcurrentModificationException。因此，編寫依賴于此異常程序的方式是錯誤的，正確做法是：迭代器的快速失敗行為應該僅 用于檢測程序錯誤。 

Hashtable:

此類實現一個哈希表，該哈希表將鍵映射到相應的值。任何非 null 對象都可以用作鍵或值。

為了成功地在哈希表中存儲和檢索對象，用作鍵的對象必須實現 hashCode 方法和 equals 方法。

Hashtable 的實例有兩個參數影響其性能：初始容量和加載因子。容量是哈希表中桶的數量，初始容量就是哈希表創建時的容量。注意，哈希表的狀態為 open：在發生“哈希沖突”的情況下，單個桶會存儲多個條目，這些條目必須按順序搜索。加載因子是對哈希表在其容量自動增加之前可以達到多滿的一個尺 度。初始容量和加載因子這兩個參數只是對該實現的提示。關于何時以及是否調用 rehash 方法的具體細節則依賴于該實現。

通常，默認加載因子(.75)在時間和空間成本上尋求一種折衷。加載因子過高雖然減少了空間開銷，但同時也增加了查找某個條目的時間（在大多數 Hashtable 操作中，包括 get 和 put 操作，都反映了這一點）。

初始容量主要控制空間消耗與執行 rehash 操作所需要的時間損耗之間的平衡。如果初始容量大于Hashtable 所包含的最大條目數除以加載因子，則永遠不會發生 rehash 操作。但是，將初始容量設置太高可能會浪費空間。

如果很多條目要存儲在一個 Hashtable 中，那么與根據需要執行自動 rehashing 操作來增大表的容量的做法相比，使用足夠大的初始容量創建哈希表或許可以更有效地插入條目。

下面這個示例創建了一個數字的哈希表。它將數字的名稱用作鍵：

要檢索一個數字，可以使用以下代碼：

 自 Java 2 平臺 v1.2 以來，此類已經改進為可以實現 Map，因此它變成了 Java Collections Framework 的一部分。與新集合的實現不同，Hashtable 是同步的。

由迭代器返回的 Iterator 和由所有 Hashtable 的“collection 視圖方法”返回的 Collection 的 listIterator 方法都是快速失敗 的：在創建 Iterator 之后，如果從結構上對 Hashtable 進行修改，除非通過 Iterator 自身的移除或添加方法，否則在任何時間以任何方式對其進行修改，Iterator 都將拋出 ConcurrentModificationException。因此，面對并發的修改，Iterator 很快就會完全失敗，而不冒在將來某個不確定的時間發生任意不確定行為的風險。由 Hashtable 的鍵和值方法返回的 Enumeration 不 是快速失敗的。

注意，迭代器的快速失敗行為無法得到保證，因為一般來說，不可能對是否出現不同步并發修改做出任何硬性保證。快速失敗迭代器會盡最大努力拋出 ConcurrentModificationException。因此，為提高這類迭代器的正確性而編寫一個依賴于此異常的程序是錯誤做法：迭代器的快 速失敗行為應該僅用于檢測程序錯誤。