仅供自己复习
数据结构分析
| JDK1.7 | JDK1.8 | |
|---|---|---|
| 底层数据结构 | 数组 + 链表 | 数组+链表/红黑树 |
| 冲突解决方法 | 拉链法 | “改进的”拉链法。当链表长度大于TREEIFY_THRESHOLD时，链表转为红黑树 |
// jdk1.8
public class HashMap extends AbstractMap
implements Map, Cloneable, Serializable {
transient Node[] table;
/**
* Basic hash bin node, used for most entries. (See below for
* TreeNode subclass, and in LinkedHashMap for its Entry subclass.)
*/
static class Node implements Map.Entry {
final int hash;
final K key;
V value;
Node next;
....
}
static final class TreeNode extends LinkedHashMap.Entry {
TreeNode parent; // red-black tree links
TreeNode left;
TreeNode right;
TreeNode prev; // needed to unlink next upon deletion
boolean red;
TreeNode(int hash, K key, V val, Node next) {
super(hash, key, val, next);
}
}
重点参数讲解
| 参数 | 作用 |
|---|---|
size |
HashMap已经插入了键值对的个数，当size>threshold时，执行扩容 |
initialCapacity |
初始化容量。该参数并不是HashMap的成员变量 |
threshold |
扩容的阈值。该值=capacity * load factor |
loadFactor |
负载因子 |
TREEIFY_THRESHOLD |
链表转树的阈值，默认是8，类型是static final int |
UNTREEIFY_THRESHOLD |
树转链表的阈值，默认是6 |
modCount |
HashMap发生结构性修改的次数。作用于fast-fail机制：在进行序列化或者迭代等操作时，比较操作前后 modCount 是否改变，若改变，则抛出 ConcurrentModificationException。 |
关于红黑树和链表转换一些细节
1）链表转红黑树
- 时机：发生在链表长度大于等于 8 时
- 原因：此时，红黑树的平均查找长度为 O(log n)=3 < 链表平均查找长度 O(n/2)=4。
- 发生：插入时进行判断与转换
2）红黑树转链表
- 时机：红黑树节点数小于等于 6 时
- 原因：链表平均查找长度更小。
- 发生：删除节点时进行判断和转换
如果留心点，会发现两个临界值之间隔了一个 7。原因是由于转换操作比较耗时，中间隔个 7，可以防止转换操作过于频繁。
假设一下，如果设计成链表个数超过8则链表转换成树结构，链表个数小于8则树结构转换成链表，如果一个HashMap不停的插入、删除元素，链表个数在8左右徘徊，就会频繁的发生树转链表、链表转树，效率会很低。
重点函数分析
哈希值计算hash()
在这方面，JDK1.8 也作为优化。
JDK1.7 的 hash() = hashCode() + 扰动操作（包括4次位运算 + 5次异或运算）
JDK1.8 的 hash() = hashCode() + 扰动操作（包括1次位运算 + 1次异或运算）
PS：扰动操作的作用是「加大哈希码低位的随机性，使得分布更均匀，从而提高对应数组存储下标位置的随机性 & 均匀性，最终减少Hash冲突」
// JDK 1.7实现：将 key 转换成 哈希码（hash值）操作 = 使用hashCode() + 4次位运算 + 5次异或运算（9次扰动）
static final int hash(int h) {
h ^= k.hashCode();
h ^= (h >>> 20) ^ (h >>> 12);
return h ^ (h >>> 7) ^ (h >>> 4);
}
// JDK 1.8实现：将 键key 转换成 哈希码（hash值）操作 = 使用hashCode() + 1次位运算 + 1次异或运算（2次扰动）
static final int hash(Object key) {
int h;
return (key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16);
}
插入操作putVal()
插入流程图[4]
源码节选：
final V putVal(int hash, K key, V value, boolean onlyIfAbsent,
boolean evict) {
Node[] tab; Node p; int n, i;
// 1）第一次执行put，才为hashmap分配空间
if ((tab = table) == null || (n = tab.length) == 0)
n = (tab = resize()).length;
// 2）插入的key在数组的下标值 i=(n-1)&hash
// 如果tab[i]==null，直接插入
if ((p = tab[i = (n - 1) & hash]) == null)
tab[i] = newNode(hash, key, value, null);
// 3）如果tab[i]!=null，则向链表或红黑树中插入
else {
Node e; K k;
// 4）判断对应数组上的元素的key与插入的key相等，
// 相等则代替。
if (p.hash == hash && ((k = p.key) == key || (key != null && key.equals(k))))
e = p;
// 5）不相等，且数组上的元素是树节点，则插入到树中
else if (p instanceof TreeNode)
e = ((TreeNode)p).putTreeVal(this, tab, hash, key, value);
// 6）不相等，且数组上的元素是链表节点，则插入到链表中
else {
// 7）遍历链表，找相等的节点。找不到就指向最后一个节点
for (int binCount = 0; ; ++binCount) {
// i.说明走到了链表尾部，则代表没找到，就直接插入
if ((e = p.next) == null) {
p.next = newNode(hash, key, value, null);
// 插入完成后，计算链表长度，如果大于阈值，转换为树
if (binCount >= TREEIFY_THRESHOLD - 1) // -1 for 1st
treeifyBin(tab, hash);
break;
}
// ii. 找到相等的节点，就推出循环
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; // 记录map的结构性修改
// 8）当map的键值对大于阈值，则扩容。
if (++size > threshold)
resize();
afterNodeInsertion(evict); // 插入成功后会调用该方法。默认实现为空
return null;
}
扩容操作resize()
final Node[] resize() {
// 1）保存当前数组以及相关参数。下面称为旧数组
Node[] oldTab = table;
int oldCap = (oldTab == null) ? 0 : oldTab.length;
int oldThr = threshold;
int newCap, newThr = 0;
// 2）容量扩展的两种情况：
// i. 旧容量已经达到最大值，就不扩容了
// ii. 如果没达到，就扩大 1 倍。
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
}
// 3）此处代表map尚未初始化（因为容量小于0），故此这两个else都是为新map初始化
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;
// 4）创新新的数组，并指向它
@SuppressWarnings({"rawtypes","unchecked"})
Node[] newTab = (Node[])new Node[newCap];
table = newTab;
if (oldTab != null) {
// 5）遍历旧数组，将元素搬迁到新数组中
for (int j = 0; j < oldCap; ++j) {
Node e;
if ((e = oldTab[j]) != null) {
oldTab[j] = null; // 释放旧数组的空间
// 6）根据当前遍历到的节点类型，选择搬迁到新数组的方法
// i: 当前节点后面没有链表/树，直接插入到新数组
// ii: 当前节点是一棵树，则遍历每个节点计算他们的新位置。而链表中的节点新位置只有两种可能
// iii: 当前节点是链表，则遍历每个节点计算他们的新位置。而链表中的节点新位置只有两种可能
if (e.next == null)
newTab[e.hash & (newCap - 1)] = e;
else if (e instanceof TreeNode)
((TreeNode)e).split(this, newTab, j, oldCap); // 将节点一分为二。因为新位置只有两种可能。
else { // preserve order
Node loHead = null, loTail = null; // 存放节点在新数组的下标=原下标
Node hiHead = null, hiTail = null; // 存放节点在新数组的下标=原下标+旧容量
Node 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;
}
还有一个关键点。
- 不管是同一棵树或者同一个链表，每个节点的 hash() 一定相等的，只不过是每个节点之间 equals() 不相等。
- 扩容后元素的新数组下标只有两种情况：
- 扩容后，若hash() 新增参与运算的位=0，新数组下标=原下标
- 扩容后，若hash() 新增参与运算的位=1，新数组下标=原下标+扩容前的旧容量
- 相关证明见[2]
线程不安全原因
本质：其中一个线程扩容进行了一个部分被挂起了，另一个线程获取资源并完成扩容后，链表的节点的 next 指针已经发生了改变，导致切换回挂起的线程继续扩容时，会出现数据丢失或循环链表的情况。
JDK1.7 和 JDK1.8 的 HashMap 都是线程不安全的。但只查阅到 JDK1.7 resize() 引发的死循环的例子，故此下例是基于 JDK1.7 的。
举个例子说明一下，例子来源于[3]。
1）假设 HashMap 现有数据如下图所示，数组大小为2，故此插入到需要扩容。
2）在单线程情况，扩容后的结果如下：
3）在多线程，扩容就可能产生循环链表或者丢失数据。问题的根源在于 tranfer()。
void transfer(Entry[] newTable) {
Entry[] src = table;
int newCapacity = newTable.length;
for (int j = 0; j < src.length; j++) {
Entry e = src[j];
if (e != null) {
src[j] = null;
do {
Entry next = e.next; // 最最最关键的代码
int i = indexFor(e.hash, newCapacity);
e.next = newTable[i];
newTable[i] = e;
e = next;
} while (e != null);
}
}
}
扩容，死循环的产生过程
扩容时，丢失数据的产生过程
PS：
- 线程 1 和线程 2 操作的是同一个 HashMap，因此线程 2 先完成，修改了结构。线程 1 最初记录已经不准确了，再根据之前的记录修改 HashMap，则发生错误。
- 当发生死循环时，会造成CPU利用率达到100%
- JDK1.8 改为尾插入，能够避免1.7的上述类型的死循环。但依旧会出现死循环
- 实例：JDK8中HashMap依然会产生死循环问题！
JDK1.8和JDK1.7对比
相比于 JDK1.7，JDK1.8 的 HashMap 做了如下的调整优化：
| 主要区别 | JDK1.7 | JDK1.8 |
|---|---|---|
| 数据结构 | 数组+链表 | 数组+链表/红黑树 |
| 插入操作 | 当发生冲突时，采用“头插法”插入到链表中 | 当发生冲突时，插入到树中或者采用“尾插法”插入到链表中 |
| 初始化容量 | 调用inflateTable() | 集成到resize() |
| 计算哈希 | 扰动操作更多 | 扰动操作更少 |
PS:
- 头插法即插入在链表的头部；尾插法即插入在链表的尾部。
- 头插法会导致链表倒序，即原本是 1->2->3，扩容后变成 3->2->1。
- 还有一些小的改动，比如说 JDK1.7 和 JDK1.8 对 key 的哈希值计算有些许的优化调整，详见[2]
常见问题讲解
Q：HashMap容量为什么一定是2的幂次方？
前提：HashMap 容量指的是 table 的大小。
原因：提高 HashMap 的计算 key 的哈希值的速度，从而提高 HashMap 的存取速度。因为当 table 的大小是 2 的幂次方时，计算哈希用的取余操作，可换算为位运算，从而提高速度。
// 为什么hashMap大小一定是2的幂次方。
// 原因：提高存取速度（更细：提高搜索数组下标的速度）
// 原本：一般计算数组下标：通过取余
int h = hash(key.hashCode());
int index = h % table.size();
// 改进:当table.size()为2的幂次方时计算数组下标：通过位运算
int h = hash(key.hashCode());
int index = h & (table.size()-1);
Q：为什么String和Integer等包装类适合作为 key？
原因：String和Integer等包装类具有不变性，从而保证 key 具有不变性。
Q：如何自定义类要作为key，需要重写哪些方法？
需要重写的方法：hashcode() 和 equals()。这两个函数在 get() 和 put() 都用到，用于判断传入的 key 与 HashMap 保存的 key 是否有相等。
比如，在 put() 的用法：
- 数组的索引：取决于 key 的 hashcode。
- 当两个元素的 hashcode 相同时，然后再判断 equals() 返回值
- 当 equals() == true，覆盖原有的值
- 当 equals() == false，插入到链表/红黑树。这就是 hash 冲突的解决方法。
Q：HashMap 实现同步的方法有哪些？
1） 使用 Collections.synchronizedMap(HashMap)
2） 使用 HashTable
3） 使用 ConcurrentHashMap
Q：Collections.synchronizedMap(HashMap)如何实现同步？
答案：Collections.synchronizedMap(HashMap) 得到的对象中有一个锁变量 mutex，然后所有操作进行加锁 synchronized(mutex)
public static Map synchronizedMap(Map m) {
return new SynchronizedMap<>(m);
}
/**
* @serial include
*/
private static class SynchronizedMap implements Map, Serializable {
private final Map m; // Backing Map
final Object mutex; // Object on which to synchronize
public int size() {synchronized (mutex) {return m.size();} }
public boolean isEmpty() { synchronized (mutex) {return m.isEmpty();} }
public boolean containsKey(Object key) { synchronized (mutex) {return m.containsKey(key);} }
public boolean containsValue(Object value) { synchronized (mutex) {return m.containsValue(value);} }
public V get(Object key) { synchronized (mutex) {return m.get(key);} }
public V put(K key, V value) { synchronized (mutex) {return m.put(key, value);} }
public V remove(Object key) { synchronized (mutex) {return m.remove(key);} }
public void putAll(Map map) { synchronized (mutex) {m.putAll(map);} }
...
}
参考文献
[1] Java：手把手带你源码分析 HashMap 1.7_Java,集合,HashMap_专注分享 Android开发 干货-CSDN博客
[2] Java源码分析：关于 HashMap 1.8 的重大更新_专注分享 Android开发 干货-CSDN博客
[3] [HashMap]HashMap死循环与元素丢失（一） - 技术栈 - OSCHINA
[4] Java 8系列之重新认识HashMap -