基於雜湊表的 Map 介面的實現。此實現提供所有可選的對映操作，並允許使用 null 值和 null 鍵。（除了非同步和允許使用 null 之外，HashMap 類與 Hashtable 大致相同。）此類不保證對映的順序，特別是它不保證該順序恆久不變。 此實現假定雜湊函式將元素適當地分佈在各桶之間，可為基本操作（get 和 put）提供穩定的效能。迭代 collection 檢視所需的時間與 HashMap 例項的“容量”（桶的數量）及其大小（鍵-值對映關係數）成比例。所以，如果迭代效能很重要，則不要將初始容量設定得太高（或將載入因子設定得太低）。 HashMap 的例項有兩個引數影響其效能：初始容量 和載入因子。容量 是雜湊表中桶的數量，初始容量只是雜湊表在建立時的容量。載入因子 是雜湊表在其容量自動增加之前可以達到多滿的一種尺度。當雜湊表中的條目數超出了載入因子與當前容量的乘積時，則要對該雜湊表進行 rehash 操作（即重建內部資料結構），從而雜湊表將具有大約兩倍的桶數。 通常，預設載入因子 (.75) 在時間和空間成本上尋求一種折衷。載入因子過高雖然減少了空間開銷，但同時也增加了查詢成本（在大多數 HashMap 類的操作中，包括 get 和 put 操作，都反映了這一點）。在設定初始容量時應該考慮到對映中所需的條目數及其載入因子，以便最大限度地減少 rehash 操作次數。如果初始容量大於最大條目數除以載入因子，則不會發生 rehash 操作。 如果很多對映關係要儲存在 HashMap 例項中，則相對於按需執行自動的 rehash 操作以增大表的容量來說，使用足夠大的初始容量建立它將使得對映關係能更有效地儲存。 注意，此實現不是同步的。如果多個執行緒同時訪問一個雜湊對映，而其中至少一個執行緒從結構上修改了該對映，則它必須 保持外部同步。（結構上的修改是指新增或刪除一個或多個對映關係的任何操作；僅改變與例項已經包含的鍵關聯的值不是結構上的修改。）這一般透過對自然封裝該對映的物件進行同步操作來完成。如果不存在這樣的物件，則應該使用 Collections.synchronizedMap 方法來“包裝”該對映。最好在建立時完成這一操作，以防止對對映進行意外的非同步訪問，如下所示： Map m = Collections.synchronizedMap(new HashMap(...)); 由所有此類的“collection 檢視方法”所返回的迭代器都是快速失敗 的：在迭代器建立之後，如果從結構上對對映進行修改，除非透過迭代器本身的 remove 方法，其他任何時間任何方式的修改，迭代器都將丟擲 ConcurrentModificationException。因此，面對併發的修改，迭代器很快就會完全失敗，而不冒在將來不確定的時間發生任意不確定行為的風險。 注意，迭代器的快速失敗行為不能得到保證，一般來說，存在非同步的併發修改時，不可能作出任何堅決的保證。快速失敗迭代器盡最大努力丟擲 ConcurrentModificationException。因此，編寫依賴於此異常的程式的做法是錯誤的，正確做法是：迭代器的快速失敗行為應該僅用於檢測程式錯誤。 使用示例: HashMap a = new HashMap(); a.put("name", "abcdef"); // key是name，value是字串abcdef System.out.println(a.get("name"));// 根據key取得其值並輸出 List list = new ArrayList(); list.add(a); // 加入1題所建立的hashmap a = new HashMap(); // 建立另一個hashmap a.put("name", "123456");//key是name，value是字串123456 list.add(a);// 加入另一個hashmap
基於雜湊表的 Map 介面的實現。此實現提供所有可選的對映操作，並允許使用 null 值和 null 鍵。（除了非同步和允許使用 null 之外，HashMap 類與 Hashtable 大致相同。）此類不保證對映的順序，特別是它不保證該順序恆久不變。 此實現假定雜湊函式將元素適當地分佈在各桶之間，可為基本操作（get 和 put）提供穩定的效能。迭代 collection 檢視所需的時間與 HashMap 例項的“容量”（桶的數量）及其大小（鍵-值對映關係數）成比例。所以，如果迭代效能很重要，則不要將初始容量設定得太高（或將載入因子設定得太低）。 HashMap 的例項有兩個引數影響其效能：初始容量 和載入因子。容量 是雜湊表中桶的數量，初始容量只是雜湊表在建立時的容量。載入因子 是雜湊表在其容量自動增加之前可以達到多滿的一種尺度。當雜湊表中的條目數超出了載入因子與當前容量的乘積時，則要對該雜湊表進行 rehash 操作（即重建內部資料結構），從而雜湊表將具有大約兩倍的桶數。 通常，預設載入因子 (.75) 在時間和空間成本上尋求一種折衷。載入因子過高雖然減少了空間開銷，但同時也增加了查詢成本（在大多數 HashMap 類的操作中，包括 get 和 put 操作，都反映了這一點）。在設定初始容量時應該考慮到對映中所需的條目數及其載入因子，以便最大限度地減少 rehash 操作次數。如果初始容量大於最大條目數除以載入因子，則不會發生 rehash 操作。 如果很多對映關係要儲存在 HashMap 例項中，則相對於按需執行自動的 rehash 操作以增大表的容量來說，使用足夠大的初始容量建立它將使得對映關係能更有效地儲存。 注意，此實現不是同步的。如果多個執行緒同時訪問一個雜湊對映，而其中至少一個執行緒從結構上修改了該對映，則它必須 保持外部同步。（結構上的修改是指新增或刪除一個或多個對映關係的任何操作；僅改變與例項已經包含的鍵關聯的值不是結構上的修改。）這一般透過對自然封裝該對映的物件進行同步操作來完成。如果不存在這樣的物件，則應該使用 Collections.synchronizedMap 方法來“包裝”該對映。最好在建立時完成這一操作，以防止對對映進行意外的非同步訪問，如下所示： Map m = Collections.synchronizedMap(new HashMap(...)); 由所有此類的“collection 檢視方法”所返回的迭代器都是快速失敗 的：在迭代器建立之後，如果從結構上對對映進行修改，除非透過迭代器本身的 remove 方法，其他任何時間任何方式的修改，迭代器都將丟擲 ConcurrentModificationException。因此，面對併發的修改，迭代器很快就會完全失敗，而不冒在將來不確定的時間發生任意不確定行為的風險。 注意，迭代器的快速失敗行為不能得到保證，一般來說，存在非同步的併發修改時，不可能作出任何堅決的保證。快速失敗迭代器盡最大努力丟擲 ConcurrentModificationException。因此，編寫依賴於此異常的程式的做法是錯誤的，正確做法是：迭代器的快速失敗行為應該僅用於檢測程式錯誤。 使用示例: HashMap a = new HashMap(); a.put("name", "abcdef"); // key是name，value是字串abcdef System.out.println(a.get("name"));// 根據key取得其值並輸出 List list = new ArrayList(); list.add(a); // 加入1題所建立的hashmap a = new HashMap(); // 建立另一個hashmap a.put("name", "123456");//key是name，value是字串123456 list.add(a);// 加入另一個hashmap