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

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

 

单线程的情况

ConcurrentHashMap 和HashMap常见的问题总结(jdk1.8的优化点)_第1张图片

 

并发的情况

ConcurrentHashMap 和HashMap常见的问题总结(jdk1.8的优化点)_第2张图片

 

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

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

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

ConcurrentHashMap 和HashMap常见的问题总结(jdk1.8的优化点)_第3张图片

ConcurrentHashMap 和HashMap常见的问题总结(jdk1.8的优化点)_第4张图片

 

 

  • ConcurrentHashMap是如何实现的?见博客《ConcurrentHashMap原理分析(锁分离技术)》

  • ConcurrentHashMap中size方法的原理?

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

你可能感兴趣的:(java,基础)