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…

JDK1.8中的HashMap实现跟JDK1.7中的实现有很大差别.下面分析JDK1.8中的实现,主要看put和get方法. 构造方法的时候并没有初始化,而是在第一次put的时候初始化 putVal方法的主要逻辑是这样的: 1.如果数组还没有初始化(数组长度是0),则先初始化 2.通过hash方法计算key的hash值,进而计算得到应该放置到数组的位置 3.如果该位置为空,则直接放置此处 4.如果该位置不为空,而且元素是红黑树,则插入到其中 5.如果是链表,则遍历链表,如果找到相等的元素则替换,…

一.JDK1.7中HashMap扩容死锁问题 我们首先来看一下JDK1.7中put方法的源码 我们打开addEntry方法如下,它会判断数组当前容量是否已经超过的阈值,例如假设当前的数组容量是16,加载因子为0.75,即超过了12,并且刚好要插入的索引处有元素,这时候就需要进行扩容操作,可以看到resize扩容大小是原数组的两倍,仍然符合数组的长度是2的指数次幂 我们再进入resize方法如下,它首先会对之前的数组容量进行判断,看是否已经达到了数组最大容量,如果没有,后面会进行数组的转移操作,即…

现象: 测试提了一个bug,我完全复现不了,但是最吊诡的是在其他人的机器上都可以复现.起初以为是SVN合并后出现的冲突,后来经过对比法排查: step 1: 我本地开两个jetty,一个跑合并之前的版本,一个跑合并之后的版本,数据库.redis配置都一样的,结果一致,由此可以推测应该不是代码的问题. step 2: 我电脑和别人电脑同样的配置.连的一个数据库,同样的代码.同样的数据,得到了两个结果,我这里是正常的,而且除了我其它人都可以复现,我喵了狗.... 我还一度以为是灵异现象....o(╯…

一.数据结构 HashMap中的数据结构是数组+单链表的组合,以键值对(key-value)的形式存储元素的,通过put()和get()方法储存和获取对象. (方块表示Entry对象,横排表示数组table[],纵排表示哈希桶bucket[实际上是一个由Entry组成的链表,新加入的Entry放在链头,最先加入的放在链尾],) 二.实现原理 成员变量 源码分析: /** 初始容量,默认16 */ static final int DEFAULT_INITIAL_CAPACITY = 1 <<…

背景 在1.7之前的版本,当数组元素较多(几百.几千,或者更多)的时候,在这种前提扩容,涉及全量元素的遍历和坐标的重新定位,这个耗时会比较长.这是之前存在的一个弊端吧.那么引入红黑树之后就解决了问题,那是怎么解决的呢,我说下自己的理解. 过程分析 既然数组扩容导致了变慢,那就是从扩容方向思考,谁决定了扩容呢?负载因子和数组长度.数组长度是resize自动做的,所以对用户来讲这应该是一个关注不到的变量,那就只剩负载因子了.负载因子越大,扩容的频率就越低. 1. 负载因子较小(小于1) hash碰撞…

当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…

趴源码是看到一段不可思议的代码,网上的解释似乎不大令人满意,因此稍微花点时间解读了一下,如有错误请指正 HashMap的桶是这样搞的 // 片段1 static final int hash(Object key) { int h; return (key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16); } // 片段2 int n = tab.length; int index = (n - 1) & hash; index就…

在扩容时 transfer( ) 方法中 newTable 新数组 局部变量 table 旧数组 全局变量 当第一个链表进行while循环时 执行到 e.next = newTable[i]; 时 newTable[i]肯定为null. 导致 旧数组table 中 当前链表对象的next已经为null了 . 所以即使是多线程的情况下不会死循环…

在分析jdk1.7中HashMap的hash冲突时,不知大家是否有个疑问就是万一发生碰撞的节点非常多怎么版?如果说成百上千个节点在hash时发生碰撞,存储一个链表中,那么如果要查找其中一个节点,那就不可避免的花费O(N)的查找时间,这将是多么大的性能损失.这个问题终于在JDK1.8中得到了解决,在最坏的情况下,链表查找的时间复杂度为O(n),而红黑树一直是O(logn),这样会提高HashMap的效率. jdk1.7中HashMap采用的是位桶+链表的方式,即我们常说的散列链表的方式,而jdk1…