public class HashMap<K,V> 
extends AbstractMap<K,V> 
implements Map<K,V>, Cloneable, Serializable

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

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

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

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

如果很多映射關(guān)系要存儲(chǔ)在 HashMap 實(shí)例中，則相對(duì)于按需執(zhí)行自動(dòng)的 rehash 操作以增大表的容量來說，使用足夠大的初始容量創(chuàng)建它將使得映射關(guān)系能更有效地存儲(chǔ)。

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

 Map m = Collections.synchronizedMap(new HashMap(...));

由所有此類的“集合視圖方法”所返回的迭代器都是快速失敗 的：在迭代器創(chuàng)建之后，如果從結(jié)構(gòu)上對(duì)映射進(jìn)行修改，除非通過迭代器自身的 remove 或 add 方法，其他任何時(shí)間任何方式的修改，迭代器都將拋出 ConcurrentModificationException。因此，面對(duì)并發(fā)的修改，迭代器很快就會(huì)完全失敗，而不冒在將來不確定的時(shí)間任意發(fā)生不確定行為的風(fēng)險(xiǎn)。

注意，迭代器的快速失敗行為不能得到保證，一般來說，存在不同步的并發(fā)修改時(shí)，不可能作出任何堅(jiān)決的保證?？焖偈〉鞅M最大努力拋出 ConcurrentModificationException。因此，編寫依賴于此異常程序的方式是錯(cuò)誤的，正確做法是：迭代器的快速失敗行為應(yīng)該僅用于檢測程序錯(cuò)誤。

public class LinkedHashMap<K,V> 
extends HashMap<K,V> 
implements Map<K,V>

Map 接口的哈希表和鏈接列表實(shí)現(xiàn)，具有可預(yù)知的迭代順序。此實(shí)現(xiàn)與 HashMap 的不同之處在于，后者維護(hù)著一個(gè)運(yùn)行于所有條目的雙重鏈接列表。此鏈接列表定義了迭代順序，該迭代順序通常就是將鍵插入到映射中的順序（插入順序）。注意，如果在映射中重新插入 鍵，則插入順序不受影響。（如果在調(diào)用 m.put(k, v) 前 m.containsKey(k) 返回了 true，則調(diào)用時(shí)會(huì)將鍵 k 重新插入到映射 m 中。）

此實(shí)現(xiàn)可以讓客戶避免未指定的、由 HashMap（及 Hashtable）所提供的通常為雜亂無章的排序工作，同時(shí)無需增加與 TreeMap 相關(guān)的成本。使用它可以生成一個(gè)與原來順序相同的映射副本，而與原映射的實(shí)現(xiàn)無關(guān)：

     void foo(Map m) {
Map copy = new LinkedHashMap(m);
...
}

如果模塊通過輸入得到一個(gè)映射，復(fù)制這個(gè)映射，然后返回由此副本確定其順序的結(jié)果，這種情況下這項(xiàng)技術(shù)特別有用。（客戶通常期望返回的內(nèi)容與其出現(xiàn)的順序相同。）

提供特殊的構(gòu)造方法來創(chuàng)建鏈接哈希映射，該哈希映射的迭代順序就是最后訪問其條目的順序，從近期訪問最少到近期訪問最多的順序（訪問順序）。這種映射很適合構(gòu)建 LRU 緩存。調(diào)用 put 或 get 方法將會(huì)訪問相應(yīng)的條目（假定調(diào)用完成后它還存在）。putAll 方法以指定映射的條目集合迭代器提供的鍵-值映射關(guān)系的順序，為指定映射的每個(gè)映射關(guān)系生成一個(gè)條目訪問。任何其他方法均不生成條目訪問。特別是，collection 視圖上的操作不 影響底層映射的迭代順序。

可以重寫 removeEldestEntry(Map.Entry) 方法來實(shí)施策略，以便在將新映射關(guān)系添加到映射時(shí)自動(dòng)移除舊的映射關(guān)系。

此類提供所有可選的 Map 操作，并且允許 null 元素。與 HashMap 一樣，它可以為基本操作（add、contains 和 remove）提供穩(wěn)定的性能，假定哈希函數(shù)將元素正確分布到桶中。由于增加了維護(hù)鏈接列表的開支，其性能很可能比 HashMap 稍遜一籌，不過這一點(diǎn)例外：LinkedHashMap 的 collection 視圖迭代所需時(shí)間與映射的大小 成比例。HashMap 迭代時(shí)間很可能開支較大，因?yàn)樗枰臅r(shí)間與其容量 成比例。

鏈接的哈希映射具有兩個(gè)影響其性能的參數(shù)：初始容量和加載因子。它們的定義與 HashMap 極其相似。要注意，為初始容量選擇非常高的值對(duì)此類的影響比對(duì) HashMap 要小，因?yàn)榇祟惖牡鷷r(shí)間不受容量的影響。

注意，此實(shí)現(xiàn)不是同步的。如果多個(gè)線程同時(shí)訪問鏈接的哈希映射，而其中至少一個(gè)線程從結(jié)構(gòu)上修改了該映射，則它必須 保持外部同步。這一般通過對(duì)自然封裝該映射的對(duì)象進(jìn)行同步操作來完成。如果不存在這樣的對(duì)象，則應(yīng)該使用 Collections.synchronizedMap 方法來“包裝”該映射。最好在創(chuàng)建時(shí)完成這一操作，以防止意外的非同步訪問：

    Map m = Collections.synchronizedMap(new LinkedHashMap(...));

結(jié)構(gòu)修改是指添加或刪除一個(gè)或多個(gè)映射關(guān)系，或者在按訪問順序鏈接的哈希映射中影響迭代順序的任何操作。在按插入順序鏈接的哈希映射中，僅更改與映射中已包含鍵關(guān)聯(lián)的值不是結(jié)構(gòu)修改。在按訪問順序鏈接的哈希映射中，僅利用 get 查詢映射不是結(jié)構(gòu)修改。）

Collection（由此類的所有 collection 視圖方法所返回）的 iterator 方法返回的迭代器都是快速失敗 的：在迭代器創(chuàng)建之后，如果從結(jié)構(gòu)上對(duì)映射進(jìn)行修改，除非通過迭代器自身的移除方法，其他任何時(shí)間任何方式的修改，迭代器都將拋出 ConcurrentModificationException。因此，面對(duì)并發(fā)的修改，迭代器很快就會(huì)完全失敗，而不冒將來不確定的時(shí)間任意發(fā)生不確定行為的風(fēng)險(xiǎn)。

注意，迭代器的快速失敗行為無法得到保證，因?yàn)橐话銇碚f，不可能對(duì)是否出現(xiàn)不同步并發(fā)修改做出任何硬性保證?？焖偈〉鲿?huì)盡最大努力拋出 ConcurrentModificationException。因此，編寫依賴于此異常的程序的方式是錯(cuò)誤的，正確做法是：迭代器的快速失敗行為應(yīng)該僅用于檢測程序錯(cuò)誤。

此類是 Java Collections Framework 的成員。

  回復(fù)  更多評(píng)論