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

单线程的情况

并发的情况

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

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

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

• ConcurrentHashMap是如何实现的？见博客《ConcurrentHashMap原理分析（锁分离技术）》

• ConcurrentHashMap中size方法的原理？

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