深入分析HaspMap源码-蒲公英云

1.分析HaspMap的构造器

前面分析HashMap的put(K key,V value)源码的时候发现，其中有两个特殊的变量:

size:该变量保存了该HashMap中所包含的key-value对的数量。
threshold：该变量包含了HashMap能容纳的key-value对的极限，它的值等于HashMap的容量乘以负载因子(load factor)。

在HashMap的addEntry方法中，当size++>=threshold时。HashMap会自动调用resize方法扩充HashMap的容量。但每扩充一次，HashMap的容量就增大一倍。

HashMap源码中存在一个就table的数组。这个数组的长度其实就是HashMap的容量。HashMap包含如下几个构造器:

HashMap() 初始容量为16。负载因子为0.75的HashMap。
HashMap(int initialCapacity) 构建一个初始容量为 initialCapacity，负载因子为0.75的HashMap
HashMap(int initialCapacity,float loadFactor) 构建指定初始容量和负载因子的HashMap

当创建一个HasMap时，系统会自动创建一个table数组来保存HashMap中的Entry。
观察构造器的源码:

//以指定初始化容量，负载因子创建HashMap
  public HashMap(int initialCapacity, float loadFactor) {
  //初始容量不能为负数
        if (initialCapacity < 0)
            throw new IllegalArgumentException("Illegal initial capacity: " +
                                               initialCapacity);
        //初始容量不能太大
        if (initialCapacity > MAXIMUM_CAPACITY)
            initialCapacity = MAXIMUM_CAPACITY;
        //负载因子必须大于0
        if (loadFactor <= 0 || Float.isNaN(loadFactor))
            throw new IllegalArgumentException("Illegal load factor: " +
                                               loadFactor);
    //计算出大于initialCapacity的最小的2的n次方值
    int capacity = 1;
    while(capacity<initialCapacity)
      capacity<<=1;
       this.loadFacotor = loadFactor;
       //设置容量极限等于容量乘以负载因子
       threshold = (int)(capacity * loadFactor);
       //初始化table数组
       table = new Entry(capacity);
       init();
    }

注意观察下面这两段代码:

int capacity = 1;
    while(capacity<initialCapacity)
      capacity<<=1;

找出大于initialCapacity的，最小的2的n次方值，并将其作为HashMap的实际容量。例如给定initialCapacity为10，那么HashMap的实际容量就是16。通常来说，HaspMap最后的实际容量通常比initialCapacity大一点，除非它刚好是2的n次方，所以我们在创建HaspMap需要指定容量时指定为2的n次方可以减少不必要的开销。

补充:

<< 把数据向左移动。移除的删除，右边用0补齐相当于乘以2的移动次幂
>> 把数据向右移动。移除的删除，左边用最高位补齐相当于除以2的移动次幂

2.HashMap根据key取出value

对于HashMap及其子类而言，它们采用Hash算法来决定集合中元素的存储位置。当系统开始初始化HashMap时，系统会创建一个长度为Capacity的Entry的数组。这个数组里可以存储元素的位置被称为”桶(bucket)”，每个bucket都有其特定的索引，系统可以根据其索引快速访问该bucket里存储的元素。

一般情况下，bucket里存储的是单个Entry，但也有会生成Entry链的情况(即两个key的hash值相同但equals返回false)。当bucket里面存储的是单个Entry，此时HaspMap性能最好。当程序需要根据key取出value时，只需要计算出key的hash值，再根据该hash值找出key在table数组中的索引，然后取出该索引处的Entry，最后返回该Entry的value即可。下面我们来看HashMapget(K key)的源码:

public V get(Object key) {
//如果key是null。调用getForNullKey
    if (key == null)
        return getForNullKey();
        //计算key的hash值
        int hash = hash(key.hashCode());
        //直接取出table数组中的指定索引处的值
        for (Entry<K,V> e = table[indexFor(hash, table.length)];
             e != null;
             //搜索下一个Entry
             e = e.next) {
            Object k;
            //如果该Entry的key与被搜索key相同
            if (e.hash == hash && ((k = e.key) == key || key.equals(k)))
                return e.value;
        }
        return null;
    }

从上面代码可以看出，当HashMap的每个bucket里只有一个Entry，HaspMap可以快速从bucket里取出Entry。在发生”Hash冲突”的情况下，单个bucket里存储的不是一个Entry，而是Entry链，此时系统只能通过遍历每个Entry，直到找到搜索的Entry为止。

总结一下:

HaspMap在底层把一个KEy-Value当成一个整体Entry对象来处理。
HaspMap底层通过一个Entry[]数组来保存所有的key-value对。
对于每一个要存储的key-value，系统通过Hash算法确定其存储位置。
当需要取出一个Entry时，也会根据Hash值来找到其在数组中存储位置

再谈负载因子loadFactor:

HaspMap有一个默认的负载因子值0.75。这是时间和空间成本上的一种折衷:

增大负载因子可以减少Hash表(就是那个Entry[]数组)所占用内存空间，但会增大查询数据的时间开销，而查询是最频繁的操作(HashMap的get()和put()都要查询)
减少负载因子可以会提高数据查询的性能，但会增加Hash表所占用的内存空间。

现在我们合理的调整负载因子的值了。如果程序比较关心内存的开销，适当增加负载因子。如果比较关心时间开销，则适当减小负载因子，其实大部分情况下保持负载因子默认的0.75即可。

多线程环境下，使用HashMap进行put操作引起的问题分析

在多线程的环境下，多个线程对HashMap数据进行put操作时会导致死循环。而造成这个原因的罪魁祸首就是因为HashMap的自动扩容机制。

我们来观察HashMap的put过程

public V put(K key, V value) {  
            if (table == EMPTY_TABLE) {  
                inflateTable(threshold);  
            } 
            //当key为null，调用putForNullKey来处理 
            if (key == null)  
                return putForNullKey(value);  
                //根据key的hashCode计算hash值
            int hash = hash(key);  
            //搜索制定hash值在对于table中的索引
            int i = indexFor(hash, table.length);
            //如果i处索引不为null。则通过循环不断遍历e元素的下一个元素  
            for (Entry<K,V> e = table[i]; e != null; e = e.next) {  
                Object k;  
                //找到指定key与需要放入key相等(即两者hash值相同，equals返回true)
                if (e.hash == hash && ((k = e.key) == key || key.equals(k))) {  
                    V oldValue = e.value;  
                    e.value = value;  
                    e.recordAccess(this);  
                    return oldValue;  
                }  
            }  
      //如果i索引处的entry为null。表明此次没有entry。直接插入在此次即可
            modCount++;  
      //添加key，value到索引i处
            addEntry(hash, key, value, i);  
            return null;  
        }

现在我们可以看出:当程序试图将一个key-value对放入HashMap中时，首先根据key的hashCode()返回值决定该Entry的存储位置，如果两个key的hash值相同，那么它们的存储位置相同。如果这个两个key的equalus比较返回true。那么新添加的Entry的value会覆盖原来的Entry的value，key不会覆盖。如果这两个equals返回false，那么这两个Entry会形成一个Entry链，并且新添加的Entry位于Entry链的头部。

观察addEntry(hash, key, value, i);源码:

void addEntry(int hash, K key, V value, int bucketIndex) {  
         //获取指定bucketIndex处的Entry
        Entry<K,V> e = table[bucketIndex];
        //将新创建的Entry放入bucketIndex索引处，并让新Entry指向原来的Entry  
        table[bucketIndex] = new Entry<K,V>(hash, key, value, e);  
       //如果Map中的key-value对的数量超过了极限
       if(size++>=threshold){
       //扩充table对象的长度到2倍
        resize(2*table.length);
        }
    }

现在我们看罪魁祸首的resize方法的源码:

void resize(int newCapacity)
{
    Entry[] oldTable = table;
    int oldCapacity = oldTable.length;
    ......
    //创建一个新的Hash Table
    Entry[] newTable = new Entry[newCapacity];
    //复制旧数据到新数组中:
    transfer(newTable);
    table = newTable;
    threshold = (int)(newCapacity * loadFactor);
}

复制旧数据到新数组中源码:

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

画了个图做了个演示。

我假设了我们的hash算法就是简单的用key mod 一下表的大小（也就是数组的长度）。
最上面的是old hash 表，其中的Hash表的size=2, 所以key = 3, 7, 5，在mod 2以后都冲突在table[1]这里了。
接下来的三个步骤是Hash表 resize成4，然后所有的<key,value> 重新rehash的过程

这里写图片描述

多线程下的rehash:

1）假设我们有两个线程。我用红色和浅蓝色标注了一下。

我们再回头看一下我们的 transfer代码中的这个细节：

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