只要是对于集合有一定了解的一定都知道HashMap是线程不安全的，我们应该使用ConcurrentHashMap。但是为什么HashMap是线程不安全的呢，之前面试的时候也遇到到这样的问题，但是当时只停留在***知道是***的层面上，并没有深入理解***为什么是***。于是今天重温一个HashMap线程不安全的这个问题。
还记得 HashMap的实现原理、jdk1.7与jdk1.8的HashMap有什么区别吗？如果忘记可以到这里重新温习：Java面试题：ArrayList底层实现原理、HashMap的实现原理、HashMap的jdk1.7和jdk1.8有什么区别
在1.7版本中，HashMap使用数组+链表的方式实现，即当发生哈希冲突时，会使用链表将冲突的元素串起来。 在1.8版本中，当链表长度超过一定阈值（默认为8）时，链表会转化为红黑树，以提高查找效率。
派大星：有过了解，首先对于HashMap在1.7之前是采用的数组+链表，并且根节点是一个entry节点，它的一个内部类。数据插入过程采用的是一个头插法。头插法会在扩容的过程中调用resize方法，然后又调用transfer方法，把里面的一些entry进行了一些rehash，这个过程可能会造成链表的一个循环死循环，也就是死链。最后一点就是由于它没有加锁，也会导致在多线程并发的情况下是线程不安全的。
3、HashMap与HashTable的区别，引出ConcurrentHashMap…
HashMap死循环是一个比较常见、也是比较经典的面试题，在大厂的面试中也经常被问到。HashMap的死循环问题只在JDK1.7版本中会出现，主要是HashMap自身的工作机制，再加上并发操作，从而导致出现死循环。JDK1.8以后，官方彻底解决了这个问题。
本文主要补充对HashMap的一些理解、分析。相信大家对HashMap都很熟悉，但是其中的一些细节上的设计、思想，往往会被大家忽略，这些都是构成HashMap的重要组成部分，包括有"如何做hash"，"resize后如何保证key的位置"，"resize在高并发下引发的死循环"，"为什么 TREEIFY_THRESHOLD = 8？"，"允许null值的原因"等等，希望有你感兴趣的。
本文主要探讨下HashMap 在多线程环境下容易出现哪些问题，深层次理解其中的HashMap。
currentHashMap是线程安全并且高效的一种容器,我们就需要研究一下currentHashMap为什么既能够保证线程安全,又可以保证高效的操作
原以为自己对HashMap的源码理解的还算可以了，应该足够应付面试了。但是看到这个问题自己确实也是懵逼了一下。 查了下资料，答案是JDK1.7是插入到首部，1.8改为了尾部。
经常有些面试官会问，是否了解过 HashMap 在多线程环境下使用时可能会发生死循环，导致服务器 cpu 100% 的线上故障？
之前在面试的过程中有被问到，ConcurrentHashMap的size方法是线程安全的吗？ 这个问题，确实没有答好。这次来根据源码来了解一下，具体是怎么一个实现过程。
JDK1.8以前Hashmap底层是数组和链表结合在一起使用，也就是散列链表。hashmap的key的hashcode()扰动函数处理后得到hash值，然后通过（n-1）& hash 判断当前元素存放的位置，如果当前位置存在元素的话，就判断当前位置存在的元素是否与之相同，相同则直接覆盖，不相同就通过拉链法解决冲突。
Java为数据结构中的映射定义了一个接口java.util.Map,分别是HashMap、Hashtable、LinkedHashMap和TreeMap，类继承关系如下图所示：
JDK 1.7 HashMap 采用数组 + 链表的数据结构，多线程背景下，在数组扩容的时候，存在 Entry 链死循环和数据丢失问题。
在JDK1.6，JDK1.7中，HashMap采用位桶+链表实现，即使用链表处理冲突，同一hash值的链表都存储在一个链表里。但是当位于一个桶中的元素较多，即hash值相等的元素较多时，通过key值依次查找的效率较低；链表是为了解决哈希冲突而存在内部解决方案（拉链法）；
Map接口的实现类主要有：HashMap、TreeMap、Hashtable、ConcurrentHashMap
前言：我们都知道HashMap是线程不安全的，在多线程环境中不建议使用，但是其线程不安全主要体现在什么地方呢，本文将对该问题进行解密。
写在前面：2020年面试必备的Java后端进阶面试题总结了一份复习指南在Github上，内容详细，图文并茂，有需要学习的朋友可以Star一下！ GitHub地址：https://github.com/abel-max/Java-Study-Note/tree/master
cnblogs.com/developer_chan/p/10450908.html
本栏目Java开发岗高频面试题主要出自以下各技术栈：Java基础知识、集合容器、并发编程、JVM、Spring全家桶、MyBatis等ORMapping框架、MySQL数据库、Redis缓存、RabbitMQ消息队列、Linux操作技巧等。
在jdk1.8中对HashMap做了很多优化，这里先分析在jdk1.7中的问题，相信大家都知道在jdk1.7多线程环境下HashMap容易出现死循环，这里我们先用代码来模拟出现死循环的情况：
我们都知道HashMap是线程不安全的，在多线程环境中不建议使用，但是其线程不安全主要体现在什么地方呢，本文将对该问题进行解密。
译>：HashMap的实例有两个影响其性能的参数——“初始容量initial capacity”和“负载因子load factor”，容量指的是哈希表中桶（buckets）的数目，初始容量即为创建哈希表时桶的数目；负载因子是衡量哈希表在自动扩容之前的填充程度的度量，即当哈希表中的条目数超过（负载因子与当前容量的乘积）时，哈希表将会自动扩容为原来桶数目的2倍，然后将已有数据进行重新映射（即内部数据结构将被重建）。
上篇文章详细剖析多线程下的linkedHashMap读写锁下的内存泄漏问题。不少朋友私下说这种按步骤详细剖析的方式很不错。
ConcurrentHashMap相当于是HashMap的多线程版本，它的功能本质上和HashMap没什么区别。因为HashMap在并发操作的时候会出现各种问题，比如死循环问题、数据覆盖等问题。而这些问题，只要使用ConcurrentHashMap就可以完美地解决。那问题来到了，ConcurrentHashMap它是如何保证线程安全的呢？
HashMap、CurrentHashMap 的实现原理基本都是BAT面试必考内容，阿里P8架构师谈：深入探讨HashMap的底层结构、原理、扩容机制深入谈过hashmap的实现原理以及在JDK 1.8的实现区别，今天主要谈CurrentHashMap的实现原理，以及在JDK1.7和1.8的区别。 哈希表
第一种可以把 key value 同时取出，第二种还得需要通过 key 取一次 value，效率较低, 第三种需要 JDK1.8 以上，通过外层遍历 table，内层遍历链表或红黑树。
双向循环链表：最后一个节点的 next 指向head，而 head 的prev指向最后一个节点，构成一个环。
本篇文章站在多线程并发安全角度，带你了解多线程并发使用 HashMap 将会引发的问题，深入学习 ConcurrentHashMap ，带你彻底掌握这些核心技术。
JDK1.8中的HashMap较于前代有了较大的变更，主要变化在于扩容机制的改变。在JDK1.7及之前HashMap在扩容进行数组拷贝的时候采用的是头插法，因此会造成并发情景下形成环状链表造成死循环的问题。JDK1.8中改用了尾插法进行数组拷贝，修复了这个问题。
HashMap 数据结构为 数组+链表（JDk1.7），JDK1.8中增加了红黑树，其中：链表的节点存储的是一个 Entry 对象，每个Entry 对象存储四个属性（hash，key，value，next）
HashMap使用链表法避免哈希冲突（相同hash值），当链表长度大于TREEIFY_THRESHOLD（默认为8）时，将链表转换为红黑树。当小于等于UNTREEIFY_THRESHOLD（默认为6）时，又会退化回链表以达到性能均衡。 下图为HashMap的数据结构（数组+链表+红黑树 ）
我们都知道对于给定的key先计算其hashcode然后hashcode再对数组的长度取余从而得到其所在的数组下标，当出现hash冲突时从，采用的链地址法将相同位置的Entry串到一条链表上，但是随着链表长度的增大，会极大的降低查找速率，因此当链表长度大于8时会由链表转为红黑树。（使用红黑树而不直接使用经典的AVL树的原因是红黑树与AVL树查询效率相当，但是红黑树牺牲一部分的平衡性从而提高了插入删除的效率，总体效率得到提升）。
容量的默认大小是 16，负载因子是 0.75，当 HashMap 的 size > 16*0.75 时就会发生扩容(容量和负载因子都可以自由调整)。
摘要 HashMap是Java程序员使用频率最高的用于映射(键值对)处理的数据类型。随着JDK（Java Developmet Kit）版本的更新，JDK1.8对HashMap底层的实现进行了优化，例如引入红黑树的数据结构和扩容的优化等。本文结合JDK1.7和JDK1.8的区别，深入探讨HashMap的结构实现和功能原理。 简介 Java为数据结构中的映射定义了一个接口java.util.Map，此接口主要有四个常用的实现类，分别是HashMap、Hashtable、LinkedHashMap和TreeM
《HashMap》中已经分析了HashMap的实现，jdk1.7与jdk1.8的实现有很多区别，现在我们分析一下两个版本的差异：
由于近期忙着搬家，又偷懒了几个礼拜！ 其实我很早以前就想写一篇关于HashMap的面试专题。对于JAVA求职者来说，HashMap可谓是集合类的重中之重，甚至你在复习的时候，其他集合类都不用看，专攻HashMap即可。 然而，鉴于网上大部分的关于HashMap的面试方向文章，烟哥看过后都不是太满意。因此，斗胆尝试也写一篇关于HashMap的面试专题文章!
针对这个问题，嗯，当然是必须看过HashMap源码。至于原理，下面那张图很清楚了:
在淘宝内网里看到同事发了贴说了一个CPU被100%的线上故障，并且这个事发生了很多次，原因是在Java语言在并发情况下使用HashMap造成Race Condition，从而导致死循环。这个事情我4、5年前也经历过，本来觉得没什么好写的，因为Java的HashMap是非线程安全的，所以在并发下必然出现问题。但是，我发现近几年，很多人都经历过这个事（在网上查“HashMap Infinite Loop”可以看到很多人都在说这个事）所以，觉得这个是个普遍问题，需要写篇疫苗文章说一下这个事，并且给大家看看一个完美的“Race Condition”是怎么形成的。
在外部调用静态方法时，可以使用 类名.方法名 的方式，也可以使用 对象.方法名 的方式，而实例方法只有后对象.方法名 这种方式。也就是说，调用静态方法可以无需创建对象 。
这个问题是在面试时常问的几个问题，一般在问这个问题之前会问Hashmap和HashTable的区别？面试者一般会回答：hashtable是线程安全的，hashmap是线程不安全的。
为了能让 HashMap 存取高效，尽量较少碰撞，也就是要尽量把数据分配均匀。 Hash 值的范围为 -2147483648 到 2147483647，前后加起来大概是40亿的映射空间，只要哈希函数映射得比较均匀松散，一般情况是很难出现碰撞的。但问题是，一个40亿长度的数组，内存是放不下的，所以这个散列值是不能直接拿来用的。用之前，还要先做对数组长度的取模运算，得到的余数，才是用来要存放的位置（也就是对应的数组下标）。这个数组下标的计算方法是 (n - 1) & hash。（n代表数组长度）。这也就解释了 HashMap 的长度为什么是2的幂次方。
以上就是我目前的理解,还有一种使用迭代器时的fast-fail，以后有机会更新。 关于ConcurrentHashMap可以看看我的另外一篇，欢迎指正：ConcurrentHashMap浅析
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
腾讯会议
实时音视频
