Java集合之深入理解HashMap

1、HashMap底层数据结构

HashMap是Java提供的使用K-V键值对方式进行存储和访问的集合类。其底层实际上是一个“链表散列”的数据结构，即数组和链表的结构，但是在jdk1.8里加入了红黑树的实现，当链表的长度超过8且size达到64时，转换为红黑树的结构，提升查询的性能。

那么为什么采用红黑树而不是平衡二叉树呢？原因是虽然红黑树的查询性能略逊色于AVL（平衡二叉树）树，因为他比AVL树会稍微不平衡最多一层，也就是说红黑树的查询性能只比相同内容的AVL树最多多一次比较，但是，红黑树在插入和删除上比AVL开销小得多。

2、put方法源码分析

put方法整体流程：
1、检查map中的数据Node table[]是否初始化，没有则初始化
2、根据新增的key的hashcode，获取table[(n-1) & hashCode]元素，如果为空，直接放入到此位置
3、如果2上面对应位置的元素不为空，对比新的key.equals(oldKey)是否相等，如果相等，替换就元素的值；如果不相等，判断2中的元素是否是红黑树，如果是，将新元素加入到红黑树结构中，如果不是红黑树结构，将新元素添加到该元素的链表结构中
4、若链表的长度超过8，转为红黑树结构
5、当前HashMap的size+1，并检查当前的容量是否超过初始容量和负载因子的乘积，如果超过，则扩容

	// 入口put方法
	public V put(K key, V value) {
        return putVal(hash(key), key, value, false, true);
	}
	// 获取对象hash值
	static final int hash(Object key) {
        int h;
        return (key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16);
	}
	final V putVal(int hash, K key, V value, boolean onlyIfAbsent,
                   boolean evict) {
        Node<K,V>[] tab; Node<K,V> p; int n, i;
        // 1、table是否初始化，没有则初始化
        if ((tab = table) == null || (n = tab.length) == 0)
            n = (tab = resize()).length;
        // 2、根据新增的key的hashcode，获取table[(n-1) & hashCode]元素，如果为空，直接放入到此位置
        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
                        	//长度超过8，转为红黑树
                            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();
        // 插入数据后的操作，子类实现(LinkedHashMap)
        afterNodeInsertion(evict);
        return null;
    }

3、HashMap避免hash冲突的优化

当key的hash值出现冲突时，会使得不同的数据存放到HashMap数组的同一个位置，形成链表或者红黑树，在此情况下，当需要获取对应的key的值时，查询次数会增加，影响性能，因此要尽量避免出现hash值冲突的情况发生。HashMap主要做了两点优化避免hash冲突。
1、hash寻址算法优化：用与运算替代取模，提升性能

tab[i = (n - 1) & hash])

当n是2的幂值时，hash对n取模的效果 与 hash & (n - 1)，效果是一样的，但是后者的性能更高
2、hash计算优化：在计算key对应所在table位置时，是与容量n进行取模运算的。但是n一般情况下不会太大，高16位一般是0，那么在第一步的计算中，hash值只有低16位参与计算，这样会增大hash冲突的概率。因此对每个hash值，在他的低16位中，让高低16位进行了异或，让他的低16位同时保持了高低16位的特征，尽量避免一些hash值后续出现冲突，大家可能会进入数组的同一个位置

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

4、hash冲突后的优化，为什么链表长度超过8就转换成红黑树

当出现hash冲突时，HashMap是先将数据转换成链表。当链表长度超过8且size达到64后，会转换成红黑树。为什么是长度超过8就转换呢？看一下类中的说明：

Because TreeNodes are about twice the size of regular nodes, 
we use them only when bins contain enough nodes to warrant use.

翻译一下：因为红黑树的空间占用是常规节点的两倍，所以仅当链表包含足够的节点时，才会使用红黑树。
所以第一点，节点数不能太少，否则空间占用多，不划算。但是链表节点数也不能太多，否则查询效率太低。红黑树的查找时间复杂度是log(n)，长度为8，查找长度为log(8)=3，链表的查找时间复杂度为n/2，当长度为8时，平均查找长度为8/2=4，这才有转换成树的必要；链表长度如果是小于等于6，6/2=3，虽然速度也很快的，但是转化为树结构和生成树的时间并不会太短。
网上有说法是泊松分布规律，8的概率已经很低所以才选择8这个数。看一下类说明：

     * In usages with well-distributed user hashCodes, tree bins are
     * rarely used.  Ideally, under random hashCodes, the frequency of
     * nodes in bins follows a Poisson distribution
     * (http://en.wikipedia.org/wiki/Poisson_distribution) with a
     * parameter of about 0.5 on average for the default resizing
     * threshold of 0.75, although with a large variance because of
     * resizing granularity. Ignoring variance, the expected
     * occurrences of list size k are (exp(-0.5) * pow(0.5, k) /
     * factorial(k)). The first values are:
     *
     * 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
     * more: less than 1 in ten million

翻译一下：
第一句是重点：在hashcode均匀分布的情况下，红黑树基本不会被使用到。为什么呢？后面的话是解释：理想情况下，在随机哈希代码下，当负载因子为0.75时，桶中的节点频率遵循泊松分布，节点长度出现的概率是上面给出的情况，超过8的概率非常非常小，那么转换成红黑树的概率就很小。所以类中提到泊松分布，只是为了解释第一句话以及负载因子默认值取0.75的一个原因而已，跟链表长度超过8再转换红黑树并没有关系。8这个取值其实跟负载因子默认取0.75是一个原因，是空间和时间的折中，应该是数学理论中的知识。

5、HashMap死循环问题

在多线程环境下操作HashMap，JDK1.7中会出现死循环问题。其根本原因是多线程扩容时，链表采用的是头插法，导致链表元素的next指针出现循环引用，在get时出现死循环。在JDK1.8中，扩容操作已经改成了尾插法，但是在多线程环境下还是有其他问题存在，因此要直接使用ConcurrentHashMap，不要使用HashMap。