HashMap

最新推荐文章于 2024-12-09 19:59:05 发布

原创最新推荐文章于 2024-12-09 19:59:05 发布 · 134 阅读

0 ·

CC 4.0 BY-SA版权

Java 专栏收录该内容

26 篇文章

订阅专栏

HashMap是Java中基于哈希表的Map接口实现，旨在实现O(1)操作。在JDK1.8以前，使用数组+链表，极端情况下会退化为O(n)。1.8后引入红黑树，当链表长度大于8时转换，保证操作时间复杂度为O(logn)。默认容量16，最大容量2^30，扩容因子0.75。HashMap非线程安全，多线程环境下可能导致数据丢失或死循环。解决方案包括使用synchronizedMap或ConcurrentHashMap。

一.描述

HashMap是常用的Java集合之一，是基于哈希表的Map接口的实现。设计目标是尽量实现哈希表O(1)级别的增删改查效果，与HashTable主要区别为**==不支持同步和允许null作为key和value==**。

二.底层实现

JDK1.8之前：

1、实现：

采用 ==数组+链表== 实现，形成一个数组带着多个桶的结构，每个数组元素就是一个桶，而数组索引就是每个桶中链表的表头，每一个Map元素的数据结构是一个 ==Entry==。
- 数组存储区间连续，占用内存较多，寻址容易，插入和删除困难。
- 链表存储区间离散，占用内存较少，寻址困难，插入和删除容易。
2、遗留问题：

在某些极端情况下，会导致大量元素都存放在同一个桶(数组索引是链表的表头)的链表中，此时的HashMap 就相当于一个单链表，假设链表中的元素个数为n个，则其==操作时间复杂度就变成了O(n)==，完全失去了哈希表的优势。
JDK1.8及以后：

1、实现：

采用 ==数组+链表+红黑树== 实现。每个Map元素的数据结构是 ==Node(链表)== 或 ==TreeNode(红黑树)==。

2、解决遗留问题：

jdk1.8时默认还是使用 数组+链表 实现，只是元素的数据结构从 Entry 变为了 Node，当存储在同一个桶中的元素过多时，才会将链表转换为红黑树实现，==保证其操作时间复杂度为 O(logn)==。

3、链表与红黑树的转换条件
- 链表->红黑树：
  
  整个 HashMap 中的==元素个数 >= 64== ==且== 同一个桶下的链表中的==元素个数 > 8==；
  
  此时Map元素的数据结构从 ==Node== 转为 ==TreeNode== ;
- 红黑树->链表：
  
  同一个桶下的链表中的==元素个数 < 6==；
  
  此时元素的数据结构为 ==Node==；
4、链表转红黑树的阈值为什么是8？

因为红黑树的平均查找长度是log(n)，长度为8的时候，平均查找长度为3，如果继续使用链表，平均查找长度为8/2=4，这才有转换为树的必要。链表长度如果是小于等于6，6/2=3，虽然速度也很快的，但是转化为树结构和生成树的时间并不会太短。

还有选择6和8，中间有个差值7可以有效防止链表和树频繁转换。假设一下，如果设计成链表个数超过8则链表转换成树结构，链表个数小于8则树结构转换成链表，如果一个HashMap不停的插入、删除元素，链表个数在8左右徘徊，就会频繁的发生树转链表、链表转树，效率会很低。

三.各项默认值

初始容量（capacity）：16（1<<4），即**==2^4==**。
最大容量：(1<<30)，即**==2^30==**。
默认扩容因子（loadFactor）：==0.75==。
自动扩容阈值：当前HashMap**==元素个数 > capacity * loadFactor==**，会自动扩容，并重新hash。
扩容机制：扩容至**==当前HashMap容量*2.0，且每次扩容后的容量必须为2的n次方==**。
容量必须为2的n次方的原因：

HashMap对元素进行读、写操作时，需要将Map元素的Key的哈希值对数组长度（HashMap 的容量）进行取模运算，结果作为该元素在数组中的索引（index），在计算机中，取模运算的代价远高于位运算的代价，当数组长度为 2^n 时，可以将Map元素的Key的hashcode对 (2^n)-1 进行 ==与运算(&)==，效果与对数组长度进行取模运算相等，所以为了提高 HashMap 的操作效率，规定 ==HashMap 的容量必须为2的n次方==，即2^n。

四.线程安全

是否线程安全？不安全的场景。

==HashMap线程不安全==，主要表现在：
- 多线程同时put时可能会丢失值（前面的put被后面的覆盖）。
- 多线程扩容时会出现环状结构，造成死循环。
- 多线程使用迭代器时会触发fast-fail机制。
如何解决？
- 使用 Collections 的 synchronizedMap() 对其进行包装，使其线程安全。（锁整个表，效率差）
- 直接使用线程安全的ConcurrentHashMap。(分段锁/CAS，效率相对较高)