HashMap、Hashtable、ConcurrentHashMap

最新推荐文章于 2025-02-27 19:08:46 发布

BigDevil_

最新推荐文章于 2025-02-27 19:08:46 发布

阅读量552

点赞数 1

分类专栏： Java基础

原文链接：https://blog.youkuaiyun.com/qq_36894974/article/details/106922225

版权

Java基础专栏收录该内容

26 篇文章

订阅专栏

文章目录

HashMap

在这里插入图片描述

特点

线程不安全，允许键值为null。底层：数组+链表+红黑树
初始化容量：16
默认加载因子：0.75f
扩容机制：存储键值对个数 > 数组容量x加载因子；或者 某链表长度>8，数组长度<64
扩容大小 ：当前容量*2
HashMap线程安全的实现：Collections.synchronizedMap(new HashMap()); 或者用ConcurrentHashMap

数据结构模型：

HashMap（jdk1.7）
在这里插入图片描述

HashMap（jdk1.8）
在这里插入图片描述
源码结构（只有结构）：
Node<K,V>[] table; 数组（链表数组，jdk1.7是Entry数组）
Node<K,V> 链表
TreeNode<K,V> 红黑树

// 1. 数组
transient Node<K,V>[] table;

// 2. 链表
static class Node<K,V> implements Map.Entry<K,V> {
    final int hash;// 元素的hash值
    final K key; // key
    V value; // value
    Node<K,V> next; // 指向 下一个node元素节点

    Node(int hash, K key, V value, Node<K,V> next) {...省略...}

    public final K getKey()        { return key; }
    public final V getValue()      { return value; }
    public final String toString() { return key + "=" + value; }

    public final int hashCode() {return Objects.hashCode(key) ^ Objects.hashCode(value);}

    public final V setValue(V newValue) {...(返回oldValue)省略...}

    public final boolean equals(Object o) {...}
}

// 3. 红黑树 
static final class TreeNode<K,V> extends LinkedHashMap.Entry<K,V> {
     TreeNode<K,V> parent;  
     TreeNode<K,V> left;
     TreeNode<K,V> right;
     TreeNode<K,V> prev;    
     boolean red;
     TreeNode(int hash, K key, V val, Node<K,V> next) {
         super(hash, key, val, next);
     }
     ...省略...
}

HashMap中的重要属性：

public class HashMap<K,V> extends AbstractMap<K,V>
    implements Map<K,V>, Cloneable, Serializable {
    //序列号，序列化的时候使用。
    private static final long serialVersionUID = 362498820763181265L;
    /** 默认容量:16 。 1向左移位4个，00000001变成00010000，也就是2的4次方为16，使用移位是因为移位是计算机基础运算，效率比加减乘除快。**/
    static final int DEFAULT_INITIAL_CAPACITY = 1 << 4;
    //最大容量，2的30次方。
    static final int MAXIMUM_CAPACITY = 1 << 30;
    //加载因子，用于扩容使用。
    static final float DEFAULT_LOAD_FACTOR = 0.75f;
    /**当某个桶节点数量大于8时，会转换为红黑树。
    （红黑树化的必要条件1） **/
    static final int TREEIFY_THRESHOLD = 8;
    //当某个桶节点数量小于6时，会转换为链表，前提是它当前是红黑树结构。
    static final int UNTREEIFY_THRESHOLD = 6;
    /**红黑树化最小容量。整个hashMap中元素数量大于64
    （红黑树化的必要条件2）**/
    static final int MIN_TREEIFY_CAPACITY = 64;
    //节点数组,就是 Entry 数组,存储元素的数组
    transient Node<K,V>[] table;
    //将数据转换成set的另一种存储形式，这个变量主要用于迭代功能。
    transient Set<Map.Entry<K,V>> entrySet;
    //键值对数量
    transient int size;
    //统计该map修改的次数
    transient int modCount;
    //临界值（初始容量 * 负载因子），元素数量达到临界值时，会进行扩容。
    int threshold;
    //也是加载因子，只不过这个是变量。
    final float loadFactor;

最大容量：
```
static final int MAXIMUM_CAPACITY = 1 << 30;
```
这里是不是有个疑问？int 占用四个字节，按说最大容量应该是左移 31 位，为什么 HashMap 最大容量是左移 30 位呢？因为在数值计算中，最高位也就是最左位的位是代表着符号位，0 -> 正数，1 -> 负数，容量不可能是负数，所以 HashMap 最高位只能移位到 2 ^ 30 次幂。
加载因子
```
static final float DEFAULT_LOAD_FACTOR = 0.75f;
```
扩容机制的原则是 当 HashMap 中存储的数量 > HashMap 容量 * 负载因子时，就会把 HashMap 的容量扩大为原来的二倍。
链表转红黑树的机制：
```
// 条件1：链表长度 > 8  （红黑树化阈值）
 static final int TREEIFY_THRESHOLD = 8;
// 条件2：数组长度 > 64 （最小红黑树化容量 （容量：数组的容量，即数组长度））
 static final int MIN_TREEIFY_CAPACITY = 64;
```
当桶中存储元素大于8时，会自动转成红黑树，然后在转变成树之前，还会有一次判断，只有数组长度大于 64 才会发生转换。这是为了避免在哈希表建立初期，多个键值对恰好被放入了同一个链表中而导致不必要的转化。

注意：
如果链表长度>8，但是数组长度<64，这个时候优先进行数组扩容（resize）。

目的：考虑到数组的长度较小，尽量避开红黑树，这种情况下，转为红黑树，反而会降低效率问题，因为红黑树需要左旋，右旋，变色操作来保持平衡，所以当数组长度小于64，搜索时间会相对快些，考虑到性能和减少搜索的时间，只有当链表长度大于阈值（默认为8）时并且数组的长度大于64时，链表将会转换为红黑树。（数组与红黑树转换很消耗性能，在数组小的时候，不变红黑树）

引申问题：为什么TREEIFY_THRESHOLD = 8，UNTREEIFY_THRESHOLD = 6 ？
（个人理解）如果都为8或6，那么频繁在一个链表中插入和删除1个元素，会频繁的进行数组和红黑树的转换，很浪费性能。所以untreeify小与treefy

引申问题2：为什么treeify是8？
根据泊松分布概率质量函数,一个哈希桶达到 9 个元素的概率小于一千万分之一. 选定阈值为 8 猜测是基于泊松分布和类似与 DEFAULT_LOAD_FACTOR 一样，基于一些空间和效率之间取的一个平均值。（尽量不用红黑树，因为红黑树消耗资源大）
https://www.v2ex.com/t/651978
扩容：
发生扩容的可能：
1. 当 map键值对总数 >= 加载因子* 数组长度时
2. 当某个桶中的链表长度>8，但是数组容量（长度）<64时
都会将原来的对象放入新的数组中（数组长度*2）。jdk1.8

参考：部分面试题https://blog.youkuaiyun.com/qq_36894974/article/details/106922225

JDK8 HashMap： https://zhuanlan.zhihu.com/p/21673805

HashMap总结：https://blog.youkuaiyun.com/hefenglian/article/details/79763634

HashMap的put流程：

在这里插入图片描述

图片：https://www.cnblogs.com/dongl961230/p/13055438.html

JDK1.7中 HashMap并发put然后resize产生死环

http://www.imooc.com/article/details/id/292265

Hashtable：

在这里插入图片描述
继承Dictionary，实现Map，Cloneable，Serializable接口。

特点

Hashtable 线程安全，键值都不能为null，底层是哈希表。
初始默认容量：11
加载因子：0.75
扩容机制：存储键值对个数 > 数组容量 x 加载因子；
扩容大小：当前容量 x 2 + 1 然后重新散列，
实现线程安全机制：修改数据时锁整个表（private transient Entry<?,?>[] table）。大部分方法（涉及线程安全问题的方法）都是同步的。

Hashtable模型：

在这里插入图片描述

Hashtable属性

/**
    // 数据保存数组  和hashMap中的tab同理
    private transient Entry<?,?>[] table;

    // 总条数  和hashMap中的size同理
    private transient int count;

    /**就是table扩容的门槛  当count 大于等于threshold时 table数组进行扩容操作
    threshold = 当前table.length * loadFactor （loadFactor默认为0.75）
     */
    private int threshold;

    /** 负载因子 相对于 数组的比例计算公式   table.length * loadFactor = threshold  */
    private float loadFactor;

ConcurrentHashMap

特点

JDK1.7：

底层采用 分段的数组+链表实现，线程安全
通过把整个Map分为N个Segment，可以提供相同的线程安全，但是效率提升N倍，默认提升16倍。(读操作不加锁，由于HashEntry的value变量是 volatile的，也能保证读取到最新的值。)
Hashtable的synchronized是针对整张Hash表的，即每次锁住整张表让线程独占，ConcurrentHashMap允许多个修改操作并发进行，其关键在于使用了锁分离技术
有些方法需要跨段，比如size()和containsValue()，它们可能需要锁定整个表而而不仅仅是某个段，这需要按顺序锁定所有段，操作完毕后，又按顺序释放所有段的锁。
扩容：段内扩容（段内元素超过该段对应Entry数组长度的75%触发扩容，不会对整个Map进行扩容），插入前检测需不需要扩容，有效避免无效扩容。（HashMap是插入后检测）
转载：https://www.cnblogs.com/heyonggang/p/9112731.html

图片来源：https://www.cnblogs.com/technologykai/articles/10966606.html

图片来源：https://www.cnblogs.com/technologykai/articles/10966606.html

JDK1.8

JDK1.8的实现已经摒弃了Segment的概念，而是直接用Node数组+链表+红黑树的数据结构来实现，并发控制使用Synchronized和CAS来操作，整个看起来就像是优化过且线程安全的HashMap，虽然在JDK1.8中还能看到Segment的数据结构，但是已经简化了属性，只是为了兼容旧版本。

数据结构模型：与HashMap一样

synchronized 只锁定当前链表或红黑二叉树的首节点，这样只要 hash 不冲突，就不会产生并发，效率又提升 N 倍。

put操作：

如果没有初始化就先调用initTable（）方法来进行初始化过程
如果没有hash冲突就直接CAS插入
如果还在进行扩容操作就先进行扩容
如果存在hash冲突，就加锁 （用synchronize锁 node对象） 来保证线程安全，这里有两种情况，一种是链表形式就直接遍历到尾端插入，一种是红黑树就按照红黑树结构插入，
最后一个如果Hash冲突时会形成Node链表，在链表长度超过8，Node数组超过64时会将链表结构转换为红黑树的结构，break再一次进入循环
如果添加成功就调用addCount（）方法统计size，并且检查是否需要扩容

ConcurrentHashMap jdk1.7和jdk1.8的对比

其实可以看出JDK1.8版本的ConcurrentHashMap的数据结构已经接近HashMap，相对而言，ConcurrentHashMap只是增加了同步的操作来控制并发，从JDK1.7版本的ReentrantLock+Segment+HashEntry，到JDK1.8版本中synchronized+CAS+HashEntry+红黑树,相对而言，总结如下思考

JDK1.8的实现降低锁的粒度，JDK1.7版本锁的粒度是基于Segment的，包含多个HashEntry，而JDK1.8锁的粒度就是HashEntry（首节点）
JDK1.8版本的数据结构变得更加简单，使得操作也更加清晰流畅，因为已经使用synchronized来进行同步，所以不需要分段锁的概念，也就不需要Segment这种数据结构了，由于粒度的降低，实现的复杂度也增加了
JDK1.8使用红黑树来优化链表，基于长度很长的链表的遍历是一个很漫长的过程，而红黑树的遍历效率是很快的，代替一定阈值的链表，这样形成一个最佳拍档
JDK1.8为什么使用内置锁synchronized来代替重入锁ReentrantLock，我觉得有以下几点
- 因为粒度降低了，在相对而言的低粒度加锁方式，synchronized并不比ReentrantLock差，在粗粒度加锁中ReentrantLock可能通过Condition来控制各个低粒度的边界，更加的灵活，而在低粒度中，Condition的优势就没有了
- JVM的开发团队从来都没有放弃synchronized，而且基于JVM的synchronized优化空间更大，使用内嵌的关键字比使用API更加自然
- 在大量的数据操作下，对于JVM的内存压力，基于API的ReentrantLock会开销更多的内存，虽然不是瓶颈，但是也是一个选择依据