原因：
JDK1.7 中，由于多线程对HashMap进行扩容，调用了HashMap#transfer()，具体原因：某个线程执行过程中，被挂起，其他线程已经完成数据迁移，等CPU资源释放后被挂起的线程重新执行之前的逻辑，数据已经被改变，造成死循环、数据丢失。
JDK1.8 中，由于多线程对HashMap进行put操作，调用了HashMap#putVal()，具体原因：假设两个线程A、B都在进行put操作，并且hash函数计算出的插入下标是相同的，当线程A执行完第六行代码后由于时间片耗尽导致被挂起，而线程B得到时间片后在该下标处插入了元素，完成了正常的插入，然后线程A获得时间片，由于之前已经进行了hash碰撞的判断，所有此时不会再进行判断，而是直接进行插入，这就导致了线程B插入的数据被线程A覆盖了，从而线程不安全。
hashmap为什么是线程不安全的 扩展
HashMap是线程不安全的原因主要有两个：
1. 键和值的添加和删除操作可能引起哈希冲突，从而影响到其他键值对的存储。如果多个线程同时进行添加或删除操作，就可能导致存储的键值对被污染或遗失。
2. HashMap内部的结构是基于数组和链表的，如果多个线程同时修改或访问同一个链表上的元素，就可能导致链表结构被破坏或数据被覆盖。
为了解决这些问题，Java提供了线程安全的HashMap实现——ConcurrentHashMap，在多线程环境中能够更好地解决哈希冲突和结构破坏等问题，保证了高效与线程安全。它的内部采用了分段锁、CAS算法、数组+链表/红黑树等方式，保证了线程安全和高效。
hashmap为什么是线程不安全的 扩展
Hashmap是线程不安全的，因为在多线程访问时，可能会出现多个线程同时对一个bucket进行put或者get操作的情况，这时候就可能会出现覆盖或者丢失某些元素的情况。
而如果要实现线程安全，可以使用ConcurrentHashMap来替代Hashmap，它使用了一种叫做分段锁（Segment）的机制，将整个map分成了多个小的segment，每个segment只被一个线程所独占，这样，多线程访问时只需要锁住相应的segment，不需要锁住整个map，就能够达到线程安全的效果。
