面試中的HashMap、ConcurrentHashMap和Hashtable，你知道多少？

時間  2021-08-13
標籤 html java node 面試 數組 安全 性能優化 markdown 數據結構 併發 欄目 快樂工作 简体版
原文   原文鏈接

前言

學過數據結構的讀者們想必其實也都學過HashMap，面試官問你的時候，想來你都是很清楚的知道HashMap是怎樣的一個構成？確實很簡單，就是數組加鏈表嘛。那再問你Hashtable和HashMap的區別是什麼？腦子也不用想，又能出來一個答案線程安全和線程不安全,Hashtable不容許存在空值唄。那繼續往深處問，HashMap是怎麼作性能優化的？這個時候你是怎麼樣的反應呢？若是知道紅黑樹，那就能答出來；不知道的話那不是就涼了，由於這個時候連ConcurrentHashMap都須要放棄回答了！！！html

部分圖片引自JDK1.7 HashMap 致使循環鏈表java

HashMap源碼導讀

其實思路大體都是相同的，因此這裏只分析一個HashMap，先貼出他的幾個常見用法。node

HashMap hashMap = new HashMap();
hashMap.put(key, value);
hashMap.get(key);
複製代碼

主要從這個方面對HashMap的整個工做流程進行分析。面試

HashMap()

public HashMap(int initialCapacity, float loadFactor) {
        if (initialCapacity < 0)
            throw new IllegalArgumentException("Illegal initial capacity: " +
                                               initialCapacity);
        // 對數組的一個保護，不能超過int最大值範圍
        if (initialCapacity > MAXIMUM_CAPACITY)
            initialCapacity = MAXIMUM_CAPACITY;
        if (loadFactor <= 0 || Float.isNaN(loadFactor))
            throw new IllegalArgumentException("Illegal load factor: " +
                                               loadFactor);
        this.loadFactor = loadFactor;
        this.threshold = tableSizeFor(initialCapacity);
    }

    public HashMap(int initialCapacity) {
        this(initialCapacity, DEFAULT_LOAD_FACTOR);
    }

    public HashMap() {
        this.loadFactor = DEFAULT_LOAD_FACTOR; // all other fields defaulted
    }

    public HashMap(Map<? extends K, ? extends V> m) {
        this.loadFactor = DEFAULT_LOAD_FACTOR;
        putMapEntries(m, false);
    }
複製代碼

其實在無參構造方法，咱們並無看到所謂的數組的初始化，他只對咱們的負載因子作了一個初始化，也就是咱們一直常說的0.75f,但爲何是0.75f呢，只能說是一個經驗值，也就是經驗所致，由於0.5f時空間太浪費，1f時容易出現極端狀況，固然也不是隨便定的，設計師確定是作了不少的測試的，但依舊是一個經驗值，或者說是測試後的最優解。數組

回到咱們以前的問題，既然咱們學習的時候學到過HashMap是一個數組+鏈表。那作第一個思考爲何初始化不見了？ 先帶着這樣的問題繼續啊往下走。安全

先看看本身動手初始化容量構造函數，最後都會調用下方的tableSizeFor()方法。性能優化

static final int tableSizeFor(int cap) {
        int n = cap - 1;
        n |= n >>> 1;
        n |= n >>> 2;
        n |= n >>> 4;
        n |= n >>> 8;
        n |= n >>> 16;
        return (n < 0) ? 1 : (n >= MAXIMUM_CAPACITY) ? MAXIMUM_CAPACITY : n + 1;
    }
複製代碼

本質意思就是把數值變成2的指數倍，這樣的好處是計算方便處理。可是出現一樣的問題，沒有初始化，這裏也只看到了容量。問題繼續保留。markdown

put(key, value)

public V put(K key, V value) {
        return putVal(hash(key), key, value, false, true); // 1
    }
// 由註釋1直接調用的方法putVal()
final V putVal(int hash, K key, V value, boolean onlyIfAbsent, boolean evict) {
        Node<K,V>[] tab; Node<K,V> p; int n, i;
        // 第一次來判斷的時候，顯然的tab是一個空，由於在構造函數中，咱們並無看到他的初始化，那麼必然要調用resize()方法。
        if ((tab = table) == null || (n = tab.length) == 0)
            n = (tab = resize()).length; // 2，未能初始化而必然調用的方法
        if ((p = tab[i = (n - 1) & hash]) == null)
            tab[i] = newNode(hash, key, value, null);
        else {
            Node<K,V> e; K k;
            if (p.hash == hash &&
                ((k = p.key) == key || (key != null && key.equals(k))))
                e = p;
            else if (p instanceof TreeNode)
                e = ((TreeNode<K,V>)p).putTreeVal(this, tab, hash, key, value);
            else {
                for (int binCount = 0; ; ++binCount) {
                    if ((e = p.next) == null) {
                        p.next = newNode(hash, key, value, null);
                        if (binCount >= TREEIFY_THRESHOLD - 1) // -1 for 1st
                            treeifyBin(tab, hash);
                        break;
                    }
                    if (e.hash == hash &&
                        ((k = e.key) == key || (key != null && key.equals(k))))
                        break;
                    p = e;
                }
            }
            if (e != null) { // existing mapping for key
                V oldValue = e.value;
                if (!onlyIfAbsent || oldValue == null)
                    e.value = value;
                afterNodeAccess(e);
                return oldValue;
            }
        }
        ++modCount;
        if (++size > threshold)
            resize(); // 2
        afterNodeInsertion(evict);
        return null;
    }
// 由註釋2直接調用的方法
// 由多種方法調用到這裏：
// 1. 還沒有初始化
// 2. 保存的數據超出 容量 * 負載因子
// 3. 數據被刪的不足以支持樹形的時候
final Node<K,V>[] resize() {
        Node<K,V>[] oldTab = table;
        int oldCap = (oldTab == null) ? 0 : oldTab.length;
        int oldThr = threshold;
        int newCap, newThr = 0;
        // 。。。。
        // 此處對容量大小作了一系列的斷定，爲定義初始化容量爲16
        // 。。。。
        if (newThr == 0) {
            float ft = (float)newCap * loadFactor;
            newThr = (newCap < MAXIMUM_CAPACITY && ft < (float)MAXIMUM_CAPACITY ?
                      (int)ft : Integer.MAX_VALUE);
        }
        threshold = newThr;
        // 進行了整個的table進行一個初始化
        // 而這個table就是一個Node的數組
        // Node也就是鏈表的一個個節點，讀者本身點進去觀察就能看到next節點
        @SuppressWarnings({"rawtypes","unchecked"})
        Node<K,V>[] newTab = (Node<K,V>[])new Node[newCap];
        table = newTab;
        // 。。。。。
    }
複製代碼

到這裏咱們就已經明白了，原來初始化的過程已經在這裏進行了定義，這也就解決了咱們的第一個問題了。可是隨之而來第二個問題，爲何要這樣設計呢？ 這裏給出我思考的一個答案，若是隻建立了，卻沒有進行使用呢？那至少就會佔去16個數據類型大小的內存，而這樣的建立方法，就是對內存的一種保護機制。數據結構

第三個問題，爲何要轉變成樹形（固然它是有好聽的名字的，叫作紅黑樹）？ 其實結構的轉換爲的不外乎幾種緣由效率問題、空間佔用問題。若是使用鏈表查詢，他的查詢速度是O(n) ，而紅黑樹的查詢速度是O(logn)。可是紅黑樹帶來的問題確實一個存儲容量的問題，做爲二叉樹，他須要同時保存左右節點，而單鏈表只有一個節點，那麼內存消耗的問題就出來了。樹的構造問題能講一篇博客，因此就再也不這裏講先了。併發

get(key)

public V get(Object key) {
        Node<K,V> e;
        return (e = getNode(hash(key), key)) == null ? null : e.value;
    }
複製代碼

經過hash值來尋找咱們對應的節點，那咱們就須要先來看看這個hash是怎麼計算的。

static final int hash(Object key) {
        int h;
        return (key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16);
    }
複製代碼

答案也是一目瞭然的，得到hashCode()值，而後進行於0000_0000_0000_0000b進行異或運算。其實就是爲了算出hashCode()的低16位。那咱們得到了hash值之後，就須要來找找咱們的節點了。

final Node<K,V> getNode(int hash, Object key) {
        Node<K,V>[] tab; Node<K,V> first, e; int n; K k;
        if ((tab = table) != null && (n = tab.length) > 0 &&
            (first = tab[(n - 1) & hash]) != null) {
            if (first.hash == hash && // always check first node
                ((k = first.key) == key || (key != null && key.equals(k))))
                return first;
            if ((e = first.next) != null) {
                if (first instanceof TreeNode)
                // 對樹形中的數據進行查找
                    return ((TreeNode<K,V>)first).getTreeNode(hash, key);
                // 對鏈表中的數據進行查找
                do {
                    if (e.hash == hash &&
                        ((k = e.key) == key || (key != null && key.equals(k))))
                        return e;
                } while ((e = e.next) != null);
            }
        }
        return null;
    }
複製代碼

而後獲取到咱們須要的數據，而後就返還給咱們了，哇哦！！原來總體就夠就是這麼簡單的。（其實真正寫起來不簡單，分析起來簡單一點罷了，嘿嘿。）

爲何hash要進行高低16的異或運算？

你是否有考慮過這樣的問題，可是卻可能頻頻發生在你的代碼中呢？

前提：key1和key2兩個值不一樣，但hashCode的高位不一樣，低位相同。

你能知道，通常在咱們的項目中，一個hashmap並不會開的過度誇張的大，可能咱們只用了32個（我項目裏最大好像也就到這兒了）。而我給出的範圍是16位數，32才只到達了5位，遠遠達不到要求，那麼這樣狀況的出現頻率也會異常的誇張。

因此Java工程師們也給出了本身的解決方案也就是高低位的異或運算，他有一個好聽的名字 —— 擾動函數。

運算其實本質上來講你能夠這樣認爲，就是讓其餘位上的二進制數們也可以加入到這場運算的盛宴中。通過這樣的運算，可能Key1最後的運算對象就從123A000變成了123A123A，而Key2就從BCD00000變到了BCD0BCD0，這樣他們與最後的0000000F的異或運算就與本來的結果就迥然不一樣了。

再來看看通過了擾動函數加工事後的衝突情況。

這是摘自專欄文章《An introduction to optimising a hashing strategy》裏的的一個實驗：他隨機選取了352個字符串，在他們散列值徹底沒有衝突的前提下，對它們作低位掩碼，取數組下標。

那麼這個時候咱們的一個HashMap長度爲512，掩碼取低9位時，衝突次數能從103次下降到92次，將近10%的效率提高。

固然會有讀者問，爲何很少進行幾回干擾？

確實屢次干擾可以帶來更好的效果，可是會出現一個問題，效率。計算機的一切出發點就是效率問題，一次的干擾可以帶來足夠好的收益時，是可以做爲折中方案被錄用的。

HashMap和Hashtable有什麼不一樣

既然咱們已經知道了整個的HashMap的構成，那主要要了解的對象就應該是Hashtable了。那咱們先來看看Hashtable的構造函數好了。

// 無參構造函數初始化，處理容量爲11，負載因子爲0，75
public Hashtable() {
        this(11, 0.75f);
    }
// 鏈表的建立在默認最後嗲用的構造函數中就已經建立
// 那這裏咱們就發現了第一個不一樣的地方。
public Hashtable(int initialCapacity, float loadFactor) {
        if (initialCapacity < 0)
            throw new IllegalArgumentException("Illegal Capacity: "+
                                               initialCapacity);
        if (loadFactor <= 0 || Float.isNaN(loadFactor))
            throw new IllegalArgumentException("Illegal Load: "+loadFactor);

        if (initialCapacity==0)
            initialCapacity = 1;
        this.loadFactor = loadFactor;
        table = new Entry<?,?>[initialCapacity];
        threshold = (int)Math.min(initialCapacity * loadFactor, MAX_ARRAY_SIZE + 1);
    }
複製代碼

文內寫了第一個不一樣點，可是還有一個不一樣點，你是否發現了？ 就是容量的問題，在HashMap中的容量計算所有都是往2的指數倍進行靠近的，可是Hashtable並無作出這樣的選擇，可是在負載因子上又出奇的一致。

再看看Hashtable的put(key, value)方法。

public synchronized V put(K key, V value) {
        // 判空機制的存在，和HashMap並沒有判空，也就允許null做爲key存在
        if (value == null) {
            throw new NullPointerException();
        }

        // Makes sure the key is not already in the hashtable.
        Entry<?,?> tab[] = table;
        int hash = key.hashCode();
        int index = (hash & 0x7FFFFFFF) % tab.length;
        @SuppressWarnings("unchecked")
        Entry<K,V> entry = (Entry<K,V>)tab[index];
        for(; entry != null ; entry = entry.next) {
            if ((entry.hash == hash) && entry.key.equals(key)) {
                V old = entry.value;
                entry.value = value;
                return old;
            }
        }

        addEntry(hash, key, value, index);
        return null;
    }
複製代碼

咱們常說Hashtable是一個線程安全的類，而這裏也給了咱們答案，他在方法上加了synchronized，也就是鎖的機制，來完成咱們的同步。可是思前想後，我都存在一個疑惑，大家是否看到了他的resize()函數呢？，沒錯，並不存在resize()函數。

那咱們繼續往下看看好了，由於在這個函數中還存在一個addEntry()方法，看看裏面是否是有擴容機制呢。

private void addEntry(int hash, K key, V value, int index) {
        modCount++;

        Entry<?,?> tab[] = table;
        if (count >= threshold) {
            // Rehash the table if the threshold is exceeded
            rehash();

            tab = table;
            hash = key.hashCode();
            index = (hash & 0x7FFFFFFF) % tab.length;
        }

        // Creates the new entry.
        @SuppressWarnings("unchecked")
        Entry<K,V> e = (Entry<K,V>) tab[index];
        tab[index] = new Entry<>(hash, key, value, e);
        count++;
    }
複製代碼

原來他改頭換面了，在addEntry()方法中，咱們發現他的重構函數是一個叫作rehash()的函數。而擴容機制和HashMap相同都是放大兩倍的操做來進行完成的。可是從效率上來說，由於一直數組+鏈表的形式存在，就算是沒有線程安全的機制，效率上來講整體仍是比HashMap差勁的。

ConcurrentHashMap就線程安全的性能優化

說到ConcurrentHashMap，其實他和HashMap同樣都是存在JDK1.8先後的版本差別的。

網上能夠查到不少關於version 1.8以前的機制，也就是分段鎖，能夠看作成多個Hashtable的組合。而version 1.8以後的機制，就是鎖槽了。遲點作一個詳細的解析。

既然是性能優化，那麼就應該有性能優化的點。

（1）和HashMap的實現方式同樣，數組+鏈表+紅黑樹，查找性能上優於Hashtable。前提： 使用的容量大於8。

（2）分段鎖機制 / 鎖槽機制：再也不是整個數組加鎖，而是對單條或者幾條鏈表和紅黑樹進行加鎖，也就同時可以就收多個不一樣的hash操做了。

由於我本地使用的JDK1.8，因此咱們就先研究一下JDK1.8的作法好了。

final V putVal(K key, V value, boolean onlyIfAbsent) {
        if (key == null || value == null) throw new NullPointerException();
        int hash = spread(key.hashCode());
        int binCount = 0;
        for (Node<K,V>[] tab = table;;) {
            Node<K,V> f; int n, i, fh;
            if (tab == null || (n = tab.length) == 0)
                //。。。。。
            }
            else if ((f = tabAt(tab, i = (n - 1) & hash)) == null) {
                // 引入了CAS機制
                if (casTabAt(tab, i, null,
                             new Node<K,V>(hash, key, value, null)))
                    break;                   // no lock when adding to empty bin
            }
            else if ((fh = f.hash) == MOVED)
                //。。。。。
            else {
                V oldVal = null;
                synchronized (f) {
                    // 。。。。。
                }
                //。。。。。
            }
        }
        addCount(1L, binCount);
        return null;
    }
複製代碼

須要關注的是加鎖對象synchronized (f)。對變量f表明就一個hash對應的一條鏈表，而加鎖正好加的是這條鏈表，或者這顆紅黑樹上，另外索引爲空時經過CAS的方式來建立一個新的節點。這也就是JDK 1.8引入的新機制CAS+鎖。

那咱們再看看JDK 1.7的作法是什麼樣的，就直接用一張圖來直觀感覺吧

version 1.7的時候根據Segment來給每一鏈配鎖，可是帶來的問題就是hash搜索時間變長。不過相較於Hashtable而言，性能上仍是更加出色的。由於分段鎖的機制也就不影響兩兩段之間並不會存在鎖的問題，也就提升了性能。

而相較於version 1.8來講，性能確是不足的，首先是引入了紅黑樹的緣由，第二Segment的維護其餘相較於如今是一個比較麻煩的過程。然後者調整爲單個Node進行一個調整，須要進行調整的範圍減少了，帶來了兩個好處，一是好管理，二是可同時操做的數量增長。

HashMap中的循環鏈

這是一個引伸的內容，一樣的分爲version 1.7和1.8。固然產生的緣由無非就是高併發的狀況下，單線程處理的狀況下怎麼可能發生這種狀況？？

先講講version 1.7的循環鏈問題，和產生和這個問題的緣由。

先讓咱們知道一下version 1.7的問題點在哪兒。

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;
                int i = indexFor(e.hash, newCapacity);
                e.next = newTable[i];
                newTable[i] = e;
                e = next;
            } while (e != null);
        }
    }
}
複製代碼

總體來講就一個頭插法的模式。

單線程狀況下

咱們說了是頭插法，你可以看到最明顯的地方就是7和3的位置互換。

高併發狀況下

步驟一：

線程1獲取到e = 3，且next = 7的時候被掛起，而線程2已經執行完畢，就會獲得下圖的結果。

步驟二：

那如今就是由線程1完成新的一份操做了，可是實際上總體數據已經修改，他手裏的數據是一份髒數據，他保持了以前的數據，而以前數據的7，已經成爲了如今的頭。

步驟三：

步驟二後，3完成了插入，再將7拿到手了，可是發現7的next指針仍是指向了3，那完了，就變成了3 -> 7 -> 3 -> 7 .......的死循環狀態了。

其實1.8作過了改進，可是一樣的會照成循環鏈的問題。

其實挺多博客都沒version 1.8會說已經結束了這個問題，可是爲何再提，那還不是由於被發現這個問題依舊存在碼。可是此次不是頭插法了，是出如今樹形和鏈表的數據結構轉化上，具體就不復述了。

其實知道便可，由於誰高併發情況還要用HashMap，這不是明知山有虎，偏向虎山行的蠢笨作法嘛。

總結

其實整體來講就是性能上是HashMap > ConcurrentHashMap > Hashtable ，考慮上線程安全之後ConcurrentHashMap > Hashtable 。也就是基於這些緣由纔會出現後來咱們在使用ConcurrentHashMap出現來替代Hashtable的狀況。

紅黑樹也是咱們對於性能優化的一種策略，可是從構建角度來看的話，紅黑樹的構建方式確實仍是比較麻煩的，須要必定的邏輯基礎。

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程