我觉得逼格高,不是体现在问题多刁钻,知识点多深,而是一个非常明确,无歧义的问题,能考察出面试者多方面的能力.这个问题背后:1.了解java中,HashMap的实现:如果一个面试者了解这一点,说明至少他关心过java提供的数据类型的实现,甚至极可能看过源码,他应该不会是一个纯粹的苦力.2.知道『不影响读写的情况下扩容』是什么含义,说明他在工作中了解多线程的相关知识.3.如果他能提到ConcurrentHashMap中的相关内容,说明他日常编程中有使用到concurrent包,可以继续聊聊,否则他对

转载请注明出处 http://www.cnblogs.com/yanzige/p/8392142.html 扩容必须满足两个条件: 1. 存放新值的时候当前已有元素的个数必须大于等于阈值 2. 存放新值的时候当前存放数据发生hash碰撞(当前key计算的hash值换算出来的数组下标位置已经存在值) 如果需要扩容,调用扩容的方法resize() void resize(int newCapacity) { Entry[] oldTable = table; int oldCapacity = ol

关于HashMap的扩容过程,请参考源码或百度. 我想记录的是1.8 HashMap扩容是对链表中节点的Hash计算分析. 对术语先明确一下: hash计算指的确定节点在table[index]中的链表位置index,不是节点的hash值. Node<K,V> loHead = null, loTail = null; //这两个是记录重新hash计算后仍在原位置(设为index)的节点 Node<K,V> hiHead = null, hiTail = null; //这两个是记

今天回顾hashmap源码的时候发现一个很有意思的地方,那就是jdk1.8在hashmap扩容上面的优化. 首先大家可能都知道,1.8比1.7多出了一个红黑树化的操作,当然在扩容的时候也要对红黑树进行重排,然而今天要说的并不是这个,而是针对数组中的链表项的处理优化. 关于hashmap的源码都十分精妙,有时间可以多看看. 首先上1.7的源码: void resize(int newCapacity) { Entry[] oldTable = table; int oldCapacity = ol

Java8的HashMap扩容过程主要就是集中在resize()方法中 final Node<K,V>[] resize() { // ...省略不重要的 } 其中,当HashMap扩容完毕之后,需要对原有的数据进行转移.因为容量变大了,部分元素的位置因此要变更,因而出现了下面的这个转移过程. 转移过程大致是:依次从旧数组里取值,然后从该值对应的链表上依次取出节点,对节点取模分别放入lo链表和hi链表,当链表中节点遍历完后,分别把lo链表和hi链表放入新数组的不同位置. 在看到如下第15行时,

原文:https://blog.csdn.net/Leon_cx/article/details/81911223 下面我们来模拟一下多线程场景下扩容会出现的问题: 假设在扩容过程中旧hash桶中有一个单链表,单链表中只有一个节点A,也就是e引用的对象.新hash桶中有一个单链表,单链表中的节点是B->C,也就是newTable[i]引用的对象. 单线程扩容如果只有一个线程在执行扩容: - 执行到第 3 行next = e.next的时候next == null - 从第 5 行到第 9 行会将

ArrayList扩容策略:默认10 扩容时是base + base/2, 即10 15 22 33 49...扩容时不安全:grow方法扩容时,赋值 elementData = Arrays.copyOf(elementData, newCapacity)时,若两个线程都进入这个地方,会导致快的赋值被慢的覆盖,导致跳号 HashMap扩容策略:容量默认16 loadFactor默认0.75 必须大于0容量扩容是16*2,若初始知道容量,也会resize为2的幂次大小,然后每次乘以2 loadF

一.HashSet保证元素唯一原理: 依赖于hashCode()和equals()方法1.唯一原理: 1.1 当HashSet集合要存储元素的时候,会调用该元素的hashCode()方法计算哈希值 1.2 判断该哈希值对应的位置上,是否有元素 1.3 如果该哈希值位置上没有元素,那么就直接存储该元素 1.4 如果该哈希值位置上有元素,那么就产生了哈希冲突 1.5 如果产生了哈希冲突,就得调用该元素的equals()方法,和该位置上的所有元素进行一一比较:       如果有任何一个元素与该元素相

HashMap: public HashMap(int initialCapacity, float loadFactor) { //初始容量不能<0 if (initialCapacity < 0) throw new IllegalArgumentException("Illegal initial capacity: " + initialCapacity); //初始容量不能 > 最大容量值,HashMap的最大容量值为2^30 if (initialCapa

  1.如果HashMap的大小超过了负载因子(load factor)定义的容量,怎么办? 默认的负载因子大小为0.75,也就是说,当一个map填满了75%的bucket时候,和其它集合类(如ArrayList等)一样,将会创建原来HashMap大小的两倍的bucket数组,来重新调整map的大小,并将原来的对象放入新的bucket数组中.这个过程叫作rehashing,因为它调用hash方法找到新的bucket位置.这个值只可能在两个地方,一个是原下标的位置,另一种是在下标为<原下标+原容量

JDK1.7 VS JDK1.8 比较 优化概述: resize 扩容优化 引入了红黑树,目的是避免单条链表过长而影响查询效率 解决了resize时多线程死循环问题,但仍是非线程安全的 这里主要讲讲扩容优化,死循环问题看笔记 扩容优化 下面我们讲解下JDK1.8做了哪些优化.经过观测可以发现,我们使用的是2次幂的扩展(指长度扩为原来2倍),所以,元素的位置要么是在原位置,要么是在原位置再移动2次幂的位置.看下图可以明白这句话的意思,n为table的长度,图(a)表示扩容前的key1和key2两种

JDK1.7中,resize时,index取得时,全部采用重新hash的方式进行了.JDK1.8对这个进行了改善. 以前要确定index的时候用的是(e.hash & oldCap-1),是取模取余,而这里用到的是(e.hash & oldCap),它有两种结果,一个是0,一个是oldCap, 比如oldCap=8,hash是3,11,19,27时,(e.hash & oldCap)的结果是0,8,0,8,这样3,19组成新的链表,index为3:而11,27组成新的链表,新分配的

1.什么是resize: resize就是重新计算容量:当我们不断的向HashMap对象里不停的添加元素时,HashMap对象内部的数组就会出现无法装载更多的元素,这是对象就需要扩大数组的长度,以便能装入更多的元素:当然Java里的数组是无法自动扩容的,方法是使用一个新的数组代替已有的容量小的数组:就像我们用一个小桶装水,如果想装更多的水,就得换大水桶. 2.什么时候需要resize(): 当向容器添加元素的时候,会判断当前容器的元素个数,如果大于等于阈值—即当前数组的长度乘以加载因子的值的时候

引用于: http://www.cnblogs.com/hongdada/p/6024832.html HashMap: public HashMap(int initialCapacity, float loadFactor) { //初始容量不能<0 if (initialCapacity < 0) throw new IllegalArgumentException("Illegal initial capacity: " + initialCapacity); //

前言:当您在读该文章的时候,我认为您已经知道HashMap的底层实现原理,如果您还不清楚HashMap是如何实现的,请先去了解,再回来看本文章. 1.HashMap什么时候扩容? HashMap的容量是有限的.当经过多次元素插入的时候,使得HashMap达到一定的饱和度,Key映射位置的几率不断变大.这个时候,HashMap就需要扩容了,也就是Resize. 影响发生Resize的因素有两个: 1)Capacity:HashMap的当前长度,HashMap的长度必是2的幂. 测试一下: 请问如下

1. HashMap在什么条件下扩容 判断HashMap的数组Size大小如果超过loadFactor*capacity,就要扩容. 相关的类属性: capacity:当前数组容量,始终保持 2^n,可以扩容,扩容后数组大小为当前的 2 倍. loadFactor:负载因子,默认为 0.75 loadFactor加载因子是控制数组存放数据的疏密程度,loadFactor越趋近于1,那么 数组中存放的数据(entry)也就越多,也就越密,也就是会让链表的长度增加,loadFactor越小,也就是趋

我们知道 HashMap 的底层是由数组,链表,红黑树组成的,在 HashMap 做扩容操作时,除了把数组容量扩大为原来的两倍外,还会对所有元素重新计算 hash 值,因为长度扩大以后,hash值也随之改变. 如果是简单的 Node 对象,只需要重新计算下标放进去就可以了,如果是链表和红黑树,那么操作就会比较复杂,下面我们就来看下,JDK1.8 下的 HashMap 在扩容时对链表和红黑树做了哪些优化? rehash 时,链表怎么处理? 假设一个 HashMap 原本 bucket 大小为 16

需要,因为要重新计算旧数组元素在新数组地址.HashMap在JDK1.8中的rehash算法(也就是扩容后重新为里面的键值对寻址的算法)进行优化.hash寻址算法是 index =(n - 1) & hash 在JDK1.7的时候,是将数组扩容为两倍,然后将HashMap中所有的key重新进行hash寻址然后再放入到新的位置.在JDK1.8的HashMap的源码中,也将rehash算法最后寻址分为了两种情况: 扩容前,key1和key2的hash值不同,但是通过hash寻址算法后索引相同:扩容后

HashMap 存储结构 HashMap是数组+链表+红黑树(1.8)实现的. (1)Node[] table,即哈希桶数组.Node是内部类,实现了Map.Entry接口,本质是键值对. static class Node<K,V> implements Map.Entry<K,V> { final int hash; //用来定位数组索引位置 final K key; V value; Node<K,V> next; //链表的下一个node Node(int ha

技巧: 与&操作   和   与 n 如8 与,为0  则位置不变 https://blog.csdn.net/zlp1992/article/details/104376309 java8在实现HashMap时做了一系列的优化,其中一个重要的优化即在扩容的时候,原有数组里的数据迁移到新数组里不需要重新hash,而是采用一种巧妙的方法,代码如下: table = newTab; if (oldTab != null) { for (int j = 0; j < oldCap; ++j) {