請問HashSet 和HashMap類的區(qū)別

mawav

如題

jjjian

HASHSET：
    此類實現(xiàn) Set 接口，由哈希表（實際上是一個 HashMap 實例）支持。它不保證集合的迭代順序；特別是它不保證該順序恒久不變。此類允許使用 null 元素。
    此類為基本操作提供了穩(wěn)定性能，這些基本操作包括 add、remove、contains 和 size，假定哈希函數(shù)將這些元素正確地分布在桶中。對此集合進行迭代所需的時間與 HashSet 實例的大�。ㄔ�素的數(shù)量）和底層 HashMap 實例（桶的數(shù)量）的“容量”的和成比例。因此，如果迭代性能很重要，則不要將初始容量設(shè)置得太高（或?qū)⒓虞d因子設(shè)置得太低）。
    注意，此實現(xiàn)不是同步的。 如果多個線程同時訪問一個集合，而其中至少一個線程修改了該集合，那么它必須 保持外部同步。這通常是通過對自然封裝該集合的對象執(zhí)行同步操作來完成的。如果不存在這樣的對象，則應(yīng)該使用 Collections.synchronizedSet 方法來“包裝”集合。最好在創(chuàng)建時完成這一操作，以防止對 HashSet 實例進行意外的不同步訪問：
          Set s = Collections.synchronizedSet(new HashSet(...));
    此類的 iterator 方法返回的迭代器是快速失敗 的：在創(chuàng)建迭代器之后，如果對集合進行修改，除非通過迭代器自身的 remove 方法，否則在任何時間以任何方式對其進行修改，Iterator 都將拋出 ConcurrentModificationException。因此，面對并發(fā)的修改，迭代器很快就會完全失敗，而不冒將來在某個不確定時間發(fā)生任意不確定行為的風(fēng)險。
    注意，迭代器的快速失敗行為無法得到保證，因為一般來說，不可能對是否出現(xiàn)不同步并發(fā)修改做出任何硬性保證�？焖偈�敗迭代器在盡最大努力拋出 ConcurrentModificationException。因此，為提高這類迭代器的正確性而編寫一個依賴于此異常的程序是錯誤做法：迭代器的快速失敗行為應(yīng)該僅用于檢測程序錯誤。

HASHMAP：
    基于哈希表的 Map 接口的實現(xiàn)。此實現(xiàn)提供所有可選的映射操作，并允許使用 null 值和 null 鍵。（除了不同步和允許使用 null 之外，HashMap 類與 Hashtable 大致相同。）此類不保證映射的順序，特別是它不保證該順序恒久不變。
    此實現(xiàn)假定哈希函數(shù)將元素正確分布在各桶之間，可為基本操作（get 和 put）提供穩(wěn)定的性能。迭代集合視圖所需的時間與 HashMap 實例的“容量”（桶的數(shù)量）及其大�。ㄦI-值映射關(guān)系數(shù)）的和成比例。所以，如果迭代性能很重要，則不要將初始容量設(shè)置得太高（或?qū)⒓虞d因子設(shè)置得太低）。
    HashMap 的實例有兩個參數(shù)影響其性能：初始容量 和加載因子。容量 是哈希表中桶的數(shù)量，初始容量只是哈希表在創(chuàng)建時的容量。加載因子 是哈希表在其容量自動增加之前可以達到多滿的一種尺度。當(dāng)哈希表中的條目數(shù)超出了加載因子與當(dāng)前容量的乘積時，通過調(diào)用 rehash 方法將容量翻倍。
    通常，默認加載因子 (.75) 在時間和空間成本上尋求一種折衷。加載因子過高雖然減少了空間開銷，但同時也增加了查詢成本（在大多數(shù) HashMap 類的操作中，包括 get 和 put 操作，都反映了這一點）。在設(shè)置初始容量時應(yīng)該考慮到映射中所需的條目數(shù)及其加載因子，以便最大限度地降低 rehash 操作次數(shù)。如果初始容量大于最大條目數(shù)除以加載因子，則不會發(fā)生 rehash 操作。
    如果很多映射關(guān)系要存儲在 HashMap 實例中，則相對于按需執(zhí)行自動的 rehash 操作以增大表的容量來說，使用足夠大的初始容量創(chuàng)建它將使得映射關(guān)系能更有效地存儲。
    注意，此實現(xiàn)不是同步的。如果多個線程同時訪問此映射，而其中至少一個線程從結(jié)構(gòu)上修改了該映射，則它必須 保持外部同步。（結(jié)構(gòu)上的修改是指添加或刪除一個或多個映射關(guān)系的操作；僅改變與實例已經(jīng)包含的鍵關(guān)聯(lián)的值不是結(jié)構(gòu)上的修改。）這一般通過對自然封裝該映射的對象進行同步操作來完成。如果不存在這樣的對象，則應(yīng)該使用 Collections.synchronizedMap 方法來“包裝”該映射。最好在創(chuàng)建時完成這一操作，以防止對映射進行意外的不同步訪問，如下所示：
      Map m = Collections.synchronizedMap(new HashMap(...));
    由所有此類的“集合視圖方法”所返回的迭代器都是快速失敗 的：在迭代器創(chuàng)建之后，如果從結(jié)構(gòu)上對映射進行修改，除非通過迭代器自身的 remove 或 add 方法，其他任何時間任何方式的修改，迭代器都將拋出 ConcurrentModificationException。因此，面對并發(fā)的修改，迭代器很快就會完全失敗，而不冒在將來不確定的時間任意發(fā)生不確定行為的風(fēng)險。
    注意，迭代器的快速失敗行為不能得到保證，一般來說，存在不同步的并發(fā)修改時，不可能作出任何堅決的保證�？焖偈�敗迭代器盡最大努力拋出 ConcurrentModificationException。因此，編寫依賴于此異常程序的方式是錯誤的，正確做法是：迭代器的快速失敗行為應(yīng)該僅用于檢測程序錯誤。