Java8中的HashMap分析

本篇文章是网上多篇文章的精华的总结，结合自己看源代码的一些感悟，其中线程安全性和性能测试部分并未做实践测试，直接是“拿来”网上的博客的。

哈希表概述

哈希表本质上一个数组，数组中每一个元素称为一个箱子（Bin），箱子中存放的是键值对Entry<K,V>链表，因而也称之为链表散列。

我们可以用图来形象地说明这个结构：

哈希表是如何工作的？

存储

Step1：根据哈希函数来计算HashCode值h，其中键值对Entry<K,V>的K来计算时需要的参数。

Step2：根据HashCode，来计算存放在哈希表（长度为n）中的位置（箱子的位置），一种计算方法是取余：h%n。

Step3：如果该箱子中已经存在键值对数据，则使用开放寻址法或拉链法解决冲突。

获取

Step1：根据key值计算HashCode的值h。

Step2：假设箱子的个数为 n，那么这个键值对应该放在第 (h % n) 个箱子中。

Step3：如果这个箱子里有多个键值对，同时假设箱子里的多个值是采用链表的方式存储，则需要遍历这个链表，复杂度为O(n)。

扩容

哈希表还有 一个重要的属性：负载因子，它是衡量哈希表的空/满程度，一定程度上也能体现查询的效率。其计算公式为：

负载因子 = 总键值对数 / 箱子数量

负载因子越大，意味着哈希表越满，越容易导致冲突（更大的概念找到同一个箱子上），因而查询效率也就更低。因而，一般来说，当负载因子大于某个常数（可能是1，也可能是其他值，Java8的HashMap的负载因子为0.75）时，哈希表就会自动扩容。

哈希表在扩容的时候，一般都会选择扩大2的倍数，同时将原来的哈希表的数据迁移到新的哈希表中，这样即使key的哈希值不变，对箱子的取余结果（假设我们用这种方法来计算HashCode）也会不同，因此所有的箱子和元素的存放位置都有可能发生变化，这个过程也称为重哈希（rehash）。

哈表的扩容并不能有效解决负载因子过大的问题，因为在前面的取HashCode的方法中，假设所有key的HashCode值都一样，那么即使扩容以后他们在哈希表中的位置也不会变，实际存放在箱子中的链表长度也不变，因此也就不能提高哈希表的查询速度。

因而，哈希表存在以下两个问题：

1、在扩容的时候，重哈希的成本比较大

2、如果Hash函数设计地不合理（如上面举例说明的取余），会导致哈希表中极端情况下变成线性表，性能极低。

我们下面来看看Java8中是如何处理这两个问题的。

以上这部分内容多参考自：深入理解哈希表 ，图片来自于HashMap的图示

Java8中的HashMap

在说明这个问题之前，我们来看下HashMap在Java8中在类图关系，如下所示：

Java8中通过如下几种方式来解决上面的两个问题：

一、让元素分布地更合理

（下面这部分不知道是哪位大神写的，原文照抄吧）

学过概率论的读者也许知道，理想状态下哈希表的每个箱子中，元素的数量遵守泊松分布：

当负载因子为 0.75 时，上述公式中 λ 约等于 0.5，因此箱子中元素个数和概率的关系如下：

数量	概率
0	0.60653066
1	0.30326533
2	0.07581633
3	0.01263606
4	0.00157952
5	0.00015795
6	0.00001316
7	0.00000094
8	0.00000006

这就是为什么我们将0.75设为负载因子，同时针对箱子中链表长度超过8以后要做另外的优化（一来是优化的概念较小，二来是优化过后的效率提升明显）。所以，一般情况下负载因子不建议修改；同时如果在数量为8的链表的概率较大，则几乎可以认为是哈希函数设计有问题导致的。

二、通过红黑树让查询更有效率（O(n)—>O(Log(n))）

第一点已经说明，当箱子中的链表元素超过8个时，会将这个链表转为红黑树，红黑树的查找效率为O(log(n))。红黑树的示图如下：

三、让扩容时重哈希(rehash)的成本变得更小

在Java7中，重哈希是要重新计算Hash值的，而在Java8中，通过高位运算的巧妙设计，避免了这种计算。下面我们举例说明：

我们要在初始大小为2的HashMap中存储3、5、7这3个值，Hash函数为取余法。

Step1：在开始的时候，3、5、7经过Hash过后 3%2=1、5%2=1、7%2=1，因而3、5、7存储在同一个箱子的链表中（地址为1）。

Step2：现在扩容了，扩容后的大小为2*2=4，现在经过Hash后3%4=3、5%4=1、7%4=3，因而3与7一起放在箱子的链表中（地址为3），5单独存放在一个箱子里（地址为1）。

整个过程如下图所示：

我们注意到，在扩容后3和7的位置变化了，由1—>3（=1+2）

      再进行扩容，由4容为8，那么经过Hash后，3%8=3、5%8=5、7%8=7，分别存放于3、5（=1+4）、7（=3+4）这几个位置中。

我们发现，扩容后的元素要么在原位置，要么在原位置再移动2次幂的位置，整个过程只需要使用一个位运算符<<就可以了（在源码的resize方法中可以找到）。

我们用计算机的地址来展示这个过程：

n为table的长度，图（a）表示扩容前的key1和key2两种key确定索引位置的示例，图（b）表示扩容后key1和key2两种key确定索引位置的示例，其中hash1是key1对应的哈希与高位运算结果。元素在重新计算hash之后，因为n变为2倍，那么n-1的mask范围在高位多1bit(红色)，因此新的index就会发生这样的变化：

因此，我们在扩充HashMap的时候，不需要像JDK1.7的实现那样重新计算hash，只需要看看原来的hash值新增的那个bit是1还是0就好了，是0的话索引没变，是1的话索引变成“原索引+oldCap”，可以看看下图为16扩充为32的resize示意图：

这个设计确实非常的巧妙，既省去了重新计算hash值的时间，而且同时，由于新增的1bit是0还是1可以认为是随机的，因此resize的过程，均匀的把之前的冲突的节点分散到新的bucket了。这一块就是JDK1.8新增的优化点。

以上这部分中的图示和位移讲解的内容参考自：深入分析hashmap

另外：

四：我们可以通过适当地初始化大小来控制扩容的次数：既然扩容是不可避免的，我们就尽可能少地让它发生，要实际编程的时候，应该根据业务合理地设置初始大小的值。

此外，Java8中HashMap还提供了另外一些参数来控制HashMap的性能，如下所示：

    /**
     * 默认的初始化大小(必须为2的幂)
     */
    static final int DEFAULT_INITIAL_CAPACITY = 1 << 4; // aka 16

    /**
     * 最大的存储数量(默认的数量,可以在构造函数中指定)
     * 必须为2的幂同时小于2的30次方
     */
    static final int MAXIMUM_CAPACITY = 1 << 30;

    /**
     * 默认的负载因子,可以在构建函数中指定
     */
    static final float DEFAULT_LOAD_FACTOR = 0.75f;

    /**
     * HashMap由链表转为红黑树存储的阀值
     * 1.8提供的新特性
     */
    static final int TREEIFY_THRESHOLD = 8;

    /**
     * HashMap由红黑树转为链表存储的阀值
     */
    static final int UNTREEIFY_THRESHOLD = 6;

    /**
     * HashMap的箱子中的链表转为红黑树之前还有一个判断:
     * 只在所有箱子(键值对)的数量大于64才会发生转换
     * 这样是为了避免在哈希表建立初期,多个键值对恰好被放入了同一个链表而导致不必要的转化
     */
    static final int MIN_TREEIFY_CAPACITY = 64;

源码中的关键方法

 方法一、hash方法

 static final int hash(Object key) {
         int h;
         return (key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16);//这里其实就要求大家来重写HashCode方法
     }

 方法二、putVal方法

下面是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为空则创建
      if ((tab = table) == null || (n = tab.length) == 0)
          n = (tab = resize()).length;
      // 步骤②：计算index，并对null做处理
      if ((p = tab[i = (n - 1) & hash]) == null)
          tab[i] = newNode(hash, key, value, null);
      else {
          Node<K,V> e; K k;
          // 步骤③：节点key存在，直接覆盖value
          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);
                         //链表长度大于8转换为红黑树进行处理
                      if (binCount >= TREEIFY_THRESHOLD - 1) // -1 for 1st
                          treeifyBin(tab, hash);
                      break;
                  }
                     // key已经存在直接覆盖value
                  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();
      afterNodeInsertion(evict);
      return null;
  }

HashMap的putVal方法

      这个 getNode() 方法就是根据哈希表元素个数与哈希值求模（使用的公式是 (n - 1) &hash）得到 key 所在的桶的头结点，如果头节点恰好是红黑树节点，就调用红黑树节点的 getTreeNode() 方法，否则就遍历链表节点。

 方法三、节点查找方法getNode

 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;
 }

HashMap的查找节点方法

 

方法四、红黑树生成方法

 //将桶内所有的 链表节点 替换成 红黑树节点

 final void treeifyBin(Node<K,V>[] tab, int hash) {

     int n, index; Node<K,V> e;

     //如果当前哈希表为空，或者哈希表中元素的个数小于 进行树形化的阈值(默认为 64)，就去新建/扩容

    if (tab == null || (n = tab.length) < MIN_TREEIFY_CAPACITY)

         resize();

     else if ((e = tab[index = (n - 1) & hash]) != null) {

         //如果哈希表中的元素个数超过了 树形化阈值，进行树形化

         // e 是哈希表中指定位置桶里的链表节点，从第一个开始

         TreeNode<K,V> hd = null, tl = null; //红黑树的头、尾节点

         do {

             //新建一个树形节点，内容和当前链表节点 e 一致

             TreeNode<K,V> p = replacementTreeNode(e, null);

             if (tl == null) //确定树头节点

                 hd = p;

            else {

                p.prev = tl;

                 tl.next = p;

             }

             tl = p;

         } while ((e = e.next) != null); 

         //让桶的第一个元素指向新建的红黑树头结点，以后这个桶里的元素就是红黑树而不是链表了

         if ((tab[index] = hd) != null)

             hd.treeify(tab);

     }

  }

     TreeNode<K,V> replacementTreeNode(Node<K,V> p, Node<K,V> next) {

     return new TreeNode<>(p.hash, p.key, p.value, next);

  }

红黑树生成方法

方法五、红黑树节点查找方法

 final TreeNode<K,V> find(int h, Object k, Class<?> kc) {
             TreeNode<K,V> p = this;
             do {
                 int ph, dir; K pk;
                 TreeNode<K,V> pl = p.left, pr = p.right, q;
                 if ((ph = p.hash) > h)
                     p = pl;
                 else if (ph < h)
                     p = pr;
                 else if ((pk = p.key) == k || (k != null && k.equals(pk)))
                     return p;
                 else if (pl == null)
                     p = pr;
                 else if (pr == null)
                     p = pl;
                 else if ((kc != null ||
                           (kc = comparableClassFor(k)) != null) &&
                          (dir = compareComparables(kc, k, pk)) != 0)
                     p = (dir < 0) ? pl : pr;
                 else if ((q = pr.find(h, k, kc)) != null)
                     return q;
                 else
                     p = pl;
             } while (p != null);
             return null;
         }

红黑树查找方法

方法六、扩容方法

 final Node<K,V>[] resize() {
     Node<K,V>[] oldTab = table;
     int oldCap = (oldTab == null) ? 0 : oldTab.length;
     int oldThr = threshold;
     int newCap, newThr = 0;
     if (oldCap > 0) {
         // 超过最大值就不再扩充了，就只好随你碰撞去吧
         if (oldCap >= MAXIMUM_CAPACITY) {
             threshold = Integer.MAX_VALUE;
             return oldTab;
         }
         // 没超过最大值，就扩充为原来的2倍
         else if ((newCap = oldCap << 1) < MAXIMUM_CAPACITY &&
                  oldCap >= DEFAULT_INITIAL_CAPACITY)
             newThr = oldThr << 1; // double threshold
     }
     else if (oldThr > 0) // initial capacity was placed in threshold
         newCap = oldThr;
     else {               // zero initial threshold signifies using defaults
         newCap = DEFAULT_INITIAL_CAPACITY;
         newThr = (int)(DEFAULT_LOAD_FACTOR * DEFAULT_INITIAL_CAPACITY);
     }
     // 计算新的resize上限
     if (newThr == 0) {

         float ft = (float)newCap * loadFactor;
         newThr = (newCap < MAXIMUM_CAPACITY && ft < (float)MAXIMUM_CAPACITY ?
                   (int)ft : Integer.MAX_VALUE);
     }
     threshold = newThr;
     @SuppressWarnings({"rawtypes","unchecked"})
         Node<K,V>[] newTab = (Node<K,V>[])new Node[newCap];
     table = newTab;
     if (oldTab != null) {
         // 把每个bucket都移动到新的buckets中
         for (int j = 0; j < oldCap; ++j) {
             Node<K,V> e;
             if ((e = oldTab[j]) != null) {
                 oldTab[j] = null;
                 if (e.next == null)
                     newTab[e.hash & (newCap - 1)] = e;
                 else if (e instanceof TreeNode)
                     ((TreeNode<K,V>)e).split(this, newTab, j, oldCap);
                 else { // preserve order
                     Node<K,V> loHead = null, loTail = null;
                     Node<K,V> hiHead = null, hiTail = null;
                     Node<K,V> next;
                     do {
                         next = e.next;
                         // 原索引
                         if ((e.hash & oldCap) == 0) {
                             if (loTail == null)
                                 loHead = e;
                             else
                                 loTail.next = e;
                             loTail = e;
                         }
                         // 原索引+oldCap
                         else {
                             if (hiTail == null)
                                 hiHead = e;
                             else
                                 hiTail.next = e;
                             hiTail = e;
                         }
                     } while ((e = next) != null);
                     // 原索引放到bucket里
                     if (loTail != null) {
                         loTail.next = null;
                         newTab[j] = loHead;
                     }
                     // 原索引+oldCap放到bucket里
                     if (hiTail != null) {
                         hiTail.next = null;
                         newTab[j + oldCap] = hiHead;
                     }
                 }
             }
         }
     }
     return newTab;
 }

HashMap扩容方法

方法七、扩容后的元素转移方法

  void transfer(Entry[] newTable) {
      Entry[] src = table;                   //src引用了旧的Entry数组
      int newCapacity = newTable.length;
      for (int j = 0; j < src.length; j++) { //遍历旧的Entry数组
          Entry<K,V> e = src[j];             //取得旧Entry数组的每个元素
          if (e != null) {
              src[j] = null;//释放旧Entry数组的对象引用（for循环后，旧的Entry数组不再引用任何对象）
              do {
                  Entry<K,V> next = e.next;
                  int i = indexFor(e.hash, newCapacity); //！！重新计算每个元素在数组中的位置
                  e.next = newTable[i]; //标记[1]
                  newTable[i] = e;      //将元素放在数组上
                  e = next;             //访问下一个Entry链上的元素
              } while (e != null);
          }
      }
 17 }

扩容后的元素转移

线程安全性

在多线程使用场景中，应该尽量避免使用线程不安全的HashMap，而使用线程安全的ConcurrentHashMap。那么为什么说HashMap是线程不安全的，下面举例子说明在并发的多线程使用场景中使用HashMap可能造成死循环。代码例子如下(便于理解，仍然使用JDK1.7的环境)：

 public class HashMapInfiniteLoop {  

     private static HashMap<Integer,String> map = new HashMap<Integer,String>(2，0.75f);
     public static void main(String[] args) {
         map.put(5， "C");  

         new Thread("Thread1") {
             public void run() {
                 map.put(7, "B");
                 System.out.println(map);
             };
         }.start();
         new Thread("Thread2") {
             public void run() {
                 map.put(3, "A);
                 System.out.println(map);
             };
         }.start();
     }
 }

其中，map初始化为一个长度为2的数组，loadFactor=0.75，threshold=2*0.75=1，也就是说当put第二个key的时候，map就需要进行resize。

通过设置断点让线程1和线程2同时debug到transfer方法(3.3小节代码块)的首行。注意此时两个线程已经成功添加数据。放开thread1的断点至transfer方法的“Entry next = e.next;” 这一行；然后放开线程2的的断点，让线程2进行resize。结果如下图：

注意，Thread1的 e 指向了key(3)，而next指向了key(7)，其在线程二rehash后，指向了线程二重组后的链表。

线程一被调度回来执行，先是执行 newTalbe[i] = e， 然后是e = next，导致了e指向了key(7)，而下一次循环的next = e.next导致了next指向了key(3)。

e.next = newTable[i] 导致 key(3).next 指向了 key(7)。注意：此时的key(7).next 已经指向了key(3)， 环形链表就这样出现了。

于是，当我们用线程一调用map.get(11)时，悲剧就出现了——Infinite Loop。

性能表现：JDK1.8 vs JDK1.7

HashMap中，如果key经过hash算法得出的数组索引位置全部不相同，即Hash算法非常好，那样的话，getKey方法的时间复杂度就是O(1)，如果Hash算法技术的结果碰撞非常多，假如Hash算极其差，所有的Hash算法结果得出的索引位置一样，那样所有的键值对都集中到一个桶中，或者在一个链表中，或者在一个红黑树中，时间复杂度分别为O(n)和O(lgn)。 鉴于JDK1.8做了多方面的优化，总体性能优于JDK1.7，下面我们从两个方面用例子证明这一点。

Hash较均匀的情况

为了便于测试，我们先写一个类Key，如下：

 class Key implements Comparable<Key> {

     private final int value;

     Key(int value) {
         this.value = value;
     }

     @Override
     public int compareTo(Key o) {
         return Integer.compare(this.value, o.value);
     }

     @Override
     public boolean equals(Object o) {
         if (this == o) return true;
         if (o == null || getClass() != o.getClass())
             return false;
         Key key = (Key) o;
         return value == key.value;
     }

     @Override
     public int hashCode() {
         return value;
     }
 }

这个类复写了equals方法，并且提供了相当好的hashCode函数，任何一个值的hashCode都不会相同，因为直接使用value当做hashcode。为了避免频繁的GC，我将不变的Key实例缓存了起来，而不是一遍一遍的创建它们。代码如下：

 public class Keys {

     public static final int MAX_KEY = 10_000_000;
     private static final Key[] KEYS_CACHE = new Key[MAX_KEY];

     static {
         for (int i = 0; i < MAX_KEY; ++i) {
             KEYS_CACHE[i] = new Key(i);
         }
     }

     public static Key of(int value) {
         return KEYS_CACHE[value];
     }
 }

现在开始我们的试验，测试需要做的仅仅是，创建不同size的HashMap（1、10、100、……10000000），屏蔽了扩容的情况，代码如下：

 static void test(int mapSize) {

        HashMap<Key, Integer> map = new HashMap<Key,Integer>(mapSize);
        for (int i = 0; i < mapSize; ++i) {
            map.put(Keys.of(i), i);
        }

        long beginTime = System.nanoTime(); //获取纳秒
        for (int i = 0; i < mapSize; i++) {
            map.get(Keys.of(i));
        }
        long endTime = System.nanoTime();
        System.out.println(endTime - beginTime);
    }

    public static void main(String[] args) {
        for(int i=10;i<= 1000 0000;i*= 10){
            test(i);
        }
    }

在测试中会查找不同的值，然后度量花费的时间，为了计算getKey的平均时间，我们遍历所有的get方法，计算总的时间，除以key的数量，计算一个平均值，主要用来比较，绝对值可能会受很多环境因素的影响。结果如下：

通过观测测试结果可知，JDK1.8的性能要高于JDK1.7 15%以上，在某些size的区域上，甚至高于100%。由于Hash算法较均匀，JDK1.8引入的红黑树效果不明显，下面我们看看Hash不均匀的的情况。

Hash极不均匀的情况

假设我们又一个非常差的Key，它们所有的实例都返回相同的hashCode值。这是使用HashMap最坏的情况。代码修改如下：

 class Key implements Comparable<Key> {

     //...

     @Override
     public int hashCode() {
         return 1;
     }
 }

仍然执行main方法，得出的结果如下表所示：

从表中结果中可知，随着size的变大，JDK1.7的花费时间是增长的趋势，而JDK1.8是明显的降低趋势，并且呈现对数增长稳定。当一个链表太长的时候，HashMap会动态的将它替换成一个红黑树，这话的话会将时间复杂度从O(n)降为O(logn)。hash算法均匀和不均匀所花费的时间明显也不相同，这两种情况的相对比较，可以说明一个好的hash算法的重要性。

小结

1.有两个字典，分别存有 100 条数据和 10000 条数据，如果用一个不存在的 key 去查找数据，在哪个字典中速度更快？

完整的答案是:在 Redis 中，得益于自动扩容和默认哈希函数，两者查找速度一样快。在 Java 和 Objective-C 中，如果哈希函数不合理，返回值过于集中，会导致大字典更慢。Java 由于存在链表和红黑树互换机制，搜索时间呈对数级增长，而非线性增长。在理想的哈希函数下，无论字典多大，搜索速度都是一样快。

2. 扩容是一个特别耗性能的操作，所以当程序员在使用HashMap的时候，估算map的大小，初始化的时候给一个大致的数值，避免map进行频繁的扩容。

3. 负载因子是可以修改的，也可以大于1，但是建议不要轻易修改，除非情况非常特殊。

4. HashMap是线程不安全的，不要在并发的环境中同时操作HashMap，建议使用ConcurrentHashMap。

5. JDK1.8引入红黑树大程度优化了HashMap的性能。

参考文档

https://tech.meituan.com/java-hashmap.html

https://www.cnblogs.com/gotodsp/p/6534699.html

https://www.cnblogs.com/shengkejava/p/6771469.html

http://www.importnew.com/14417.html 这篇讲性能的文章值得一看

http://alex09.iteye.com/blog/539545 这是讲Java7中的HashMap的

https://www.cnblogs.com/chinajava/p/5808416.html 这里面讲了Java的HashMap和Redis的HashMap对比

http://blog.csdn.net/Richard_Jason/article/details/53887222

http://www.importnew.com/7099.html