default_initial_capacity：初始化容量，**中為1 << 4 ，即為16。（為什麼要這樣寫呢？）
maximum_capacity：最大容量，**中衛1 << 30 ，即為2的30次冪。
30次冪的原因是：改屬性為int型別，int型別最大為4個位元組，共32個二進位制位，理論上可以向左移動31次，即31次冪，但是由於第一位應為識別符號號的正負位，所以最大為30次冪。選擇int而不選擇long和byte是為了效能的折中考慮。
default_load_factor：預設載入因子,0.75
empty_table：乙個空表（暫時沒發現有什麼用）
table：相比於empty_table多了transient，不用序列化
size：hashmap的大小
threshold：當hashmap的size大於該值時，就會進行擴容處理。大小為capacity * load factor
loadfactor：裝載因子
modcount：用於記錄hashmap的修改次數。put和get方法，以及迭代器中都會引入該值。由於hashmap不是執行緒安全的,所以在迭代的時，會將modcount賦值到迭代器的expectedmodcount屬性中，後進行迭代，如果在迭代的過程中hashmap被其他執行緒修改了，modcount的數值就會發生變化,這個時候expectedmodcount和modcount不相等，迭代器就會丟擲concurrentmodificationexception()異常。
alternative_hashing_threshold_default：乙個閾值，預設值為integer.max_value，當乙個鍵值對的鍵是string型別時，且map的容量達到了這個閾值，就啟用備用雜湊（alternative hashing）。備用雜湊可以減少string型別的key計算雜湊碼（更容易）發生雜湊碰撞的發生率。
內部類holder：已在jdk1.8中刪除，為了方便所有依賴都進行載入
hashseed：初始值為0，雜湊種子，用於降低key的hash碰撞概率，如果為0則禁用備用雜湊演算法
public hashmap(int initialcapacity, float loadfactor)：指定初始容量及載入因子
public hashmap(int initialcapacity)：指定初始容量，載入因子預設
public hashmap()：載入因子和初始容量都預設
public hashmap(map<? extends k, ? extends v> m)：根據已有的map介面建立乙個元素相同的hashmap
//to-do
JDK1 7的HashMap死迴圈
為什麼在jdk1.7多執行緒情況下會很容易出現hashmap死迴圈，這個還是要根據它採取的擴容策略來看，它的擴容策略是頭插法，因此會導致這樣的問題。在jdk1.8改進為尾插法，但並不意味著尾插法能適應多執行緒併發的場景，我認為其最主要的考慮就是頭插法在正常情況下是與原來鍊錶順序相逆的，而尾插不會改變...
JDK1 7和JDK1 8HashMap的區別
jdk1.7與jdk1.8中hashmap區別 最重要的一點是底層結構不一樣，1.7是陣列 鍊錶，1.8則是陣列 鍊錶 紅黑樹結構 jdk1.7中當雜湊表為空時，會先呼叫inflatetable 初始化乙個陣列 而1.8則是直接呼叫resize 擴容 插入鍵值對的put方法的區別，1.8中會將節點插...
JDK1 8中的hashmap和JDK1 7的區別
1.資料插入的方式不同 jdk1.7用的是頭插法，而jdk1.8用的是尾插法，這是由於jdk1.7是用單鏈表進行的縱向延伸，當採用頭插法時會容易出現逆序且環形鍊錶死迴圈問題。但是在jdk1.8之後是因為加入了紅黑樹使用尾插法，能夠避免出現逆序且鍊錶死迴圈的問題。2.組成結構不同 jdk1.7的時候使...