標籤:blog add tor 不同 dfa 數組 存在 resize nbsp
Hash表資料結構
HashMap通常會用一個指標數組(假設為table[])來做分散所有的key,當一個key被加入時,會通過Hash演算法通過key算出這個數組的下標i,然後就把這個<key, value>插到table[i]中,如果有兩個不同的key被算在了同一個i,那麼就叫衝突,又叫碰撞,這樣會在table[i]上形成一個鏈表。
我們知道,如果table[]的尺寸很小,比如只有2個,如果要放進10個keys的話,那麼碰撞非常頻繁,於是一個O(1)的尋找演算法,就變成了鏈表遍曆,效能變成了O(n),這是Hash表的缺陷。
所以,Hash表的尺寸和容量非常的重要。一般來說,Hash表這個容器當有資料要插入時,都會檢查容量有沒有超過設定的loadFactor,如果超過,需要增大Hash表的尺寸,但是這樣一來,整個Hash表裡的無素都需要被重算一遍。這叫rehash,這個成本相當的大。
HashMap的rehash原始碼
Put一個Key,Value對到Hash表中:
public V put(K key, V value){ ...... //算Hash值 int hash = hash(key.hashCode()); int i = indexFor(hash, table.length); //如果該key已被插入,則替換掉舊的value (連結操作) for (Entry<K,V> e = table[i]; e != null; e = e.next) { Object k; if (e.hash == hash && ((k = e.key) == key || key.equals(k))) { V oldValue = e.value; e.value = value; e.recordAccess(this); return oldValue; } } modCount++; //該key不存在,需要增加一個結點 addEntry(hash, key, value, i); return null;}
檢查容量是否超標
void addEntry(int hash, K key, V value, int bucketIndex){ Entry<K,V> e = table[bucketIndex]; table[bucketIndex] = new Entry<K,V>(hash, key, value, e); //查看當前的size是否超過了我們設定的閾值threshold,如果超過,需要resize if (size++ >= threshold) resize(2 * table.length);}
建立一個更大尺寸的hash表,然後把資料從老的Hash表中遷移到新的Hash表中。
void resize(int newCapacity){ Entry[] oldTable = table; int oldCapacity = oldTable.length; ...... //建立一個新的Hash Table Entry[] newTable = new Entry[newCapacity]; //將Old Hash Table上的資料移轉到New Hash Table上 transfer(newTable); table = newTable; threshold = (int)(newCapacity * loadFactor);}
遷移的原始碼,注意高亮處:
void transfer(Entry[] newTable){ Entry[] src = table; int newCapacity = newTable.length; //下面這段代碼的意思是: // 從OldTable裡摘一個元素出來,然後放到NewTable中 for (int j = 0; j < src.length; j++) { Entry<K,V> e = src[j]; if (e != null) { src[j] = null; do { Entry<K,V> next = e.next; int i = indexFor(e.hash, newCapacity); e.next = newTable[i]; newTable[i] = e; e = next; } while (e != null); } }}
好了,這個代碼算是比較正常的。而且沒有什麼問題。
正常的ReHash的過程
畫了個圖做了個示範。
- 我假設了我們的hash演算法就是簡單的用key mod 一下表的大小(也就是數組的長度)。
- 最上面的是old hash 表,其中的Hash表的size=2, 所以key = 3, 7, 5,在mod 2以後都衝突在table[1]這裡了。
- 接下來的三個步驟是Hash表 resize成4,然後所有的<key,value> 重新rehash的過程
並發下的Rehash
1)假設我們有兩個線程。我用紅色和淺藍色標註了一下。
我們再回頭看一下我們的 transfer代碼中的這個細節:
do { Entry<K,V> next = e.next; // <--假設線程一執行到這裡就被調度掛起了 int i = indexFor(e.hash, newCapacity); e.next = newTable[i]; newTable[i] = e; e = next;} while (e != null);
而我們的線程二執行完成了。於是我們有下面的這個樣子。
注意,因為Thread1的 e 指向了key(3),而next指向了key(7),其線上程二rehash後,指向了線程二重組後的鏈表。我們可以看到鏈表的順序被反轉後。
2)線程一被調度回來執行。
- 先是執行 newTalbe[i] = e;
- 然後是e = next,導致了e指向了key(7),
- 而下一次迴圈的next = e.next導致了next指向了key(3)
3)一切安好。
線程一接著工作。把key(7)摘下來,放到newTable[i]的第一個,然後把e和next往下移。
4)環形連結出現。
e.next = newTable[i] 導致 key(3).next 指向了 key(7)
注意:此時的key(7).next 已經指向了key(3), 環形鏈表就這樣出現了。
於是,當我們的線程一調用到,HashTable.get(11)時,悲劇就出現了——Infinite Loop。
啦啦啦
JAVA HASHMAP的死迴圈