多线程使用哈希表

❣️关注专栏: JavaEE


多线程环境使用哈希表,HashMap 本身不是线程安全的.
在多线程环境下使用哈希表可以使用:

  • Hashtable(不推荐使用)
  • ConcurrentHashMap(推荐)

🎈1 Hashtable

Hashtable是线程安全的,是给关键方法加上了关键字synchronized,等于给 this 加锁。

public synchronized V put (K key, V value) { }
public synchronized Object get (Object key) { }

这相当于直接针对 Hashtable 对象本身加锁,只要操作哈希表上的任意元素,就会产生加锁,也就可能发生锁冲突。
接下来通过图示展示 Hashtable 的加锁:
![在这里插入图片描述](https://img-blog.csdnimg.cn/eb5b979887494778ad7cba0304a61c25.png
由此可见使用HashTable锁冲突的概率太大了,任何两个元素的操作都会有锁冲突,即使是在不停的链表上。这就是不推荐使用Hashtable的最主要原因!!!
所以使用Hashtable的缺点总结有以下3点:

  • 如果多线程访问同一个 Hashtable 就会直接造成锁冲突。
  • size 属性也是通过 synchronized 来控制同步, 也是比较慢。
  • 一旦触发扩容, 就由该线程完成整个扩容过程,这个过程会涉及到大量的元素拷贝, 效率会非常低。

🎈2 ConcurrentHashMap

之所以推荐,是因为相比于 Hashtable 做出了一系列的改进和优化。 以 JDK1.8 为例。

🎈2.1 ConcurrentHashMap加锁优化

ConcurrentHashMap的加锁时对每个链表都加锁,每个链表有自己的锁,而不是所有的链表共用一个锁。加锁的方式仍然是使用 synchronized, 但是不是锁整个对象, 而是 “锁桶” (用每个链表的头结点作为锁对象), 大大降低了锁冲突的概率。
图示展示 ConcurrentHashMap加锁:
在这里插入图片描述
由此可见:使用ConcurrentHashMap,两个线程针对同一个锁对象加锁,才有锁竞争,才有阻塞等待,针对不同的对象,没有锁竞争。

🎈2.2 ConcurrentHashMap 做了一个激进的操作:针对读操作不加锁,只对写操作加锁

  • 读和读之间没有冲突;
  • 写和写之间有冲突;
  • 读和写之间也没有冲突。很多场景下读写之间没有锁控制,可能会读到一个只写了一半的结果,如果写操作不是原子的,此时就可能出现读到没写完的结果,就是“脏读”,所以针对这种情况,ConcurrentHashMap 使用了 volatile 保证从内存读取结果,从而解决了写操作不是原子的情况。

🎈2.3 充分利用 CAS 特性

ConcurrentHashMap 内部充分使用CAS,通过这个进一步的削减加锁操作,比如维护元素个数,size 属性通过 CAS 来更新, 避免出现重量级锁的情况。

🎈2.4 优化了扩容方式: 化整为零

1、HashMap/HashTable 扩容:
创建一个更大的数组空间,把旧的数组上的链表的每一个元素搬到新的数组上。这个扩容操作会在某次 put 的时候进行触发,如果元素的个数特别多,就会导致这样的搬运操作,比较耗时。就会有在某次 put 的时候比平时 put 的时候卡很多。(对于现实生活中用户的感受是:大部分用户使用的时候就会好好的,某个用户就会卡了)
2、ConcurrentHashMap 扩容:
如果有需要扩容的线程, 只需要创建一个新的数组, 同时只搬几个元素过去.。扩容期间, 新老数组同时存在,后续每个来操作 ConcurrentHashMap 的线程, 都会参与搬家的过程,每个操作负责搬运一小部分元素,搬完最后一个元素再把老数组删掉。
这个期间, 插入(每次 put)只往新数组加,同时进行一部分搬运(把一小部分旧的元素搬运到新数组);
查找(每次 get)需要同时查新数组和老数组;
每次 remove,只把元素删了就行。

🎈3 相关面试题

🎈1. ConcurrentHashMap的读是否要加锁,为什么?
不需要!读操作没有加锁.。目的是为了进一步降低锁冲突的概率。为了保证读到刚修改的数据, 搭配了volatile 关键字,可以解决不是原子的问题。
🎈 2. ConcurrentHashMap在 jdk1.8 做了哪些优化?
取消了分段锁, 直接给每个哈希桶(每个链表)分配了一个锁(就是以每个链表的头结点对象作为锁对象),图示在2.1处可见。将原来 数组 + 链表 的实现方式改进成 数组 + 链表 / 红黑树 的方式。 当链表较长的时候(>= 8 个元素)就转换成红黑树。
在JDK1.7之前都是分段锁,把若干个哈希桶分成一个"段" (Segment), 针对每个段分别加锁。 当两个线程访问的数据恰好在同一个段上的时候, 才触发锁竞争。图示如下:
在这里插入图片描述
🎈 3. Hashtable和HashMap、ConcurrentHashMap 之间的区别?
HashMap: 线程不安全, key 允许为 null。
Hashtable: 线程安全, 使用 synchronized 锁 Hashtable 对象, 效率较低, key 不允许为 null。
ConcurrentHashMap: 线程安全. 使用 synchronized 锁每个链表头结点, 锁冲突概率低, 充分利用CAS 机制, 优化了扩容方式,key 不允许为 null。
具体区别可在上述文章中看到,此处不详说。

  • 1
    点赞
  • 4
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值