Java HashMap源码浅析

之前虽然很频繁使用java的hashmap，但一直都是纯用，至于里面怎么实现的，一直都是糊里糊涂的。今年4月份跳槽找工作，大概看了一下HashMap的源码，在面试过程中也被多位面试官问到HashMap的相关问题，有些问题也没回答出来。本来几个月前就想着写一篇相关源码解析的博客（主要是加深自己的理解），一直拖到现在，接下来就跟我一起看下HashMap的实现（基于jdk8）。
　　
　　HashMap实现了Map，Cloneable，Serializable三个接口，Map定义了必要方法，Cloneable意味着HashMap是可被clone的，Serializable以为这HashMap可以被序列化。但是AbstractMap是什么鬼？打开AbstractMap的源码就会发现注释第一句就告诉你，AbstractMap给Map提供了一个骨架，事实上它实现了Map的几乎所有的方法，除了entrySet()。AbstractMap既然实现了Map接口，那为什么HashMap还要实现Map接口？ 好吧关于这个问题，有人说是个作者的一个失误，见StackOverflow，我觉得这个说法站不住脚啊，如果是个失误，为啥到jdk10还没被修复，跳过这个问题。
　　打开HashMap的源码，跳过一堆注释，最先看到的是几个常量，这几个常量是缺省时的默认值，非常重要，它们决定这HashMap在使用过程中内部的发生的一些行为，我们挨个看一下。

long serialVersionUID = 362498820763181265L;   //用来在序列化时校验用的  
int DEFAULT_INITIAL_CAPACITY = 1 << 4;   //缺省时HashMap的初始容量 16
int MAXIMUM_CAPACITY = 1 << 30;  //最大容量  
float DEFAULT_LOAD_FACTOR = 0.75f;  //缺省时的默认负载因子，当map中的存储量占总容量的75%以上，hashmap就会把自身容量扩张一倍
int TREEIFY_THRESHOLD = 8;  // 触发树化阀值
int MIN_TREEIFY_CAPACITY = 64;  // 真正树化阀值 

了解一个类，应该最先从其构造函数开始，HashMap可选的构造参数并不多，最核心的就这一个构造方法，如下。

    public HashMap(int initialCapacity, float loadFactor) {
        if (initialCapacity < 0)
            throw new IllegalArgumentException("Illegal initial capacity: " +
                                               initialCapacity);
        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);
    }

这个构造函数做的事很简单，只是初始化了两个值，一个是负载因子，如果用户用自定义切校验通过就会抛弃默认的0.75负载因子。另一个是threshold，loadFactor是个负载因子的比例，threhold才是实际值，HashMap会根据threhold具体值来做resize()。这里我们顺带看下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;
    }

这个函数就就是找到最小那个比cap大的2^n。
　　如上所示，其实构造函数什么都没做。内部空间初始化也没做，那什么时候做呢？其实HashMap存储初始化的动作都是插入值的时候做的，这样设计有个好处，可以避免你虽然new了一个HashMap，但写入数据导致的资源浪费。
　　 接下来我们看下HashMap内部是怎么存储数据的。HashMap中有个内部静态类Node<K,V>，这个用来存储数据的实体，看下代码。

static class Node<K,V> implements Map.Entry<K,V> {
        final int hash;
        final K key;
        V value;
        Node<K,V> next;
        /**
        * 省略一些简单方法
        */
    }

这个类里除了用户可见的K，V之外，还额外存储了hash值，这个hash值就是K的hash值，单独存下是为了优化，不需要每次用到的时候都计算K的hash值。next这个就是单链表的next指针了，HashMap解决hash值冲突的方式就是是开一条单链表，Jdk8之后就不仅仅是单链表了，后续我们会详解介绍。
　　HashMap中有个Node<K,V>[] table; 这个数组就是所有数据存储的地方了。它会在第一次插入数据时发现table为null候才被初始化。

final V putVal(int hash, K key, V value, boolean onlyIfAbsent,
                   boolean evict) {
        Node<K,V>[] tab; Node<K,V> p; int n, i;
        if ((tab = table) == null || (n = tab.length) == 0)
            n = (tab = resize()).length;
        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();
        afterNodeInsertion(evict);
        return null;
    }

既然贴出来了这段代码了，我们就先来看下这段，再看HashMap的resize()。最开始就检查table，如果table是null，就用resize做初始化，然后在安插新节点。如果遇到hash值碰撞，如果发现是同一个key，就覆盖。否在有两种情况，要么单链表插入，要么红黑树插入，一个HashMap的内部存储可能长这个样子，树化后的某些单链表可能会变成一颗树(示意图，并不代表真实情况)。

　　这里就遇到jdk对于hashmap指针碰撞的优化了，如果过多的K,V都有同样的hash值，就会变成一条非常长的链，增删查的性能就非常低了。所以jdk8在链表长度达到8的时候就会触发链表的树话，把单链表变成一个红黑树，可以把各种操作的时间复杂度从O(n)降低到O(logn)。
　　事实上，链表长度到8，虽然会触发树化，但并不一定会树化，而是会优先选择resize()，只有链表长度达到64才会树化，其实我并不理解为什么要再设个64的阀值才会树化，可能是在节点树少的时候，树的平局操作时间复杂度不会比单链表的优太多吧。
　　我觉得在HashMap中resize()是HashMap的核心，也是很多问题的根源。虽然resize()对用户不可见，但它是保证HashMap性能最重要的一般，当然它也是HashMap并发问题的罪魁祸首。

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;
            }
            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);
        }
        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) {
            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;
                            }
                            else {
                                if (hiTail == null)
                                    hiHead = e;
                                else
                                    hiTail.next = e;
                                hiTail = e;
                            }
                        } while ((e = next) != null);
                        if (loTail != null) {
                            loTail.next = null;
                            newTab[j] = loHead;
                        }
                        if (hiTail != null) {
                            hiTail.next = null;
                            newTab[j + oldCap] = hiHead;
                        }
                    }
                }
            }
        }
        return newTab;
    }

大体上就是新建一个newTab，是原来table大小的两倍，然后把原有数据做放到newTab中。先不管Tree是怎么裂变的（还没搞懂），我们来看下单链表怎么裂变的。 这里直接把一个单链表裂变成了两个。在odltab中第j位置的单链表，裂变成两条单链表，一条放newtab中j位置，另一条放newtab中i+oldcap的位置，每个j都是这么做的，就是这么神奇， 很长时间我一直没理解这么简单处理，如何保证在同一条链表中的节点都有相同的hash值？
　　其实也很简单，就是按hash值第oldCap那位0和1做了区分。因为我们cap每次都是以2为系数增长的，然后按cap-1为掩码来计算位置的，当容量扩大一倍后，只会有一部分最高位是1的才需要移动。比如hash值最后4位都是是0101的节点，其在newtab中新的位置要么是10101，要么是00101。
　　今天最后一个问题，为什么HashMap不是线程安全的？ 罪魁祸首还是resize()，如果在多线程插入的情况下，多个线程有可能同时执行resize()，多线程操作一个单链表，很大几率会出现数据一致性的问题，甚至有可能会在链表中出现环。

文章来源: xindoo.blog.csdn.net，作者：xindoo，版权归原作者所有，如需转载，请联系作者。

原文链接：xindoo.blog.csdn.net/article/details/82555800