2、JDK1.8中的数据覆盖
（1）dk1.7的数据丢失、死循环问题在JDK1.8中已经得到了很好的解决，直接在HashMap的resize()中完成了数据迁移。
（2）为什么说 JDK1.8会出现数据覆盖的情况？
查看这段JDK1.8中的put操作代码：
在这里插入图片描述
如下图框中的代码是判断是否出现hash碰撞，假设两个线程A、B都在进行put操作，并且hash函数计算出的插入下标是相同的，当线程A执行完该行判断代码后由于时间片耗尽导致被挂起，而线程B得到时间片后在该下标处插入了元素，完成了正常的插入，然后线程A获得时间片，由于之前已经进行了hash碰撞的判断，所有此时不会再进行判断，而是直接进行插入，这就导致了线程B插入的数据被线程A覆盖了，从而线程不安全。
原文链接：https://blog.csdn.net/qq_46074155/article/details/120072178
ConcurrentHashMap是怎么做到线程安全的？
get方法如何线程安全地获取key、value？
put方法如何线程安全地设置key、value？
size方法如果线程安全地获取容器容量？
底层数据结构扩容时如果保证线程安全？
初始化数据结构时如果保证线程安全？
ConcurrentHashMap并发效率是如何提高的？
和加锁相比较，为什么它比HashTable效率高？
而ConcurrentHashMap则使用了锁分段（减小锁范围）、CAS（乐观锁，减小上下文切换开销，无阻塞
多个线程同时进行put操作，在初始化数组时使用了乐观锁CAS操作来决定到底是哪个线程有资格进行初始化，其他线程均只能等待。
用到的并发技巧：
volatile变量（sizeCtl）：它是一个标记位，用来告诉其他线程这个坑位有没有人在，其线程间的可见性由volatile保证。
CAS操作：CAS操作保证了设置sizeCtl标记位的原子性，保证了只有一个线程能设置成功
减小锁粒度：将Node链表的头节点作为锁，若在默认大小16情况下，将有16把锁，大大减小了锁竞争（上下文切换），就像开头所说，将串行的部分最大化缩小，在理想情况下线程的put操作都为并行操作。同时直接锁住头节点，保证了线程安全
如何实现呢？这就用到了ConcurrentHashMap中最关键的Segment。
ConcurrentHashMap中维护着一个Segment数组，每个Segment可以看做是一个HashMap。
而Segment本身继承了ReentrantLock，它本身就是一个锁。
在Segment中通过HashEntry数组来维护其内部的hash表。
每个HashEntry就代表了map中的一个K-V，用HashEntry可以组成一个链表结构，通过next字段引用到其下一个元素。
0.3 线程安全的扩容(Rehash)
HashMap的线程安全问题大部分出在扩容(rehash)的过程中。
ConcurrentHashMap的扩容只针对每个segment中的HashEntry数组进行扩容。
由上述put的源码可知，ConcurrentHashMap在rehash的时候是有锁的，所以在rehash的过程中，其他线程无法对segment的hash表做操作，这就保证了线程安全
原文链接：https://blog.csdn.net/qq_41737716/article/details/90549847