jdk1.8中hashmap的扩容resize】的更多相关文章

当hashmap第一次插入元素.元素个数达到容量阀值threshold时,都会扩容resize(),源码: (假设hashmap扩容前的node数组为旧横向node数组,扩容后的node数组为新横向node数组) 1 final Node<K,V>[] resize() { 2 Node<K,V>[] oldTab = table; 3 int oldCap = (oldTab == null) ? 0 : oldTab.length; 4 int oldThr = thresho…
一.JDK1.7中HashMap扩容死锁问题 我们首先来看一下JDK1.7中put方法的源码 我们打开addEntry方法如下,它会判断数组当前容量是否已经超过的阈值,例如假设当前的数组容量是16,加载因子为0.75,即超过了12,并且刚好要插入的索引处有元素,这时候就需要进行扩容操作,可以看到resize扩容大小是原数组的两倍,仍然符合数组的长度是2的指数次幂 我们再进入resize方法如下,它首先会对之前的数组容量进行判断,看是否已经达到了数组最大容量,如果没有,后面会进行数组的转移操作,即…
JDK1.8中的HashMap实现跟JDK1.7中的实现有很大差别.下面分析JDK1.8中的实现,主要看put和get方法. 构造方法的时候并没有初始化,而是在第一次put的时候初始化 putVal方法的主要逻辑是这样的: 1.如果数组还没有初始化(数组长度是0),则先初始化 2.通过hash方法计算key的hash值,进而计算得到应该放置到数组的位置 3.如果该位置为空,则直接放置此处 4.如果该位置不为空,而且元素是红黑树,则插入到其中 5.如果是链表,则遍历链表,如果找到相等的元素则替换,…
一.数据结构 HashMap中的数据结构是数组+单链表的组合,以键值对(key-value)的形式存储元素的,通过put()和get()方法储存和获取对象. (方块表示Entry对象,横排表示数组table[],纵排表示哈希桶bucket[实际上是一个由Entry组成的链表,新加入的Entry放在链头,最先加入的放在链尾],) 二.实现原理 成员变量 源码分析: /** 初始容量,默认16 */ static final int DEFAULT_INITIAL_CAPACITY = 1 <<…
JDK 1.8 中 HashMap 的 hash 算法和寻址算法 HashMap 源码 hash() 方法 static final int hash(Object key) { int h; return (key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16); } h = key.hashCode() 表示 h 是 key 对象的 hashCode 返回值: h >>> 16 是 h 右移 16 位,因为 int…
/** * Initializes or doubles table size. If null, allocates in * accord with initial capacity target held in field threshold. * Otherwise, because we are using power-of-two expansion, the * elements from each bin must either stay at same index, or mo…
在扩容时 transfer( ) 方法中 newTable 新数组 局部变量 table 旧数组 全局变量 当第一个链表进行while循环时 执行到 e.next = newTable[i]; 时 newTable[i]肯定为null. 导致 旧数组table 中 当前链表对象的next已经为null了 . 所以即使是多线程的情况下不会死循环…
背景 在1.7之前的版本,当数组元素较多(几百.几千,或者更多)的时候,在这种前提扩容,涉及全量元素的遍历和坐标的重新定位,这个耗时会比较长.这是之前存在的一个弊端吧.那么引入红黑树之后就解决了问题,那是怎么解决的呢,我说下自己的理解. 过程分析 既然数组扩容导致了变慢,那就是从扩容方向思考,谁决定了扩容呢?负载因子和数组长度.数组长度是resize自动做的,所以对用户来讲这应该是一个关注不到的变量,那就只剩负载因子了.负载因子越大,扩容的频率就越低. 1. 负载因子较小(小于1) hash碰撞…
在分析jdk1.7中HashMap的hash冲突时,不知大家是否有个疑问就是万一发生碰撞的节点非常多怎么版?如果说成百上千个节点在hash时发生碰撞,存储一个链表中,那么如果要查找其中一个节点,那就不可避免的花费O(N)的查找时间,这将是多么大的性能损失.这个问题终于在JDK1.8中得到了解决,在最坏的情况下,链表查找的时间复杂度为O(n),而红黑树一直是O(logn),这样会提高HashMap的效率. jdk1.7中HashMap采用的是位桶+链表的方式,即我们常说的散列链表的方式,而jdk1…
​ HashMap本质上Java中的一种数据结构,他是由数组+链表的形式组织而成的,当然了在jdk1.8后,当链表长度大于8的时候为了快速寻址,将链表修改成了红黑树. ​ 既然本质上是一个数组,那我们应该把对应的键值对放到数组的哪个位置就成了重中之重,因为要保证这个算法对同一个key在同一个数组中每次计算出来的结果的一致性进行保证(幂等性).那有的同学就要说了,很简单啊,我们获取key的hashCode然后将结果和数组长度进行取模就可以了. ​ 这个办法的确可行,但是jdk中是这样做的吗?为什么…