为什么HashMap在jdk1.7下是线程不安全的?
HashMap为什么在并发情况下访问使用get函数会造成环?
因为首先扩容时的transfer函数由于头插法造成了环,从而导致在使用get函数进行访问的时候出现CPU飙升的情况。
首先看下transfer函数:
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;
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;
}
}
}
先看下put过程:
hashmap的put函数过程
-
计算桶的位置:根据hashcode进行计算哈希值也就是哈希桶的位置
-
插入节点:根据上部计算出来的哈希值进行定位到桶的位置,查看相应的桶位置是否已经存在元素,如果存在元素的话就进行遍历链表进行查看是否有链表结点的keyt等于待插入的结点,如果存在的话就直接进行覆盖其value值。否则就进行插入一个新的结点,注意在jdk1.7的时候使用的头插法。即先取出当前哈希桶位置的元素,也就是链表的第一个结点,然后new一个新的结点,并将原始链表的第一个结点传给当前的新结点,即设置新结点的next指向原来的头结点。然后再将哈希表的长度增加1,之后再判断是够应该扩容。
-
扩容:主要是调用resize方法,在该方法中new一个大的数组,然后再调用transfer方法。注意table数组的引用是hashmap的成员变量,transfer的过程就是对table数组中的每一个槽对应的链表进行迁徙复制的过程。
这个迁徙复制的过程其实就是向新的table中进行头插的过程。头插法的过程主要是:
-
假设待转移的结点是e,先获取保留旧的链表的当前的结点的next结点
-
计算e的在新表中的哈希位置,定位到新表的哈希槽的位置之后,以头插法的方式插入即将e的next指针指向新的当前的哈希槽的元素(链表的旧头结点),并将哈希的位置赋值为e即由e来充当新的头结点。然后更新e为第一步保存的next结点,接着循环的后续的复制迁移过程,一直到e为空,即当前的槽链表复制完全。
-
hashmap在高并发下的环链问题
主要是transfer函数的过程。
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;//线程1执行到此挂起了
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;
}
}
}
主要原因:
假设有两个线程,线程1和线程2(注意每一个线程都有自己的newtable但是却共享老的table包括table中的链表接结点):
线程1目前指向了e, 且保留了next=7之后即停留在结点e=3的位置,挂起了,此时线程2正常完成了迁移过程。
然后线程1接着工作,将7头插到自己的newtable的某一个哈希槽的头结点,然后接着进行迁徙下一个节点即7的next结点,在单线程下其实7的next结点已经为空了,但是由于线程2事先完成了头插,造成7的next为3,所以此时对线程1来说,7是指向3的,然后线程1又要把3以头插的方式插入到自己的newtable中,即造成了3指向了7。最终3指向7,7指向3,然后就造成了环。
参考博文
https://coolshell.cn/articles/9606.html