HashMap常见面试题补充
HashMap和Hashtable的区别和联系
hashmap为什么是线程不安全的
hashmap线程不安全是因为：HashMap底层是一个Entry数组，当发生hash冲突的时候，hashmap是采用链表的方式来解决的，在对应的数组位置存放链表的头结点。
对链表而言，新加入的节点会从头结点加入。如果多个线程同时访问一个哈希映射，而其中至少一个线程从结构上修改了该映射，则它必须 保持外部同步。
这一般通过对自然封装该映射的对象进行同步操作来完成。如果使用Collections.synchronizedMap 方法来“包装”该映射。最好在创建时完成这一操作，以防止对映射进行意外的非同步访问。
Java中的HashMap的工作原理是什么？
一，存储方式： Java中的HashMap是以键值对(key-value)的形式存储元素的。
二，调用原理： HashMap需要一个hash函数，它使用hashCode()和equals()方法bai来向集合/从集合添加和检索元素。当调用put()方法的时候，HashMap会计算key的hash值，然后把键值对存储在集合中合适的索引上。如果key已经存在了，value会被更新成新值。
三，其他热性： HashMap的一些重要的特性是它的容量(capacity)，负载因子(load factor)和扩容极限(threshold resizing)。
HashMap实现了Map接口，该接口的作用主要是为客户提供三种方式的数据显示：只查看keys列表；只查看values列表，或以key-value形式成对查看。Map接口并没有定义数据要如何存储，也没有指定如何判定key是一样，因此并不是所有的Map实现都会与hashCode方法扯上关系，如TreeMap便是要求对象实现Comparator接口，通过其compare方法来比对两者是否一致，而非hashCode及equals。同理，如果我们自己实现Map接口，我们也可以直接使用数组进行数据存储使用==判定key值是否一致，依然可以完全满足Map接口的定义。
HashMap死锁原因及替代方案
1、首先我们需要简单地了解一下HashMap数据结构
HashMap通常会用一个指针数组（假设为table[]）来做分散所有的key，当一个key被加入时，会通过Hash算
法通过key算出这个数组的下标i，然后就把这个<key, value>插到table[i]中，如果有两个不同的key被算了。
但有时候两个key算出的下标会是一个i，那么就叫冲突，又叫碰撞，这样会在table[i]上形成一个链表。所以
如果链表过多或过长，查找算法则会变成低性能的链表遍历，这是Hash表的缺陷。
我们都知道HashMap初始容量大小为16,一般来说，Hash表这个容器当有数据要插入时，都会检查容量有没有超过设定的thredhold，如果超过，需要增大Hash表的尺寸，但是这样一来，整个Hash表里的元素都需要被重算一遍。这叫rehash，这个成本相当的大。具体大家可以看看JDK源码
2、现在来讨论死锁产生的原因
HashMap是非线程安全，死锁一般都是产生于并发情况下。我们假设有二个进程T1、T2，HashMap容量为2,T1线程放入key A、B、C、D、E。在T1线程中A、B、C Hash值相同，于是形成一个链接，假设为A->C->B，而D、E Hash值不同，于是容量不足，需要新建一个更大尺寸的hash表，然后把数据从老的Hash表中
迁移到新的Hash表中(refresh)。这时T2进程闯进来了，T1暂时挂起，T2进程也准备放入新的key，这时也发现容量不足，也refresh一把。refresh之后原来的链表结构假设为C->A，之后T1进程继续执行，链接结构
为A->C,这时就形成A.next=B,B.next=A的环形链表。一旦取值进入这个环形链表就会陷入死循环。
3、替代方案
使用ConcurrentHashMap进行替代，ConcurrentHashMap是一个线程安全的Hash Table。可能有人会使用HashTable。当然HashTable也是线程安全,但HashTable锁定的是整个Hash表，效率相对比较低。而ConcurrentHashMap可以做到读取数据不加锁，并且其内部的结构可以让其在进行写操作的时候能够将锁的粒度保持地尽量地小，
HashMap和HashTable的key和value是否可以为null
1、 HashMap计算key的hash值时调用单独的方法，在该方法中会判断key是否为null，如果是则返回0；而Hashtable中则直接调用key的hashCode()方法，因此如果key为null，则抛出空指针异常。
2、 HashMap将键值对添加进数组时，不会主动判断value是否为null；而Hashtable则首先判断value是否为null。
3、以上原因主要是由于Hashtable继承自Dictionary，而HashMap继承自AbstractMap。
4、虽然ConcurrentHashMap也继承自AbstractMap，但是其也过滤掉了key或value为null的键值对。
Get方法的流程是怎样的？
先调用Key的hashcode方法拿到对象的hash值，然后用hash值对第一维数组的长度进行取模，得到数组的下标。这个数组下标所在的元素就是第二维链表的表头。然后遍历这个链表，使用Key的equals同链表元素进行比较，匹配成功即返回链表元素里存放的值。
Get方法的时间复杂度是多少？
小伙伴们在回答这道题是有很多人会开始怀疑人生，他们的脑细胞这个时候会出现短路现象。明明是O(1)啊，平时都记得牢牢的，可是刚才Get方法的流程里需要遍历链表，遍历的时间复杂度难道不是O(n)么？此刻观察这些孩子们的表情是非常卡哇伊呢的。当然还有些甚至是科班的小伙伴居然没听过时间复杂度，想到这里我也开始怀疑人生了。当他们卡壳的时候，我会稍微提醒一下，问下面的这一道题。
假如HashMap里的元素有100w个，请问第二维链表的长度大概是多少？
嗦嘎！链表的长度很短，相比总元素的个数可以忽略不计。这个时候小伙伴们的眼睛通常会开始发光，很童贞。作为面试官是很喜欢看到这种眼神的。我使用反射统计过HashMap里面链表的长度，在HashMap里放了100w个随机字符串键值对，发现链表的长度几乎从来没有超过7这个数字，当我增大loadFactor的时候，才会偶尔冒出几个长度为8的链表来。于是问题又来了。
既然链表如此短，为啥Java8要对HashMap的链表进行改造，使用红黑树来代替链表呢？
有很多同学都没具体去深入关注Java8的新特性，如果他们回答不上来，我也不会感到失望。因为到这个问题的时候，已经只剩下15%的同学不到了，如果再打击他们，看着他们落寞的身影走出了大门，我都要对自己感到失望了，怎么招个人就如此困难？
这道题的关键在于如果Key的hashcode不是随机的，而是人为特殊构造的话，那么第二维链表可能会无比的长，而且分布极为不均匀，这个时候就会出现性能问题。比如我们把对象的hashcode都统一返回一个常量，最终的结果就是hashmap会退化为一维链表，Get方法的性能巨降为O(n)，使用红黑树可以将性能提升到O(log(n))。
请解释一下HashMap的参数loadFactor，它的作用是什么？
loadFactor表示HashMap的拥挤程度，影响hash操作到同一个数组位置的概率。默认loadFactor等于0.75，当HashMap里面容纳的元素已经达到HashMap数组长度的75%时，表示HashMap太挤了，需要扩容，在HashMap的构造器中可以定制loadFactor。
请说明一下HashMap扩容的过程
扩容需要重新分配一个新数组，新数组是老数组的2倍长，然后遍历整个老结构，把所有的元素挨个重新hash分配到新结构中去。这个rehash的过程是很耗时的，特别是HashMap很大的时候，会导致程序卡顿，而2倍内存的关系还会导致内存瞬间溢出，实际上是3倍内存，因为老结构的内存在rehash结束之前还不能立即回收。那为什么不能在HashMap比较大的时候扩容扩少一点呢，关于这个问题我也没有非常满意的答案，我只知道hash的取模操作使用的是按位操作，按位操作需要限制数组的长度必须是2的指数。另外就是Java堆内存底层用的是TcMalloc这类library，它们在内存管理的分配单位就是以2的指数的单位，2倍内存的递增有助于减少内存碎片，减少内存管理的负担。
HashMap是线程安全的么？
当然不是，线程安全的HashMap是ConcurrentHashMap。关于ConcurrentHashMap还可以问很多问题，这就需要另一篇文章来具体讲解了。
你了解Redis么，你知道Redis里面的字典是如何扩容的么？
你了解Python么，你知道Python里面字典的结构是怎样的么？
创作不易，各位的支持和认可，就是我创作的最大动力，我们下篇文章见！如排版或者哪里写得不够好，欢迎评论区一起交流。最好关注一下
浙公网安备 33010602011771号