JDK7HashMap

JDK7HashMap

成员变量

HashMap中定义了非常多的成员变量以及常量，各成员变量含义具体如下：

//默认初始化长度-16
static final int DEFAULT_INITIAL_CAPACITY = 1 << 4; // aka 16
//最大容量
static final int MAXIMUM_CAPACITY = 1 << 30;
//默认加载因子
static final float DEFAULT_LOAD_FACTOR = 0.75f;
//空entry数组
static final Entry<?,?>[] EMPTY_TABLE = {};
//table存放数据
transient Entry<K,V>[] table = (Entry<K,V>[]) EMPTY_TABLE;
//数组包含元素个数
transient int size;
//数组扩容阈值=capacity*load_factor
int threshold;
//加载因子
final float loadFactor;

DEFAULT_INITIAL_CAPACITY为什么设置为16，创建HashMap的时候需要设置值嘛？

这些问题将等下揭晓。

DEFAULT_LOAD_FACTOR为什么设置为0.75？

JDK官方基于空间与时间成本做出的均衡，加载因子越大，扩容越晚，节省空间，哈希碰撞越多，put、get效率越低，至于为什么是0.75，这是一个数学or统计问题？再次不做深究

HashMap的存储结构

//成员变量Entry数组
transient Entry<K,V>[] table = (Entry<K,V>[]) EMPTY_TABLE;
static final Entry<?,?>[] EMPTY_TABLE = {};

//内部类Entry，实现了Map.Entry接口
static class Entry<K,V> implements Map.Entry<K,V>{
    	final K key;
        V value;
        Entry<K,V> next;
        int hash;

        /**
         * Creates new entry.
         */
        Entry(int h, K k, V v, Entry<K,V> n) {
            value = v;
            next = n;
            key = k;
            hash = h;
        }
}

由此可以看出，JDK7的HashMap的存储结构是通过数组加链表的方式实现的，了解了put方法之后也能明白，HashMap采用的是冲突链表的方式解决哈希碰撞

JDK7的HashMap构造方法

public HashMap() {
    //调用默认初始长度16，默认加载因子0.75
    this(DEFAULT_INITIAL_CAPACITY, DEFAULT_LOAD_FACTOR);
}
public HashMap(int initialCapacity) {
    //默认加载因子0.75
        this(initialCapacity, DEFAULT_LOAD_FACTOR);
}

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);
		//对loadFactor赋值以及threshold赋值
        this.loadFactor = loadFactor;
        threshold = initialCapacity;
    	//空方法，交由子类实现，在HashMap中无用
        init();
}

//插入整个map
public HashMap(Map<? extends K, ? extends V> m) {
        this(Math.max((int) (m.size() / DEFAULT_LOAD_FACTOR) + 1,
                      DEFAULT_INITIAL_CAPACITY), DEFAULT_LOAD_FACTOR);
        inflateTable(threshold);

        putAllForCreate(m);
}

我们在构造函数中传入的capacity实际上赋值给了threshold参数，而不是table数组真正的大小，table数组真正的大小在put第一个元素时

核心方法put()详解

put()

public V put(K key, V value) {
    	//判断table是否为EMPRT_TABLE
        if (table == EMPTY_TABLE) {
            //用大于threshold的2次幂初始化table
            inflateTable(threshold);
        }
    	//如果key为null
        if (key == null)
            return putForNullKey(value);
    	//对key进行hash
        int hash = hash(key);
    	//根据hash值确定数组下表，通过&操作获得
        int i = indexFor(hash, table.length);
    	//遍历链表，寻找key相同的元素，并且修改value
        for (Entry<K,V> e = table[i]; e != null; e = e.next) {
            Object k;
            if (e.hash == hash && ((k = e.key) == key || key.equals(k))) {
                V oldValue = e.value;
                e.value = value;
                //recordAccess空方法
                e.recordAccess(this);
                return oldValue;
            }
        }

        modCount++;
        addEntry(hash, key, value, i);
        return null;
    }

inflateTable()

如果是第一次put，在构造函数处我们传入的capacity赋值给了threshold，而threshold被传递到了toSize，我们的capacity才真正的起作用

private void inflateTable(int toSize) {
        // Find a power of 2 >= toSize寻找一个大于toSize的2次幂
        int capacity = roundUpToPowerOf2(toSize);
		//我们传入的capacity赋值给了threshold，然而此刻threshold又被修改了，hashMap老渣男了
        threshold = (int) Math.min(capacity * loadFactor, MAXIMUM_CAPACITY + 1);
        table = new Entry[capacity];
    	//哈希种子，跳过
        initHashSeedAsNeeded(capacity);
}

通过费劲心机的一通位运算，三目运算符，拿到了一个比在构造函数中传入的capacity大的二次幂，这是为啥呢？

为什么就非得是个二次幂？

这个问题等下hash回答

费劲心机的roundroundUpToPowerOf2()

private static int roundUpToPowerOf2(int number) {
    // assert number >= 0 : "number must be non-negative";
    int rounded = number >= MAXIMUM_CAPACITY
        ? MAXIMUM_CAPACITY
        : (rounded = Integer.highestOneBit(number)) != 0
            ? (Integer.bitCount(number) > 1) ? rounded << 1 : rounded
            : 1;

    return rounded;
}

解释一下上面的代码，可以说非常之精妙的了，由于里面参杂了大量的三目运算符使得看起来非常难受，下面用伪代码解释一下，其中以数字7举例，其二进制的后四位为：0111

if number>=MAXIMUM_CAPACITY
	rounded=number=MAXIMUM_CAPACITY
else
	//这里返回的是number二进制的最高位那个1，通俗点来说就是小于number的最大2次幂
	//会有详细分析JDK是如何操作的
	//rounded=0100=4
	rounded=Integer.hightestOneBit(number)
	if rounded！=0
		//这里统计了number二进制表示中1的个数,0111--3个1
		if Integer.bitCount(number)>1
			//如果超过1，则rounded左移一位就是大于num的最小二次幂，也就是1000--8>7
			rounded=rounded<<1
		else
			//如果==1，表明rounded==number
			rounded=rounded
	else
		//rounded为0，赋值为1
		rounded=1

其中highestOneBit()、bitCount()中包含了大量的位运算，非常的精妙，详解另一篇讲解(待补)

hash()

回到put方法中，在第一次放入时，我们已经创建好了table了，capacity也被我们设置好了，threshold也被重新设置了，然我们暂且忽略掉putForNullKey这个分支，进入hash方法，在这里也会了解为什么capacity非得是个二次幂

final int hash(Object k) {
    int h = hashSeed;
    if (0 != h && k instanceof String) {
        return sun.misc.Hashing.stringHash32((String) k);
    }

    h ^= k.hashCode();

    // This function ensures that hashCodes that differ only by
    // constant multiples at each bit position have a bounded
    // number of collisions (approximately 8 at default load factor).
    h ^= (h >>> 20) ^ (h >>> 12);
    return h ^ (h >>> 7) ^ (h >>> 4);
}

哈希方法最重要的性能考虑之一就是散，也就是尽量减少哈希碰撞

例如字符串jack的hashcode的表现形式为
1100011010011111011111

直接取这个hashcode值当作hash值行不行？当然可以，但是有问题

在了解了下面的indexFor方法之后，发现hashMap采用位运算的方式计算元素对应的下标，这样会有什么问题呢？

1100011010011111011111
xxxxxxxxxxxxxxxxxxx111

问题很明显了，如果后面111相同，在当前情况下，前面的29位不同都会被映射到同一个位置，这无疑导致了大量的哈希碰撞，那么为了弥补在indexFor中的过错，hash值的计算就需要尽可能综合所有bit的信息，所以hash方法中加入了扰动计算，算是为indexFor的高效擦屁股吧！

indexFor()

hashMap就是通过如下的方法来计算某个key所计算出来的hash已经对应到数组的哪个位置的，它相较于直接对length取余有何优势呢？

• 与操作速度比除法取余的方式更快
• 不用担心负数的问题

static int indexFor(int h, int length) {
    // assert Integer.bitCount(length) == 1 : "length must be a non-zero power of 2";
    return h & (length-1);
}

而着就要求length也就是capacity必须是一个二次幂

举例说明 8--1000 8-1=7=0111，前28位的0省略

任何hash值与0111进行于操作，它的值只能落在0000-0111之间，也就正好是数组的范围

这样做值得嘛？

值得，entry被放入map中之后，它的hash值也被保存到了自身的成员变量之中一般来说不会变化，直接访问即可，而在hashMap的最频繁调用的方法get()中，indexFor效率的提升肯定是非常棒的，因此牺牲hash的高效换取indexFor的高效无疑提高了整个HashMap的效率，何况hash中的操作也都是位运算

HashTable中的hash方法与index的计算

private int hash(Object k) {
    // hashSeed will be zero if alternative hashing is disabled.
    return hashSeed ^ k.hashCode();
}

int index = (hash & 0x7FFFFFFF) % tab.length;

可以看出hashTable则选择了较为朴素的实现，为什么hashTable不跟进效率高的实现呢？总的来说就是Hashtable和HashMap的容量选取策略不同

• hashtabl选取素数容量，默认为11，翻倍也是2*n+1的翻倍，素数的选择使得简单的取余分布就很均匀，这应该是数学上的知识了，不予证明
• hashMap选取二次幂作为初始容量，默认16，翻倍也是2倍的翻倍，通过位运算实现高效的index计算，但是需要扰动计算hash值

addEntry()

put方法中找不到相同的key，此时需要添加新的entry

void addEntry(int hash, K key, V value, int bucketIndex) {
    	//如果size超过了threhold，
        if ((size >= threshold) && (null != table[bucketIndex])) {
            //扩容扩容大小为原数组的两倍
            resize(2 * table.length);
            //扩容之后需要重新计算hash重新寻找index
            hash = (null != key) ? hash(key) : 0;
            bucketIndex = indexFor(hash, table.length);
        }
		//头插法插入链表
        createEntry(hash, key, value, bucketIndex);
}

头插法createEntry()

void createEntry(int hash, K key, V value, int bucketIndex) {
    Entry<K,V> e = table[bucketIndex];
    table[bucketIndex] = new Entry<>(hash, key, value, e);
    size++;
}

头插法导致的问题见

老生常谈之扩容

resize()

以两倍的容量扩张

void resize(int newCapacity) {
        Entry[] oldTable = table;
        int oldCapacity = oldTable.length;
        if (oldCapacity == MAXIMUM_CAPACITY) {
            threshold = Integer.MAX_VALUE;
            return;
        }
		//resize(2 * table.length);
        Entry[] newTable = new Entry[newCapacity];
    	//转移数据
        transfer(newTable, initHashSeedAsNeeded(newCapacity));
        table = newTable;
        threshold = (int)Math.min(newCapacity * loadFactor, MAXIMUM_CAPACITY + 1);
}

transfor()

void transfer(Entry[] newTable, boolean rehash) {
        int newCapacity = newTable.length;
        for (Entry<K,V> e : table) {
            //拷贝数组
            while(null != e) {
                Entry<K,V> next = e.next;
                //如果需要重新hash的话则重新hash
                if (rehash) {
                    e.hash = null == e.key ? 0 : hash(e.key);
                }
                int i = indexFor(e.hash, newCapacity);
                //头插法
                e.next = newTable[i];
                newTable[i] = e;
                e = next;
            }
        }
}

为什么扩容之后要重新对元素进行hash然后再散列呢？

举例：

扩容前

length=16

h= 0001 1001

& 0000 1111

= 0000 1001=9

扩容后

h= 0001 1001

& 0001 1111

= 0001 1001=25

可见扩容之后的位置有两种情况：1.原位置不动 2.向后移动原数组长度个位置。因此，扩容之后在对数据进行复制的时候需要重新计算hash和index，这样的扩容能够实现对链表长度的削减，以提高整体HashMap的查询效率