前言:
我以前在百度的mentor, 在面試時特喜歡考察哈希表. 那時的我滿是疑惑和不解, 覺得這東西很基礎, 不就的分桶理念(以空間換時間)和散列函數選擇嗎? 最多再考察點沖突解決方案. 為何不考察類似跳躍表, LSM樹等高級數據結構呢?
隨着工程實踐的積累, 慢慢發現了自己當初的膚淺. 面試的切入點, 最好是大家所熟悉的, 但又能從中深度挖掘/剖析和具有區分度的.
本文結合自己的工程實踐, 來談談對哈希表的優化和實踐的一些理解.
基礎篇:
哈希表由一定大小的連續桶(bucket)構成, 借助散列函數映射到具體某個桶上. 當多個key/value對聚集到同一桶時, 會演化構成一個鏈表.
哈希表結構有兩個重要的參數, 容量大小(Capacity)和負載因子(LoadFactor). 兩者的乘積 Capacity * LoadFactor決定了哈希表rehash的觸發條件.
以空間換時間為核心思想, 確保其數據結構的訪問時間控制在O(1).
哈希表隱藏了內部細節, 而對外的使用則非常的簡單. 只需定義key的hash函數和compare函數即可.
以Java為例, 其把默認的hash函數和equals函數置於頂層的Object基類中.
class Object {
public native int hashCode();
public boolean equals(Object obj) {
return (this == obj);
}
}
所有的子類, 需要重載hashCode和equals就能方便的使用哈希表.
進階篇:
hash函數的選擇需保證一定散列度, 這樣才能充分利用空間. 事實上哈希表的使用者, 往往關注hash函數的快速計算和高散列度, 卻忽視了其潛在的風險和危機.
1). hash碰撞攻擊
前段時間, php爆出hash碰撞的攻擊漏洞. 其攻擊原理, 簡單可概括為: 特定的大量key組合, 讓哈希表退化為鏈表訪問, 進而拖慢處理速度, 請求堆積, 最終演變為拒絕服務狀態.
具體可參考博文: PHP哈希表碰撞攻擊原理.
大致的思路是利用php哈希表大小為2的冪次, 索引位置計算由 hash(key) % size(bucket) 轉變為 hash(key) & (1^n - 1).
黑客(hacker)知曉time33算法和hash函數, 可以構造/收集特定的key系列, 使得其hash(key)為同一桶索引值. 通過post請求附帶, 導致php構造超長鏈的哈希表.
其實如果能理解hash碰撞攻擊的原理, 說明其對hash的沖突處理和哈希表本身的數據結構模型有了較深的理解了.
2). 分段鎖機制
如果加鎖是不可避免的選擇, 那能否減少鎖沖突的概率呢?
答案是肯定的, 不同桶之間的key/value操作彼此互不影響. 在此前提下, 對哈希桶進行分段加鎖. 這樣全局鎖就退化為多個分段鎖, 而鎖沖突的概率由於分區的原因, 降低至1/N (N為分段鎖個數).
Java並發類中的ConcurrentHashMap也是采用類似的思想來實現, 不過比這復雜多了.
難度篇:
哈希表單key的操作復雜度為O(1), 性能異常優異. 但需要對哈希表進行迭代遍歷其所有元素時, 其性能就非常的差. 究其原因是各個key/value對分散在各個桶中, 彼此並無關聯. 元素遍歷轉化為對哈希桶的全掃描.
那如果存在這樣的需求, 既要保證O(1)的單key操作時間復雜度, 又要讓迭代遍歷的復雜度為O(n) (n為哈希表的key/value對個數, 不是桶個數), 那如何去實現呢?
1). LinkedHashMap&LRU緩存
是否存在一個復合數據結構, 既有Hashmap的特性, 又具備DoubleLinkedList線性遍歷的特征?
答案是肯定的, 該復合結構就是LinkedHashmap.
注: 依次添加key1, key2, ..., key6, 其按插入順序構成一個雙向列表.
一圖勝千言, 該圖很形象的描述了LinkedHashMap的構成. 可以這么認為: 每個hash entry的結構的基礎上, 添加prev和next成員指針用於維護雙向列表. 實現就這么簡單.
在工程實踐中, 往往采用LinkedHashMap的變體來實現帶LRU機制的Cache.
簡單描述其操作流程:
(1). 查詢/添加key, 則把該key/value對擱置於LRU隊列的末尾
(2). 若key/value對個數超過閾值時, 則選擇把LRU隊列的首元素淘汰掉.
模擬key5元素被查詢訪問, 成為最近的熱點, 則內部的鏈接模型狀態轉變如下:
注: key5被訪問后, 內部雙向隊列發生變動, 可以理解為刪除key5, 然后再添加key5至末尾.
JAVA實現帶LRU機制的Cache非常的簡單, 用如下代碼片段描述下:
public class LRULinkedHashMap<K, V> extends LinkedHashMap<K, V> {
private int capacity = 1024;
public LRULinkedHashMap(int initialCapacity, float loadFactor, int lruCapacity) {
// access order=> true:訪問順序, false:插入順序
super(initialCapacity, loadFactor, true);
this.capacity = lruCapacity;
}
@Override
protected boolean removeEldestEntry(Entry<K, V> eldest) {
if(size() > capacity) {
return true;
}
return false;
}
}
注: 需要注意access order為true, 表示按訪問順序維護. 使用Java編程的孩子真幸福.
當哈希表中的元素數量超過預定的閾值時, 就會觸發rehash過程. 但是若此時的hash表已然很大, rehash的完整過程會阻塞服務很長時間. 這對高可用高響應的服務是不可想象的災難.
面對這種情況, 要么避免大數據量的rehash出現, 預先對數據規模進行有效評估. 要么就繼續優化哈希的rehash過程.
2). 0/1切換和漸進式rehash
redis的設計者給出了一個很好的解決方案, 就是0/1切換hash表+漸進式rehash.
其漸進的rehash把整個遷移過程拆分為多個細粒度的子過程, 同時0/1切換的hash表共存.
redis的rehash過程分兩種方式:
• lazy rehashing: 在對dict操作的時候附帶執行一個slot的rehash
• active rehashing：定時做個小時間片的rehash
總結:
哈希表作為常用的數據結構, 被人所熟知. 但對其進一步的理解和挖掘, 需要真正的工程實踐積累. 洗盡鉛華始見真.
寫在最后：
如果你覺得這篇文章對你有幫助, 請小小打賞下. 其實我想試試, 看看寫博客能否給自己帶來一點小小的收益. 無論多少, 都是對樓主一種由衷的肯定.
