注：以下內容基於JDK1.8
使用HashMap疑惑點?
- 爲什麼使用HashMap插入效率高，查詢效率低
- Hash衝突及解決方案
- JDK8爲什麼要引入紅黑樹
- 擴容機制原理，相對於JDK1.7的改動
- 重寫equals方法爲什麼要重寫hashcode方法
- 線程是否安全，concurrentModificastionException出現場景及解決方案
- 使用HashMap需要注意的地方（小建議：如果提前知道要放入元素容量，可以在初始化hashMap的時候指定容量大小，避免產生擴容）
HashMap是什麼?
public class HashMap<K,V>
extends AbstractMap<K,V>
implements Map<K,V>, Cloneable, Serializable
基於哈希表的實現的Map接口。 此實現提供了所有可選集合操作，並允許null的值和null鍵。 （ HashMap類大致相當於Hashtable ，除了它是不同步的，並允許null）。這個類不能保證集合的順序。
HashMap特點
- 是基於Map接口
- 允許null值存在，鍵值也允許爲null，但最多一條，如果多條則返回最後插入的值
- 線程不安全，無序
- 底層的實現是數組+鏈表+紅黑樹實現
爲什麼使用HashMap插入效率高，查詢效率低
由於HashMap用到了鏈表的特點，所以插入速度快，鏈表元素在內存中是散列分佈的，不需要佔用連續的內存空間，通過next指向下一個元素，如果鏈表過長在查詢的時候就需要從頭結點開始找，所以查詢的效率低，所以JDK1.8引入了紅黑樹數據結構，解決了鏈表過長的問題，保證了插入效率的同時，也一定程度上提升了查詢效率。
Hash衝突及解決方案
哈希是通過對數據進行再壓縮，提高效率的一種解決方法。但由於通過哈希函數產生的哈希值是有限的，而數據可能比較多，導致經過哈希函數處理後仍然有不同的數據對應相同的哈希值。這時候就產生了哈希衝突。
解決hash衝突方法如下：
- 開發定址法：既然當前位置容不下衝突的元素了，那就再找一個空的位置存儲 Hash 衝突的值（當前 index 衝突了，那麼將衝突的元素放在 index+1)。
- 再散列法：換一個 Hash 算法再計算一個 hash 值，如果不衝突了就存儲值（例如第一個算法是名字的首字母的 Hash 值，如果衝突了，計算名字的第二個字母的 Hash 值，如果衝突解決了則將值放入數組中）。
-
鏈地址法：每個數組中都存有一個單鏈表，發生 Hash 衝突時，只是將衝突的 value 當作新節點插入到鏈表（HashMap 解決衝突的辦法）。
-
公共溢出區法：將衝突的 value 都存到另外一個順序表中，查找時如果當前表沒有對應值，則去溢出區進行順序查找。（HashMap使用的是鏈地址法來處理hash衝突）
JDK8爲什麼要引入紅黑樹
當發生hash衝突時，hashmap會將元素插入至鏈表的最後一位，形成單鏈表。而對於單鏈表，每當查找該位置元素時，都需要從頭到尾遍歷鏈表，然後逐一對比。由於我們在使用HashMap過程中，肯定不只是使用插入(put)功能，相對應的查詢也很多，所以引入了紅黑樹數據結構（紅黑樹的操作效率是中和了鏈表和平衡二叉樹這兩個數據結構的特性，保證插入效率的同時提升查詢效率）
擴容機制原理，相對於JDK1.7的改動
- JDK1.7擴容機制：
Hashmap的擴容需要滿足兩個條件：當前數據存儲的數量（即size()）大小必須大於等於閾值；當前加入的數據是否發生了hash衝突。
因爲上面這兩個條件，所以存在下面這些情況
（1）hashmap在存值的時（默認大小爲16，負載因子0.75，閾值12），可能達到最後存滿16個值的時候，再存入第17個值纔會發生擴容現象，因爲前16個值，每個值在底層數組中分別佔據一個位置，並沒有發生hash碰撞。
（2）當然也有可能存儲更多值（超多16個值，最多可以存26個值）都還沒有擴容。原理：前11個值全部hash碰撞，存到數組的同一個位置（這時元素個數小於閾值12，不會擴容），後面所有存入的15個值全部分散到數組剩下的15個位置（這時元素個數大於等於閾值，但是每次存入的元素並沒有發生hash碰撞，所以不會擴容），前面11+15=26，所以在存入第27個值的時候才同時滿足上面兩個條件，這時候纔會發生擴容現象。
源碼中在addEntry(int hash,K key, V value,int bucketIndex)方法中進行擴容操作
void addEntry(int hash, K key, V value, int bucketIndex) {
//1、判斷當前個數是否大於等於閾值
// 大小爲16，負載因子0.75，閾值12（大小（16）*負載因子）
//2、當前存放是否發生哈希碰撞
//如果上面兩個條件否發生，那麼就擴容
if ((size >= threshold) && (null != table[bucketIndex])) {
//擴容，並且把原來數組中的元素重新放到新數組中
resize(2 * table.length);
hash = (null != key) ? hash(key) : 0;
bucketIndex = indexFor(hash, table.length);
}
createEntry(hash, key, value, bucketIndex);
}
如果滿足條件需要擴容，會調用resize()方法進行擴容，以下是resize源碼片段
void resize(int newCapacity) {
Entry[] oldTable = table;
int oldCapacity = oldTable.length;
//判斷是否有超出擴容的最大值，如果達到最大值則不進行擴容操作
if (oldCapacity == MAXIMUM_CAPACITY) {
threshold = Integer.MAX_VALUE;
return;
}
Entry[] newTable = new Entry[newCapacity];
// transfer()方法把原數組中的值放到新數組中
transfer(newTable, initHashSeedAsNeeded(newCapacity));
//設置hashmap擴容後爲新的數組引用
table = newTable;
//設置hashmap擴容新的閾值
threshold = (int)Math.min(newCapacity * loadFactor, MAXIMUM_CAPACITY + 1);
}
transfer()在實際擴容時候把原來數組中的元素放入新的數組中
void transfer(Entry[] newTable, boolean rehash) {
int newCapacity = newTable.length;
for (Entry<K,V> e : table) {
while(null != e) {
Entry<K,V> next = e.next;
if (rehash) {
e.hash = null == e.key ? 0 : hash(e.key);
}
//通過key值的hash值和新數組的大小算出在當前數組中的存放位置
int i = indexFor(e.hash, newCapacity);
e.next = newTable[i];
newTable[i] = e;
e = next;
}
}
}
JDK1.7擴容機制會有死鎖問題......自行查資料，這裏不做講解
- JDK1.8優化點：
1.使用數組+鏈表+紅黑樹
轉換成紅黑樹條件
（根據屬性TREEIFY_THRESHOLD判斷是否要轉成紅黑樹，默認值是8，如果大於8就轉成紅黑樹結構，
根據UNTREEIFY_THRESHOLD屬性判斷是否要從紅黑樹轉成鏈表結構，默認是6，如果小於等於6就轉成鏈表結構 ）
以下是這兩個閾值的源碼定義：
/**
* The bin count threshold for using a tree rather than list for a
* bin. Bins are converted to trees when adding an element to a
* bin with at least this many nodes. The value must be greater
* than 2 and should be at least 8 to mesh with assumptions in
* tree removal about conversion back to plain bins upon
* shrinkage.
*/
static final int TREEIFY_THRESHOLD = 8;
/**
* The bin count threshold for untreeifying a (split) bin during a
* resize operation. Should be less than TREEIFY_THRESHOLD, and at
* most 6 to mesh with shrinkage detection under removal.
*/
static final int UNTREEIFY_THRESHOLD = 6;
2.新節點再插入到鏈表時的順序不同（jdk1.7插在鏈表的頭部，jdk1.8插在鏈表的尾部）
3.hash算法進行了優化
4.擴容機制進行了優化（解決了jdk1.7的死鎖問題）
重寫equals方法爲什麼要重寫hashcode方法
當此方法被重寫時，通常有必要重寫 hashCode 方法，以維護 hashCode 方法的常規協定，該協定聲明相等對象必須具有相等的哈希碼。如下：
(1)當obj1.equals(obj2)爲true時，obj1.hashCode() == obj2.hashCode()必須爲true
(2)當obj1.hashCode() == obj2.hashCode()爲false時，obj1.equals(obj2)必須爲false
如果不重寫equals，那麼比較的將是對象的引用是否指向同一塊內存地址，重寫之後目的是爲了比較兩個對象的value值是否相等。特別指出利用equals比較八大包裝對象（如int，float等）和String類（因爲該類已重寫了equals和hashcode方法）對象時，默認比較的是值，在比較其它自定義對象時都是比較的引用地址。
hashcode是用於散列數據的快速存取，如利用HashSet/HashMap/Hashtable類來存儲數據時，都是根據存儲對象的hashcode值來進行判斷是否相同的。
這樣如果我們對一個對象重寫了equals，意思是隻要對象的成員變量值都相等那麼equals就等於true，但不重寫hashcode，那麼我們再new一個新的對象，當原對象.equals（新對象）等於true時，兩者的hashcode卻是不一樣的，由此將產生了理解的不一致，如在存儲散列集合時（如Set類），將會存儲了兩個值一樣的對象，導致混淆，因此，就也需要重寫hashcode()。
線程是否安全，concurrentModificastionException出現場景及解決方案
- 不是線程安全的
- concurrentModificastionException異常，首先分析導致原因
是由於hashMap中的modCount屬性（hashMap再結構上被修改的次數）和迭代器的expectedModCount屬性值不相等導致的，注:結構修改是指改變映射的數量（如put，remove操作）
final Node<K,V> nextNode() {
Node<K,V>[] t;
Node<K,V> e = next;
if (modCount != expectedModCount)
throw new ConcurrentModificationException();
if (e == null)
throw new NoSuchElementException();
if ((next = (current = e).next) == null && (t = table) != null) {
do {} while (index < t.length && (next = t[index++]) == null);
}
return e;
}
由於HashMap不是線程安全的,所以在迭代的時候,會將modCount賦值到迭代器的expectedModCount屬性中,然後進行迭代，如果在迭代的過程中HashMap被其他線程修改了,modCount的數值就會發生變化,這個時候expectedModCount和ModCount不相等,迭代器就會拋出ConcurrentModificationException()異常，這種方式也叫快速失敗機制
解決方案：1，可以使用concurrentHashMap
2，使用Iterator迭代器的remove方法
public static void main(String[] args) {
HashMap<String,String> test = new HashMap<>();
test.put("bb","bb");
test.put("cc","cc");
Iterator<String> iterator = test.keySet().iterator();
while (iterator.hasNext()) {
String key = iterator.next();
if (key.equals("bb")){
//這裏使用iterator中的remove方法
iterator.remove();
}
}
}
//Iterator中remove方法代碼
public final void remove() {
Node<K,V> p = current;
if (p == null)
throw new IllegalStateException();
if (modCount != expectedModCount)
throw new ConcurrentModificationException();
current = null;
K key = p.key;
removeNode(hash(key), key, null, false, false);
//這裏會將expecteModCount賦值爲modCount，就不會導致多線程操作時某個線程查詢時兩個屬性值不相等了
expectedModCount = modCount;
}