天天看點

HashMap 實作原理(複習)

1. HashMap的資料結構

資料結構中有數組和連結清單來實作對資料的存儲,但這兩者基本上是兩個極端。

    數組

數組存儲區間是連續的,占用記憶體嚴重,故空間複雜的很大。但數組的二分查找時間複雜度小,為O(1);數組的特點是:尋址容易,插入和删除困難;

連結清單

連結清單存儲區間離散,占用記憶體比較寬松,故空間複雜度很小,但時間複雜度很大,達O(N)。連結清單的特點是:尋址困難,插入和删除容易。

哈希表

那麼我們能不能綜合兩者的特性,做出一種尋址容易,插入删除也容易的資料結構?答案是肯定的,這就是我們要提起的哈希表。哈希表((Hash table)既滿足了資料的查找友善,同時不占用太多的内容空間,使用也十分友善。

  哈希表有多種不同的實作方法,我接下來解釋的是最常用的一種方法—— 拉鍊法,我們可以了解為“連結清單的數組” ,如圖:

HashMap 實作原理(複習)
HashMap 實作原理(複習)

  從上圖我們可以發現哈希表是由數組+連結清單組成的,一個長度為16的數組中,每個元素存儲的是一個連結清單的頭結點。那麼這些元素是按照什麼樣的規則存儲到數組中呢。一般情況是通過hash(key)%len獲得,也就是元素的key的哈希值對數組長度取模得到。比如上述哈希表中,12%16=12,28%16=12,108%16=12,140%16=12。是以12、28、108以及140都存儲在數組下标為12的位置。

  HashMap其實也是一個線性的數組實作的,是以可以了解為其存儲資料的容器就是一個線性數組。這可能讓我們很不解,一個線性的數組怎麼實作按鍵值對來存取資料呢?這裡HashMap有做一些處理。

  首先HashMap裡面實作一個靜态内部類Entry,其重要的屬性有 key , value, next,從屬性key,value我們就能很明顯的看出來Entry就是HashMap鍵值對實作的一個基礎bean,我們上面說到HashMap的基礎就是一個線性數組,這個數組就是Entry[],Map裡面的内容都儲存在Entry[]裡面。

    /**

     * The table, resized as necessary. Length MUST Always be a power of two.

     */

    transient Entry[] table;

2. HashMap的存取實作

     既然是線性數組,為什麼能随機存取?這裡HashMap用了一個小算法,大緻是這樣實作:

// 存儲時:

int hash = key.hashCode(); // 這個hashCode方法這裡不詳述,隻要了解每個key的hash是一個固定的int值

int index = hash % Entry[].length;

Entry[index] = value;

// 取值時:

int hash = key.hashCode();

return Entry[index];

1)put

疑問:如果兩個key通過hash%Entry[].length得到的index相同,會不會有覆寫的危險?

  這裡HashMap裡面用到鍊式資料結構的一個概念。上面我們提到過Entry類裡面有一個next屬性,作用是指向下一個Entry。打個比方, 第一個鍵值對A進來,通過計算其key的hash得到的index=0,記做:Entry[0] = A。一會後又進來一個鍵值對B,通過計算其index也等于0,現在怎麼辦?HashMap會這樣做:B.next = A,Entry[0] = B,如果又進來C,index也等于0,那麼C.next = B,Entry[0] = C;這樣我們發現index=0的地方其實存取了A,B,C三個鍵值對,他們通過next這個屬性連結在一起。是以疑問不用擔心。也就是說數組中存儲的是最後插入的元素。到這裡為止,HashMap的大緻實作,我們應該已經清楚了。

 public V put(K key, V value) {

        if (key == null)

            return putForNullKey(value); //null總是放在數組的第一個連結清單中

        int hash = hash(key.hashCode());

        int i = indexFor(hash, table.length);

        //周遊連結清單

        for (Entry<K,V> e = table[i]; e != null; e = e.next) {

            Object k;

            //如果key在連結清單中已存在,則替換為新value

            if (e.hash == hash && ((k = e.key) == key || key.equals(k))) {

                V oldValue = e.value;

                e.value = value;

                e.recordAccess(this);

                return oldValue;

            }

        }

        modCount++;

        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); //參數e, 是Entry.next

    //如果size超過threshold,則擴充table大小。再散列

    if (size++ >= threshold)

            resize(2 * table.length);

}

  當然HashMap裡面也包含一些優化方面的實作,這裡也說一下。比如:Entry[]的長度一定後,随着map裡面資料的越來越長,這樣同一個index的鍊就會很長,會不會影響性能?HashMap裡面設定一個因子,随着map的size越來越大,Entry[]會以一定的規則加長長度。

2)get

 public V get(Object key) {

            return getForNullKey();

        //先定位到數組元素,再周遊該元素處的連結清單

        for (Entry<K,V> e = table[indexFor(hash, table.length)];

             e != null;

             e = e.next) {

            if (e.hash == hash && ((k = e.key) == key || key.equals(k)))

                return e.value;

3)null key的存取

null key總是存放在Entry[]數組的第一個元素。

   private V putForNullKey(V value) {

        for (Entry<K,V> e = table[0]; e != null; e = e.next) {

            if (e.key == null) {

        addEntry(0, null, value, 0);

    private V getForNullKey() {

            if (e.key == null)

4)确定數組index:hashcode % table.length取模

HashMap存取時,都需要計算目前key應該對應Entry[]數組哪個元素,即計算數組下标;算法如下:

   /**

     * Returns index for hash code h.

    static int indexFor(int h, int length) {

        return h & (length-1);

按位取并,作用上相當于取模mod或者取餘%。

這意味着數組下标相同,并不表示hashCode相同。

5)table初始大小

  public HashMap(int initialCapacity, float loadFactor) {

        .....

        // Find a power of 2 >= initialCapacity

        int capacity = 1;

        while (capacity < initialCapacity)

            capacity <<= 1;

        this.loadFactor = loadFactor;

        threshold = (int)(capacity * loadFactor);

        table = new Entry[capacity];

        init();

注意table初始大小并不是構造函數中的initialCapacity!!

而是 >= initialCapacity的2的n次幂!!!!

————為什麼這麼設計呢?——

3. 解決hash沖突的辦法

  1. 開放定址法(線性探測再散列,二次探測再散列,僞随機探測再散列)
  2. 再哈希法
  3. 鍊位址法
  4. 建立一個公共溢出區

Java中hashmap的解決辦法就是采用的鍊位址法。

4. 再散列rehash過程

當哈希表的容量超過預設容量時,必須調整table的大小。當容量已經達到最大可能值時,那麼該方法就将容量調整到Integer.MAX_VALUE傳回,這時,需要建立一張新表,将原表的映射到新表中。

     * Rehashes the contents of this map into a new array with a

     * larger capacity.  This method is called automatically when the

     * number of keys in this map reaches its threshold.

     *

     * If current capacity is MAXIMUM_CAPACITY, this method does not

     * resize the map, but sets threshold to Integer.MAX_VALUE.

     * This has the effect of preventing future calls.

     * @param newCapacity the new capacity, MUST be a power of two;

     *        must be greater than current capacity unless current

     *        capacity is MAXIMUM_CAPACITY (in which case value

     *        is irrelevant).

    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(newTable);

        table = newTable;

        threshold = (int)(newCapacity * loadFactor);

     * Transfers all entries from current table to newTable.

    void transfer(Entry[] newTable) {

        Entry[] src = table;

        int newCapacity = newTable.length;

        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;

                    //重新計算index

                    int i = indexFor(e.hash, newCapacity);

                    e.next = newTable[i];

                    newTable[i] = e;

                    e = next;

                } while (e != null);

轉自:http://blog.csdn.net/leoleocmm/article/details/38294249