8.19ConCurrentHashMap

一.HashTable的加锁策略的问题:

1.在方法上直接加synchronized,相当于对this加锁,针对同一个对象的任意一个操作都会对this加锁,如果多个线程都想操作,会发生激烈的锁竞争,只能一个一个串行执行,并发量低,执行效率低.

2.一旦发生扩容,会一口气全部完成,相当耗时间,会发生突然间卡了很久的情况.

二.ConCurrentHashMap的改进:

1.(核心)减小锁的粒度,每个链表有一把锁(对头节点对象加锁),大部分情况不涉及锁冲突.

2. 大量使用CAS操作(比如size++),不涉及锁冲突.

3.写操作进行加锁,读操作不加锁,同时读写操作不冲突,如果同时读写,可能会读到旧版数据,但不会读到半个数据.

4.扩容时,化整为零,把旧数组上的数据逐渐往新数组上搬,一段时间内会出现新旧数组并存.

a)新增元素时往新数组上插入.

b)删除元素如果新的数组上没有,就删除旧的.

c)查找元素时新旧数组都要找.

d)修改元素时同意把元素整到新数组上.

上述每个操作都会触发一定程度的搬运,每次搬运一点,就可以保证不会卡很久没有响应,全部搬完后把旧数组销毁.

三.ConCurrentHashMap分段锁

Java8前使用分段锁,java8及以后每个链表一把锁.

分段锁:一把锁管多个链表.

  • 3
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论

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

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

数九天有一个秘密

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值