ConcurrentHashMap 和HashMap常见的问题总结(jdk1.8的优化点)

5 篇文章 0 订阅

JDK1.8之后的改进:

  • 链表改成了红黑树,当链表中的结点达到一个阀值TREEIFY_THRESHOLD时,会将链表转换为红黑树,查询效率提从原来的O(n),提高为O(logn)

  • 将每个segment的分段锁ReentrantLock改为CAS+Synchronized

 

问题汇:

  • HashMap的get和put的工作原理?

  • 为何说HashMap是线程不安全的?

  • HashMap在高并发操作时会导致哪些问题?

  • ConcurrentHashMap是如何实现的?

  • ConcurrentHashMap中size方法的原理?

 

问题解答:

  • HashMap的get和put的工作原理?

1、数组+链表的结构

2、get(key)时,会用key做一次hash运算得到hashcode,根据hashcode找到数组的位置,然后查看对应数组下是否有链表,有则遍历看链表中的结点Node是否有key相等的结点,如果有则返回此结点的value,无则继续

 

  • 为何说HashMap是线程不安全的?

1、方法不是同步的

2、resize()方法在高并发的情况下,可能会引起死循环。

场景:resize()进行扩容时,需要rehash(),就是重新计算已有结点存放的位置。这个过程是非常耗费时间和空间的

问题关键:resize()方法中的transfer()方法进行位置重排时,因为不同的线程是对同一个数据块进行重排,所以才导致的问题

参考博客:https://blog.csdn.net/z69183787/article/details/64920074?locationNum=15&fps=1

 

单线程的情况

 

并发的情况

 

  • HashMap在针对jdk1.8针对resize的问题做了哪些改进?

参考博客 :  https://blog.csdn.net/aichuanwendang/article/details/53317351   》》》jdk1.8之后resize()的改进:不需要重新计算索引,且迁移新表后数据不会倒置。

不需要重新计算hash,只需要用原来的hash值,加上高一位做为索引

 

 

每个segment都有一个modCount变量保存修改次数,segment被更新时modCount会+1。所以在size()计算大小时,会判断每个segment的modCount是否有变化,如果有变化,如果有变化则重新计算,当然忍耐是有限度的,重试3次后就会将所有segment锁住,计算完size后就会释放锁。

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

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

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值