前言
你问的为什么,我都想回答。大家好,我是ShadowJava,为你解答疑惑!
本文内容同步到我的微信公众号【JustKeepCoding】,喜欢的朋友点个订阅,我们一起努力进步!
这节依然是探讨Java中的常考的数据结构concurrenthashmap
、hashtable
,虽然常考但是你理解透了吗?让我们来探讨为什么吧!
1 回顾
上节详细分析了HashMap的源码知识,从JDK1.7的数组加链表
到 JDK1.8的数组加链表加红黑树
的数据结构,让我们知道hashmap在1.8的重大改变。
1.2 那么作为在实际工作中我们为什么喜欢用concurrenthashmap代替hashmap呢?
众所周知,hashmap是线程不安全
的,是因为hashmap在并发的环境下1.7同时插入会形成环形链表造成死循环,在1.8下插入会直接覆盖数据。
1.3 那覆盖数据和形成环形链表怎么会不安全呢?
线程安全:我们定义当多个线程访问时,采用了加锁机制
,当一个线程访问一个类的数据时,进行保护
,其他线程不能进行访问直到该线程读取完
,其他线程才可以使用。不会出现数据不一致或者数据污染(脏读)。否则就是线程不安全。
其实就是类似于操作系统的互斥,一个人访问必须等待其他人访问完毕其他人才能访问,避免访问被修改,造成脏数据
。
回到主题,1.8中的利用尾插法
且多个put线程
同时插入不同的数据,如果hash值相同
时第一个线程插入成功,第二线程不用判断hash值直接将数据覆盖
。导致put线程还没结束,就被另一个数据修改了,所以线程不安全。如果这段话不太懂可以查看我的上一篇博文:哈?还在聊hashmap?老知识点了!
来个黄图深入理解一下:
喜欢我写的文章就关注我吧,周三和周日都会更新文章。我也会尽量学习更多新的知识更大家,我的微信公众号【JustKeepCoding】也有Java的并发编程等书籍,喜欢的可以关注领取!
1.4 那么HashMap线程不安全,可以用那些数据结构优化替代呢?
可以使用Collections.synchronizedMap(map)、Hashtable和ConcurrentHashMap代替。那么首先这些是怎么工作的,又是怎样有效替代hashmap的,而ConcurrentHashMap为什么又是最好的选择呢?
2 Collections.synchronizedMap(map)的那些事儿
Collections.synchronizedMap是个比较老的API了,实用起来需要手动做一些事儿。但是相对于ConcurrentHashMap来说可以接收任何类型的map。
2.1 读Collections.synchronizedMap源码 学大佬编程
2.1.1 构造函数源码
SynchronizedMap(Map<K,V> m) {
this.m = Objects.requireNonNull(m);
mutex = this;
}
SynchronizedMap(Map<K,V> m, Object mutex) {
this.m = m;
this.mutex = mutex;
}
从上面可以看出SynchronizedMap
包含两个构造函数,可以只传入一个map,或者传入两个参数。其中mutex
是互斥锁,如果只传入一个map,则将互斥锁赋值给调用SynchronizedMap的对象。如果传入两个参数,则当前互斥锁为该参数对象mutex。创建出SynchronizedMap之后,再操作Map对象就会给对方上锁。
什么意思呢,相信学过操作系统互斥
原理的看见mutex应该懂一大半了吧!上锁了,就只能允许当前线程操作完毕了,才允许另一个线程访问!
2.1.2 增删改查源码
public int size() {
synchronized (mutex) {return m.size();}
}
public boolean isEmpty() {
synchronized (mutex) {return m.isEmpty();}
}
public boolean containsKey(Object key) {
synchronized (mutex) {return m.containsKey(key);}
}
public boolean containsValue(Object value) {
synchronized (mutex) {return m.containsValue(value);}
}
public V get(Object key) {
synchronized (mutex) {return m.get(key);}
}
public V put(K key, V value) {
synchronized (mutex) {return m.put(key, value);}
}
public V remove(Object key) {
synchronized (mutex) {return m.remove(key);}
}
public void putAll(Map<? extends K, ? extends V> map) {
synchronized (mutex) {m.putAll(map);}
}
public void clear() {
synchronized (mutex) {m.clear();}
}
上面的方法都是该对象的增删改查方法,操作时就会加入synchronized
关键字给对象上锁。那么synchronized关键字的作用是什么呢,这就得自己百度了,后面还有好多呢,或者可以先关注我,下集可能就出了!
3 关于Hashtable的茶话会
Hashtable也是跟HashMap一样基于散列表的实现
3.1 Hashtable源码
public class Hashtable<K,V>
extends Dictionary<K,V>
implements Map<K,V>, Cloneable, java.io.Serializable {}
private transient Entry<?,?>[] table;
private int threshold;//阈值
private float loadFactor;//负载因子
public synchronized int size() {
return count;
}
可以看出源码跟HashMap的1.7版本有些类似,是基于数组加链表
实现。但是为什么效率低下,因为对数据操作时都会上锁。
3.2 Hashtable为什么会被弃用?
虽然Hashtable比HashMap出的早一些,但是基本上是被弃用了,首先因为继承的是被弃用的Dictionary类。HashMap已经成为广泛的数据结构,主要是因为Hashtable线程安全导致,每个方法都有synchronized
同步锁。因为加入synchronized同步锁了,在并发度高的情况下,其他线程会被阻塞或者一直轮询。
3.3 Hashtable和HashMap的不同点
上一节认真看过的都知道,HashMap是可以允许KEY和VALUE为Null
的,而HashTable是不允许为Null
的,这是因为他们的迭代器不同。
3.3.1 从源码分析
从HashMap的hash源码看:
static final int hash(Object key) {
int h;
return (key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16);
}
当我们向HashMap中插入Null时,会处理为0地址,所以是可以插入
Null
值的。
从HashTable源码看:
public synchronized V put(K key, V value) {
// Make sure the value is not null
if (value == null) {
throw new NullPointerException();
}
}
当value为null是会抛出NullPointerException异常
HashMap使用的是Iterator 迭代器,而Hashtable 使用的是Enumerator 迭代器。
3.3.2 迭代器不同
迭代器不同会有什么影响呢,现在来讲讲Java中迭代器的两种模式吧:
- 快速失败(
fail—fast
)
在用迭代器遍历一个集合对象时,如果遍历过程中对集合对象的内容进行了修改(增加、删除、修改),则会抛出Concurrent Modification Exception
。(这个过程包括多线程下的修改,也包括单线程的修改)
原理:迭代器在遍历时直接访问集合中的内容,并且在遍历过程中使用一个modCount
变量。集合在被遍历期间如果内容发生变化,就会改变modCount的值。每当迭代器使用hashNext()/next()遍历下一个元素之前,都会检测modCount变量是否为expectedmodCount
值,是的话就返回遍历;否则抛出异常,终止遍历。
场景:java.util包下的集合类
都是快速失败的,不能在多线程下发生并发修改(迭代过程中被修改)。 - 安全失败(
fail—safe
)
采用安全失败机制的集合容器,在遍历时不是直接在集合内容上访问的,而是先复制原有集合内容,在拷贝的集合上进行遍历。
原理:由于迭代时是对原集合的拷贝
进行遍历,所以在遍历过程中对原集合所作的修改并不能被迭代器检测到,所以不会触发Concurrent Modification Exception。
缺点:基于拷贝内容的优点是避免了Concurrent Modification Exception,但同样地,迭代器并不能访问到修改后的内容,即:迭代器遍历的是开始遍历那一刻拿到的集合拷贝,在遍历期间原集合发生的修改迭代器是不知道的
。
场景:java.util.concurrent包
下的容器都是安全失败,可以在多线程下并发使用,并发修改。
而 Iterator 迭代器是fail-fast
的,而 Hashtable 的 Enumerator不是 fail-fast 的。
这样当其他增删改查线程改变了HashMap的结构数据将会抛出Concurrent Modification Exception
异常,而Hashtable不会。
我摊牌了,我不装了,我是色批,来个色图总结一下!
4 concurrenthashmap的茶话会
4.1 为什么都推崇ConcurrentHashMap
因为ConcurrentHashMap并发度较高啊,因为好用啊,哈?这?【摸摸了摸头】
ConcurrentHashMap在1.7版本和1.8也有很大的不同,所以也需要从两个版本中分析才能得出结论。
1.7 源码分析:
static final class HashEntry<K,V> {
final K key; // 声明 key 为 final 型
final int hash; // 声明 hash 值为 final 型
volatile V value; // 声明 value 为 volatile 型
final HashEntry<K,V> next; // 声明 next 为 final 型
HashEntry(K key, int hash, HashEntry<K,V> next, V value) {
this.key = key;
this.hash = hash;
this.next = next;
this.value = value;
}
}
在1.7版本中,ConcurrentHashMap的数据结构是由一个Segment数组和多个HashEntry组成,本质跟HashMap一样是个数组加链表
。ConcurrentHashMap采用了非常精妙的"分段锁"策略,它的主干是个Segment数组,而Segment继承了ReentrantLock。
static final class Segment<K,V> extends ReentrantLock implements Serializable {
transient volatile HashEntry<K,V>[] table;//table存放数据的桶
transient int modCount;//修改次数,就是fail—fast中机制使用的记录变量
transient int threshold;//阈值
final float loadFactor; // 负载因子
}
4.3 那么什么是ReentrantLock?
在ConcurrentHashMap,一个Segment就是一个子哈希表,Segment里维护了一个HashEntry数组,并发环境下,对于不同Segment的数据进行操作是不用考虑锁竞争的。