HashMap原理及詳解
一、定義
HashMap實現了Map介面，繼承AbstractMap。其中Map介面定義了鍵對映到值的規則，而AbstractMap類提供 Map 介面的骨幹實現，以最大限度地減少實現此介面所需的工作，其實AbstractMap類已經實現了Map，這裡標註Map LZ覺得應該是更加清晰吧！
</pre><pre name="code" class="java">public class HashMap<K,V>
extends AbstractMap<K,V>
implements Map<K,V>, Cloneable, Serializable二、建構函式
HashMap提供了三個建構函式：
HashMap()：構造一個具有預設初始容量 (16) 和預設載入因子 (0.75) 的空 HashMap。
HashMap(int initialCapacity)：構造一個帶指定初始容量和預設載入因子 (0.75) 的空 HashMap。
HashMap(int initialCapacity, float loadFactor)：構造一個帶指定初始容量和載入因子的空 HashMap。
在這裡提到了兩個引數：初始容量，載入因子。這兩個引數是影響HashMap效能的重要引數，其中容量表示雜湊表中桶的數量，初始容量是建立雜湊表時的容量，載入因子是雜湊表在其容量自動增加之前可以達到多滿的一種尺度，它衡量的是一個散列表的空間的使用程度，負載因子越大表示散列表的裝填程度越高，反之愈小。對於使用連結串列法的散列表來說，查詢一個元素的平均時間是O(1+a)，因此如果負載因子越大，對空間的利用更充分，然而後果是查詢效率的降低；如果負載因子太小，那麼散列表的資料將過於稀疏，對空間造成嚴重浪費。系統預設負載因子為0.75，一般情況下我們是無需修改的。
HashMap是一種支援快速存取的資料結構，要了解它的效能必須要了解它的資料結構。
三、資料結構
我們知道在Java中最常用的兩種結構是陣列和模擬指標(引用)，幾乎所有的資料結構都可以利用這兩種來組合實現，HashMap也是如此。實際上HashMap是一個“連結串列雜湊”，如下是它資料結構：
從上圖我們可以看出HashMap底層實現還是陣列，只是陣列的每一項都是一條鏈。其中引數initialCapacity就代表了該陣列的長度。下面為HashMap建構函式的原始碼：
public HashMap(int initialCapacity, float loadFactor) {
//初始容量不能<0
if (initialCapacity < 0)
throw new IllegalArgumentException("Illegal initial capacity: "
+ initialCapacity);
//初始容量不能 > 最大容量值，HashMap的最大容量值為2^30
if (initialCapacity > MAXIMUM_CAPACITY)
initialCapacity = MAXIMUM_CAPACITY;
//負載因子不能 < 0
if (loadFactor <= 0 || Float.isNaN(loadFactor))
throw new IllegalArgumentException("Illegal load factor: "
+ loadFactor);
// 計算出大於 initialCapacity 的最小的 2 的 n 次方值。
int capacity = 1;
while (capacity < initialCapacity)
capacity <<= 1;
this.loadFactor = loadFactor;
//設定HashMap的容量極限，當HashMap的容量達到該極限時就會進行擴容操作
threshold = (int) (capacity * loadFactor);
//初始化table陣列
table = new Entry[capacity];
init();
}從原始碼中可以看出，每次新建一個HashMap時，都會初始化一個table陣列。table陣列的元素為Entry節點。
static class Entry<K,V> implements Map.Entry<K,V> {
final K key;
V value;
Entry<K,V> next;
final int hash;
/**
* Creates new entry.
*/
Entry(int h, K k, V v, Entry<K,V> n) {
value = v;
next = n;
key = k;
hash = h;
}
.......
}其中Entry為HashMap的內部類，它包含了鍵key、值value、下一個節點next，以及hash值，這是非常重要的，正是由於Entry才構成了table陣列的項為連結串列。
上面簡單分析了HashMap的資料結構，下面將探討HashMap是如何實現快速存取的。
四、儲存實現：put(key,vlaue)
首先我們先看原始碼
public V put(K key, V value) {
//當key為null，呼叫putForNullKey方法，儲存null與table第一個位置中，這是HashMap允許為null的原因
if (key == null)
return putForNullKey(value);
//計算key的hash值
int hash = hash(key.hashCode()); ------(1)
//計算key hash 值在 table 陣列中的位置
int i = indexFor(hash, table.length); ------(2)
//從i出開始迭代 e,找到 key 儲存的位置
for (Entry<K, V> e = table[i]; e != null; e = e.next) {
Object k;
//判斷該條鏈上是否有hash值相同的(key相同)
//若存在相同，則直接覆蓋value，返回舊value
if (e.hash == hash && ((k = e.key) == key || key.equals(k))) {
V oldValue = e.value; //舊值 = 新值
e.value = value;
e.recordAccess(this);
return oldValue; //返回舊值
}
}
//修改次數增加1
modCount++;
//將key、value新增至i位置處
addEntry(hash, key, value, i);
return null;
}通過原始碼我們可以清晰看到HashMap儲存資料的過程為：首先判斷key是否為null，若為null，則直接呼叫putForNullKey方法。若不為空則先計算key的hash值，然後根據hash值搜尋在table陣列中的索引位置，如果table陣列在該位置處有元素，則通過比較是否存在相同的key，若存在則覆蓋原來key的value，否則將該元素儲存在鏈頭（最先儲存的元素放在鏈尾）。若table在該處沒有元素，則直接儲存。這個過程看似比較簡單，其實深有內幕。有如下幾點：
1、 先看迭代處。此處迭代原因就是為了防止存在相同的key值，若發現兩個hash值（key）相同時，HashMap的處理方式是用新value替換舊value，這裡並沒有處理key，這就解釋了HashMap中沒有兩個相同的key。
2、 在看（1）、（2）處。這裡是HashMap的精華所在。首先是hash方法，該方法為一個純粹的數學計算，就是計算h的hash值。
static int hash(int h) {
h ^= (h >>> 20) ^ (h >>> 12);
return h ^ (h >>> 7) ^ (h >>> 4);
}我們知道對於HashMap的table而言，資料分佈需要均勻（最好每項都只有一個元素，這樣就可以直接找到），不能太緊也不能太鬆，太緊會導致查詢速度慢，太鬆則浪費空間。計算hash值後，怎麼才能保證table元素分佈均與呢？我們會想到取模，但是由於取模的消耗較大，HashMap是這樣處理的：呼叫indexFor方法。
static int indexFor(int h, int length) {
return h & (length-1);
}HashMap的底層陣列長度總是2的n次方，在建構函式中存在：capacity <<= 1;這樣做總是能夠保證HashMap的底層陣列長度為2的n次方。當length為2的n次方時，h&(length - 1)就相當於對length取模，而且速度比直接取模快得多，這是HashMap在速度上的一個優化。至於為什麼是2的n次方下面解釋。
我們回到indexFor方法，該方法僅有一條語句：h&(length - 1)，這句話除了上面的取模運算外還有一個非常重要的責任：均勻分佈table資料和充分利用空間。
這裡我們假設length為16(2^n)和15，h為5、6、7。
當n=15時，6和7的結果一樣，這樣表示他們在table儲存的位置是相同的，也就是產生了碰撞，6、7就會在一個位置形成連結串列，這樣就會導致查詢速度降低。誠然這裡只分析三個數字不是很多，那麼我們就看0-15。
從上面的圖表中我們看到總共發生了8此碰撞，同時發現浪費的空間非常大，有1、3、5、7、9、11、13、15處沒有記錄，也就是沒有存放資料。這是因為他們在與14進行&運算時，得到的結果最後一位永遠都是0，即0001、0011、0101、0111、1001、1011、1101、1111位置處是不可能儲存資料的，空間減少，進一步增加碰撞機率，這樣就會導致查詢速度慢。而當length = 16時，length – 1 = 15 即1111，那麼進行低位&運算時，值總是與原來hash值相同，而進行高位運算時，其值等於其低位值。所以說當length = 2^n時，不同的hash值發生碰撞的概率比較小，這樣就會使得資料在table陣列中分佈較均勻，查詢速度也較快。
這裡我們再來複習put的流程：當我們想一個HashMap中新增一對key-value時，系統首先會計算key的hash值，然後根據hash值確認在table中儲存的位置。若該位置沒有元素，則直接插入。否則迭代該處元素連結串列並依此比較其key的hash值。如果兩個hash值相等且key值相等(e.hash == hash && ((k = e.key) == key
|| key.equals(k))),則用新的Entry的value覆蓋原來節點的value。如果兩個hash值相等但key值不等 ，則將該節點插入該連結串列的鏈頭。具體的實現過程見addEntry方法，如下：
void addEntry(int hash, K key, V value, int bucketIndex) {
//獲取bucketIndex處的Entry
Entry<K, V> e = table[bucketIndex];
//將新建立的 Entry 放入 bucketIndex 索引處，並讓新的 Entry 指向原來的 Entry
table[bucketIndex] = new Entry<K, V>(hash, key, value, e);
//若HashMap中元素的個數超過極限了，則容量擴大兩倍
if (size++ >= threshold)
resize(2 * table.length);
}這個方法中有兩點需要注意：
一是鏈的產生。這是一個非常優雅的設計。系統總是將新的Entry物件新增到bucketIndex處。如果bucketIndex處已經有了物件，那麼新新增的Entry物件將指向原有的Entry物件，形成一條Entry鏈，但是若bucketIndex處沒有Entry物件，也就是e==null,那麼新新增的Entry物件指向null，也就不會產生Entry鏈了。
二、擴容問題。
隨著HashMap中元素的數量越來越多，發生碰撞的概率就越來越大，所產生的連結串列長度就會越來越長，這樣勢必會影響HashMap的速度，為了保證HashMap的效率，系統必須要在某個臨界點進行擴容處理。該臨界點在當HashMap中元素的數量等於table陣列長度*載入因子。但是擴容是一個非常耗時的過程，因為它需要重新計算這些資料在新table陣列中的位置並進行復制處理。所以如果我們已經預知HashMap中元素的個數，那麼預設元素的個數能夠有效的提高HashMap的效能。
五、讀取實現：get(key)
相對於HashMap的存而言，取就顯得比較簡單了。通過key的hash值找到在table陣列中的索引處的Entry，然後返回該key對應的value即可。
public V get(Object key) {
// 若為null，呼叫getForNullKey方法返回相對應的value
if (key == null)
return getForNullKey();
// 根據該 key 的 hashCode 值計算它的 hash 碼
int hash = hash(key.hashCode());
// 取出 table 陣列中指定索引處的值
for (Entry<K, V> e = table[indexFor(hash, table.length)]; e != null; e = e.next) {
Object k;
//若搜尋的key與查詢的key相同，則返回相對應的value
if (e.hash == hash && ((k = e.key) == key || key.equals(k)))
return e.value;
}
return null;
}在這裡能夠根據key快速的取到value除了和HashMap的資料結構密不可分外，還和Entry有莫大的關係，在前面就提到過，HashMap在儲存過程中並沒有將key，value分開來儲存，而是當做一個整體key-value來處理的，這個整體就是Entry物件。同時value也只相當於key的附屬而已。在儲存的過程中，系統根據key的hashcode來決定Entry在table陣列中的儲存位置，在取的過程中同樣根據key的hashcode取出相對應的Entry物件。
轉自：http://blog.csdn.net/chenssy/article/details/18323767