java文章分享
2017-08-10 11:27

一直以来，HashMap就是Java面试过程中的常客，不管是刚毕业的，还是工作了好多年的同学，在Java面试过程中，经常会被问到HashMap相关的一些问题，而且每次面试都被问到一些自己平时没有注意的问题。因为HashMap不管对于毕业生，还是对于老司机来说，都非常熟悉，熟悉到你经常忽略它。

本着知其然，更要知其所以然的精神，本人对JDK 1.8版本的HashMap源码进行了仔细的学习。大家知道，JDK 1.8中HashMap的实现有了一些改进，特别是数据存储结构引进了红黑树，使得查询更加的快捷，本文也会对相应的内容进行分析，希望大家能有收获。

一、HashMap基础

1.1 HashMap的定义

话不多说，首先从HashMap的一些基础开始。我们先看一下HashMap的定义：

public class HashMap<K,V> extends AbstractMap<K,V> implements Map<K,V>, Cloneable, Serializable1

我们可以看出，HashMap继承了AbstractMap

1.2 HashMap的属性

接着，我们通过源码看看HashMap的一些重要的常量属性。

这里我们要知道<<运算符的意义，表示移位操作，每次向左移动一位(相对于二进制来说)，表示乘以2，此处1<<4表示00001中的1向左移动了4位，变成了10000，换算成十进制就是2^4=16，也就是HashMap的默认容量就是16。Java中还有一些位操作符，比如类似的>>(右移)，还有>>>(无符号右移)等，也是需要我们掌握的。这些位操作符的计算速度很快，我们在平时的工作中可以使用它们来提升我们系统的性能。

这里我们需要加载因子(load_factor)，加载因子默认为0.75，当HashMap中存储的元素的数量大于(容量×加载因子)，也就是默认大于16*0.75=12时，HashMap会进行扩容的操作。

二、初始化

一般来说，我们初始化的时候会这样写：

Map<K,V> map = new HashMap<K,V>();

这个过程发生了什么呢？我们看看源码。

我们debug跟踪时，会发现，这里的initialCapacity并不是我们想象的16，而是31，并且会变化几次之后，initialCapacity最终变成了11，这是为什么呢？说实话，我也不清楚，希望有大神可以帮忙解答。

我们继续。初始化时，会首先判断初始容量是否小于0，如果小于0，会抛出异常。接着，判断初始容量是否大于最大的容量(即2^31)，如果大于，将初始容量设置为最大初始容量。紧接着，判断加载因子：如果小于等于0，或者不是一个数字，都会抛出异常。等这些校验完成之后，会将HashMap的加载因子和扩容的阈值设置上。这里需要注意一下，threshold(阈值)=capacity*loadFactor。而我们的阈值是怎么来的呢？我们看一下tableSizeFor()这个方法。

我们可以看到英文注释：Returns a power of two size for the given target capacity.(返回目标容量对应的2的幂次方。)我们可以想象一下，如果我们将初始值设置为非2的幂次方的数值，比如我们设置为19，最终我们通过这个方法，得到的数组大小是多少呢？我们可以计算一下。

因为cap最大为2^31，我们可以知道，这个方法的最终目的就是返回比cap大的最小的2的幂次方。

三、put()

下面，我们开始解析HashMap中最重要的一个方法:put()。

下面我们首先看一下hash(key)，然后再看一下putVal()方法，这两个方法是精髓。

3.1 hash(key)

先上源码：

我们可以发现，当key=null时，也是有hash值的，是0，所以，HashMap的key是可以为null的，对比HashTable源码我们可以知道，HashTable的key直接进行了hashCode，如果key为null时，会抛出异常，所以HashTable的key不可以是null。

我们还能发现hash值的计算，首先计算出key的hashCode()为h，然后与h无条件右移16位后的二进制进行按位异或(^)得到最终的hash值，这个hash值就是键值对存储在数组中的位置。

备注：异或的操作如下：0 ^ 0=0，1 ^ 1 =0，0 ^ 1=1，1 ^ 0=1，也就是相同时返回0，不同时返回1。

我们目前不去深究为什么这么设计，我们只要知道，这样设计的目的是为了让hash值分布的更加均匀即可。

3.2 putVal()方法

3.2.1 源码

我们直接看源码。

我们慢慢来分析。首先看入参：

• hash：表示key的hash值

• key：待存储的key值

• value：待存储的value值，从这个方法可以知道，HashMap底层存储的是key-value的键值对，不只是存储了value

• onlyIfAbsent：这个参数表示，是否需要替换相同的value值，如果为true，表示不替换已经存在的value

• evict：如果为false，表示数组是新增模式

我们看到put时所传入的参数put(hash(key), key, value, false, true)，可以得到相应的含义。

3.2.2 HashMap的数据结构

在继续下一步分析之前，我们首先需要看一下HashMap底层的数据结构。

我们可以看到，HashMap底层是数组加单向链表或红黑树实现的(这是JDK 1.8里面的内容，之前的版本纯粹是数组加单向链表实现)。

下面我们看一下HashMap的一些重要的内部类。首先最重要的就是Node类，即HashMap内部定义的单向链表

我们重点看一下数据结构，Node中存储了key的hash值，键值对，同时还有下一个链表元素。我们重点关注一些equals这个方法，这个方法在什么时候会用到呢？当我们算出的key的hash值相同时，put方法并不会报错，而是继续向这个hash值的链表中添加元素。我们会调用equals方法来比对key和value是否相同，如果equals方法返回false，会继续向链表的尾部添加一个键值对。

当然，在JDK 1.8中引入了红黑树的概念，内部定义为TreeNode，对红黑树感兴趣的同学可以看看相关的文档，引入红黑树是为了提升查询的效率。

3.2.3 继续分析putVal()方法

首先判断当前HashMap的数组是否为空，如果为空，则调用resize()方法，对HashMap进行扩容，这次扩容的结果就是HashMap的初始化一个长度为16的数组。获取到数组的长度n。代码如下：

接着，根据长度-1和hash值进行按位与运算，算出hash值对应于数组中的位置，从tab中将这个位置上面的内容取出，判断为null时，在这个位置新增一个Node。代码如下：

如果同样的位置取到了数据，也就是这个hash值对应数组的位置上面已经有了键值对存在，这时候我们就需要做一些动作了。首先，我们判断这个Node，也就是p的hash值是否与传入的hash相等，然后接着判断key是否相等(这里判断key是否相等，用了一个或运算)。如果判断通过，表示要传入的key-val键值对就是tab[i]位置上面的键值对，直接替换即可，不用管后面是链表还是红黑树。代码如下：

如果tab[i]的key不是我们传入的key，下面我们首先要判断p这个Node是不是红黑树，如果是红黑树，直接向红黑树新增一个数据。向红黑树新增数据的代码我们后续再解析，目前先不进行分析。代码如下：

下面，当p是单向链表时，我们遍历链表进行插入等操作。找到链表的尾部，将节点新增到尾部。如果链表的长度大于等于红黑树化的阈值-1，就将桶(也就是链表)转成红黑树存储数据。如果在链表中还存在相同的key，直接替换旧的value即可。

最后，还有一个操作，大家千万不要忽略，也就是判断当前的键值对数量是否即将超过阈值，如果即将超过，需要进行resize()操作。

下一篇文章我们将着重分析resize()和get()的源码。

==========================================================================================

本文继续分析HashMap的源码。本文的重点是resize()方法和HashMap中其他的一些方法，希望各位提出宝贵的意见。

话不多说，咱们上源码。

上面一段代码的内容比较好理解，都已经根据注释就能看懂，主要的内容在下半部分：扩容后和扩容前，数据存放位置的变化。我们可以理解一下。

经过观测可以发现，我们使用的是2次幂的扩展(指长度扩为原来2倍)，所以，元素的位置要么是在原位置，要么是在原位置再移动2次幂的位置。看下图可以明白这句话的意思，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新增的优化点。有一点注意区别，JDK1.7中rehash的时候，旧链表迁移新链表的时候，如果在新表的数组索引位置相同，则链表元素会倒置，但是从上图可以看出，JDK1.8不会倒置。

小结

以上就是HashMap中比较重要的源码分析，希望大家能有所收获。高并发时，HashMap还有一些问题，具体是啥问题，大家搜一搜吧，后续可能会出相应的文章，届时再详细解析。所以，在高并发的情况下，还是尽量使用ConcurrentHashMap，后续也会对ConcurrentHashMap的源码进行解析，希望大家关注。