重温HashMap底层原理

1.HashMap概述

2.JDK7与JDK8的HashMap区别

3.HashMap的主要方法分析

4.常见问题分析总结

1.HashMap概述

HashMap是使用频率最高的用于映射键值对(key和value)处理的数据类型。随着JDK版本的跟新，JDK1.8对HashMap底层的实现进行了优化，列入引入红黑树的数据结构和扩容的优化等。本文结合JDK1.7和JDK1.8的区别，深入探讨HashMap的数据结构实现和功能原理。

在讨论哈希表之前，我们先大概了解下其他数据结构在新增，查找等基础操作执行性能

数组：采用一段连续的存储单元来存储数据。对于指定下标的查找，时间复杂度为O(1)；通过给定值进行查找，需要遍历数组，逐一比对给定关键字和数组元素，时间复杂度为O(n)，当然，对于有序数组，则可采用二分查找，插值查找，斐波那契查找等方式，可将查找复杂度提高为O(logn)；对于一般的插入删除操作，涉及到数组元素的移动，其平均复杂度也为O(n)

线性链表：对于链表的新增，删除等操作（在找到指定操作位置后），仅需处理结点间的引用即可，时间复杂度为O(1)，而查找操作需要遍历链表逐一进行比对，复杂度为O(n)

二叉树：对一棵相对平衡的有序二叉树，对其进行插入，查找，删除等操作，平均复杂度均为O(logn)。

哈希表：相比上述几种数据结构，在哈希表中进行添加，删除，查找等操作，性能十分之高，不考虑哈希冲突的情况下（后面会探讨下哈希冲突的情况），仅需一次定位即可完成，时间复杂度为O(1)，接下来我们就来看看哈希表是如何实现达到惊艳的常数阶O(1)的。

我们知道，数据结构的物理存储结构只有两种：顺序存储结构和链式存储结构（像栈，队列，树，图等是从逻辑结构去抽象的，映射到内存中，也这两种物理组织形式），而在上面我们提到过，在数组中根据下标查找某个元素，一次定位就可以达到，哈希表利用了这种特性，哈希表的主干就是数组。

比如我们要新增或查找某个元素，我们通过把当前元素的关键字通过某个函数映射到数组中的某个位置，通过数组下标一次定位就可完成操作。

哈希冲突

如果两个不同的元素，通过哈希函数得出的实际存储地址相同怎么办？也就是说，当我们对某个元素进行哈希运算，得到一个存储地址，然后要进行插入的时候，发现已经被其他元素占用了，其实这就是所谓的哈希冲突，也叫哈希碰撞。前面我们提到过，哈希函数的设计至关重要，好的哈希函数会尽可能地保证计算简单和散列地址分布均匀,但是，我们需要清楚的是，数组是一块连续的固定长度的内存空间，再好的哈希函数也不能保证得到的存储地址绝对不发生冲突。那么哈希冲突如何解决呢？哈希冲突的解决方案有多种:开放定址法（发生冲突，继续寻找下一块未被占用的存储地址），再散列函数法，链地址法，而HashMap即是采用了链地址法，也就是数组+链表的方式。

HashMap的几个重要知识点

HashMap是无序且不安全的数据结构。
HashMap 是以key–value对的形式存储的，key值是唯一的（可以为null），一个key只能对应着一个value，但是value是可以重复的。
HashMap 如果再次添加相同的key值，它会覆盖key值所对应的内容，这也是与HashSet不同的一点，Set通过add添加相同的对象，不会再添加到Set中去。
HashMap 提供了get方法，通过key值取对应的value值，但是HashSet只能通过迭代器Iterator来遍历数据，找对象。

2.JDK7与JDK8的HashMap区别

既然讲HashMap，那就不得不说一下JDK1.7与JDK1.8（及jdk8以后）的HashMap有什么区别：

jdk1.8中添加了红黑树，当链表长度大于等于8的时候链表会变成红黑树
链表新节点插入链表的顺序不同（jdk1.7是插入头结点，jdk1.8因为要把链表变为红黑树所以采用插入尾节点）
hash算法简化 ( jdk1.8 )
resize的逻辑修改（jdk1.7会出现死循环，jdk1.8不会）

3.HashMap的主要方法分析

put方法

put方法用于将键值对插入到 HashMap 中。让我们看一下put方法的源代码：

首先，通过has(key)方法计算键的哈希码，并调用putVal()方法进行插入操作。下面是putVal()方法的源代码：

putVal()方法的核心是通过哈希码定位桶，然后在桶中进行插入操作。如果桶为空，则直接在桶中插入新节点。如果桶不为空，则遍历链表或红黑树，查找键是否已存在。如果键已存在，则替换对应的值；如果键不存在，则将新节点插入到链表的末尾，并根据链表长度是否达到阈值来决定是否将链表转化为红黑树。最后，更新修改次数和元素数量，并进行必要的操作。

get方法

当我们需要根据键来获取值时，可以使用 HashMap 的get(key)方法。下面讲解下 HashMap 的get方法的原理。

首先，我们传入要查找的键key，然后通过hash(key)方法计算键的哈希码。哈希码被用来确定键在 HashMap 中的桶（bucket）位置。根据哈希码，我们可以确定键在数组中的索引位置。

接下来，我们在确定的索引位置找到对应的桶。如果桶为空，即没有键值对存在，那么返回 null，表示没有找到对应的值。

如果桶不为空，那么可能存在多个键值对，这时我们需要遍历链表或红黑树来找到具有相同键的节点。在遍历过程中，我们会使用键的 equals() 方法来比较传入的键和当前节点的键是否相等。如果找到了相等的键，那么返回对应节点的值。

如果遍历完整个链表或红黑树仍然没有找到相等的键，那么返回 null，表示没有找到对应的值。

整个get()方法的原理就是根据键的哈希码确定索引位置，然后在对应的桶中遍历链表或红黑树，通过 equals() 方法比较键的相等性来找到对应的值。

resize方法

resize方法用于动态扩容 HashMap。当元素数量超过阈值时，HashMap 会自动触发扩容操作。resize方法的主要功能是创建一个新的数组，并将所有键值对重新计算哈希码和索引位置，然后将它们分配到新的桶中。扩容后的容量是原来的两倍，并根据负载因子重新计算阈值。在转移键值对时，会根据哈希码的高位来确定是保留在原来的位置还是移动到新的位置。如果链表长度超过阈值，则会将链表转化为红黑树以提高查找效率。

4.常见问题分析总结

4.1为什么要用HashMap，你知道底层原理吗？

HashMap结合了查询效率快以及增删效率快的优点，作为一个容器是非常可贵的。HashMap存的都是一个个键值对，我们通过键值对对其进行修改和访问，在 JDK 1.7及以前底层是一个数组+链表的结构，当发生哈希冲突时，就将节点采用头插法的方式放在链表头部。在JDK1.7以后底层是一个数组+链表+红黑树的结构，同样的，发生哈希冲突时，依旧是插到链表里去，只不过现在是尾插法，这样做就是为了避免出现循环数据，另外当链表节点大于8时，会转成红黑树进行存储，但这并不代表删除了链表结构，链表结构依然存在，当节点数量重新小于8后，红黑树又会重新变成链表结构。(再说说get(),put()方法原理就差不多了)。

4.2HashMap 中的 hash 值有什么用？

HashMap中的hash值是由hash函数产生的，它是保证HashMap能正常运转的基石，所有键值对进行存储时的位置都是靠它和 (length - 1) 进行位运算得出的，我们进行插入、访问、删除都必须先得到对应的hash值，再通过它算出对应的索引值，最后才能操作对应的键值对。

4.3HashMap中初始化大小为什么是16呢？

首先我们看hashMap的源码可知当新put一个数据时会进行计算位于table数组(也称为桶)中的下标：

因为是将二进制进行按位于，(16-1) 是 1111,末位是1，这样也能保证计算后的index既可以是奇数也可以是偶数，并且只要传进来的key足够分散，均匀那么按位于的时候获得的index就会减少重复，这样也就减少了hash的碰撞以及hashMap的查询效率。

那么到了这里你也许会问？那么就然16可以，是不是只要是2的整数次幂就可以呢？

答案是肯定的。那为什么不是8,4呢？因为是8或者4的话很容易导致map扩容影响性能，如果分配的太大的话又会浪费资源，所以就使用16作为初始大小。

4.4为什么建议用 String Integer 这样的包装类作为 HashMap 的键？

首先，这些类内部重写了hashCode()，equal()方法，本身就遵循HashMap中的规范，可以有效减小hash碰撞的概率。其次，这些类都是final类型，也就是说key是不可变的，避免同一个对象的计算出的hash值不一样。除了上面所说的，很多容器都不能用基本类型并且也不能存null值也是一个原因。

4.5重写equals方法需同时重写hashCode方法吗？

我们举例来看看，如果重写了equals而不重写hashcode会发生什么样的问题

package HashBucketDemo;

import java.util.HashMap;

public class MyTest {
    private static class Person{
        int idCard;
        String name;

        public Person(int idCard, String name) {
            this.idCard = idCard;
            this.name = name;
        }
        @Override
        public boolean equals(Object o) {
            if (this == o) {
                return true;
            }
            if (o == null || getClass() != o.getClass()){
                return false;
            }
            Person person = (Person) o;
            //两个对象是否等值，通过idCard来确定
            return this.idCard == person.idCard;
        }

    }
    public static void main(String []args){
        HashMap<Person,String> map = new HashMap<Person, String>();
        Person person = new Person(1234,"大大怪");
        //put到hashmap中去
        map.put(person,"呃呃呃呃呃");
        //get取出，从逻辑上讲应该能输出“呃呃呃呃呃”
        System.out.println("结果:"+map.get(new Person(1234,"大大怪")));
    }
}

这是因为我们在进行get和put操作的时候，使用的key从逻辑上讲是等值的（通过equals比较是相等的），但由于没有重写hashCode方法，所以put操作时，key(hashcode1)–>hash–>indexFor–>最终索引位置，而通过key取出value的时候 key(hashcode1)–>hash–>indexFor–>最终索引位置，由于hashcode1不等于hashcode2，导致没有定位到一个数组位置而返回逻辑上错误的值null。

所以，在重写equals的方法的时候，必须注意重写hashCode方法，同时还要保证通过equals判断相等的两个对象，调用hashCode方法要返回同样的整数值。而如果equals判断不相等的两个对象，其hashCode可以相同（只不过会发生哈希冲突，应尽量避免）。

4.6为什么HashMap的默认负载因子是0.75，而不是0.5或者是整数1呢？

阈值(threshold) = 负载因子(loadFactor) x 容量(capacity) 根据HashMap的扩容机制，他会保证容量(capacity)的值永远都是2的幂为了保证负载因子x容量的结果是一个整数，这个值是0.75(4/3)比较合理，因为这个数和任何2的次幂乘积结果都是整数。
理论上来讲，负载因子越大，导致哈希冲突的概率也就越大，负载因子越小，费的空间也就越大,这是一个无法避免的利弊关系，所以通过一个简单的数学推理，可以测算出这个数值在0.75左右是比较合理的，是一个平衡点。

4.7JDK 1.7中为什么会形成死循环?(重点)

此处JDK为1.7，为头插法

在多线程下扩容会形成死循环，我们先来回顾下正常情况下的扩容。

成功扩容后，我们发现链表被倒置了，现在再来看看 多线程 下对 HashMap 进行扩容形成环形数据结构的情况。

假设现在有两个线程在同时扩容 HashMap ，当线程A执行到 Entry<K,V> next = e.next 时被挂起，待到线程B扩容完毕后，线程A重新拿到 CPU时间片 。

因为线程A在扩容前执行过 Entry<K,V> next = e.next，因此现在线程A的 e 和 next 分别指向 key("cofbro") 和 key("cc")。

现在 线程A 开始扩容，首先执行 newTab[i] = e，将 entry 插入到数组中，随后按照顺序执行 e = next，然后进入下一个循环 Entry<K,V> next = e.next，因为此时HashMap已经被 线程B 扩容完成，所以此时的 next = key("cofbro") 。