Hashmap

　　基于哈希表的 Map 接口的實現。此實現提供所有可選的映射操作，并允許使用 null 值和 null 鍵。（除了非同步和允許使用 null 之外，HashMap 類與 Hashtable 大致相同。）此類不保證映射的順序，特別是它不保證該順序恒久不變。 此實現假定哈希函數將元素適當地分布在各桶之間，可為基本操作（get 和 put）提供穩定的性能。迭代 collection 視圖所需的時間與 HashMap 實例的“容量”（桶的數量）及其大小（鍵-值映射關系數）成比例。所以，如果迭代性能很重要，則不要將初始容量設置得太高（或將加載因子設置得太低）。

　　Hashmap重要參數

　　HashMap 的實例有兩個參數影響其性能：初始容量 和加載因子。容量是哈希表中桶的數量，初始容量只是哈希表在創建時的容量。加載因子 是哈希表在其容量自動增加之前可以達到多滿的一種尺度。當哈希表中的條目數超出了加載因子與當前容量的乘積時，則要對該哈希表進行 rehash 操作（即重建內部數據結構），從而哈希表將具有大約兩倍的桶數。在Java編程語言中，加載因子默認值為0.75，默認哈希表元為101

　　hashMap出現線程不安全的原因：

　　HashMap的實現里沒有鎖的機制，因此它是線程不安全的。其實只要有鎖的機制，可以通過鎖實現線程安全，我們在讀寫HashMap對象的時候加鎖，以保障這個對象的線程安全，但不代表HashMap本身是線程安全的，因為是外力（你自己加的鎖）使然。為啥不在HashMap內部加鎖讓它變成線程安全？這樣會增加單線程訪問的資源消耗，即使沒有多線程訪問，也要每次檢查、加鎖、解鎖。實際上有線程安全的Map，Collections里面有個靜態方法可以返回一個線程安全版本的HashMappublic static 《K，V》 Map《K，V》 synchronizedMap（Map《K，V》 m） {

　　return new SynchronizedMap《K，V》（m）;

　　}

　　另外java5之后還提供了ConcurrentHashMap類，提供更高效的線程安全操作。

　　hashMap出現線程不安全的表現：

　　表現1：

　　多個線程同時操作一個hashmap就可能出現不安全的情況：

　　比如A B兩個線程（A線程獲數據 B線程存數據） 同時操作myHashMap

　　1.B線程執行存放數據

　　modelHashMap.put（“1”，“2”）;

　　2.A線程執行get獲取數據

　　modelHashMap.get（“1”）

　　A線程獲取的值本來應該是2，但是如果A線程在剛到達獲取的動作還沒執行的時候，

　　線程執行的機會又跳到線程B，此時線程B又對modelHashMap賦值 如：modelHashMap.put（“1”，“3”）;

　　然后線程虛擬機又執行線程A，A取到的值為3，這樣map中第一個存放的值 就會丟失。。。。。

　　要保證值的準確，就要保證操作的原子性，就是保證A操作從頭開始不能被打斷。。所有要用同步關鍵字，或者使用java 1.5中的current新包中的ConcurrentHashMap，這是線程安全的，在java最新的并發包中，對之前非線程安全的工具，如hashMap List 都做了同步封轉。

　　表現2：

　　一般我們聲明HashMap時，使用的都是默認的構造方法：HashMap《K，V》，看了代碼你會發現，它還有其它的構造方法：HashMap（int initialCapacity， float loadFactor），其中參數initialCapacity為初始容量，loadFactor為加載因子，而之前我們看到的threshold = （int）（capacity * loadFactor）; 如果在默認情況下，一個HashMap的容量為16，加載因子為0.75，那么閥值就是12，所以在往HashMap中put的值到達12時，它將自動擴容兩倍，如果兩個線程同時遇到HashMap的大小達到12的倍數時，就很有可能會出現在將oldTable轉移到newTable的過程中遇到問題，從而導致最終的HashMap的值存儲異常。

　　表現3：

　　構造entry《K，V》單鏈表時，也會出現不安全的情況。