Java集合面试题汇总【附答案】持续更新

1：HashMap 的数据结构？

A：哈希表结构（链表散列：数组+链表）实现，结合数组和链表的优点。当链表长度超过 8 时，链表转换为红黑树。

transient Node<K,V>\[\] table;

2：HashMap 的工作原理？

HashMap 底层是 hash 数组和单向链表实现，数组中的每个元素都是链表，由 Node 内部类（实现 Map.Entry接口）实现，HashMap 通过 put & get 方法存储和获取。

存储对象时，将 K/V 键值传给 put() 方法：

①、调用 hash(K) 方法计算 K 的 hash 值，然后结合数组长度，计算得数组下标；

②、调整数组大小（当容器中的元素个数大于 capacity * loadfactor 时，容器会进行扩容resize 为 2n）；

③、i.如果 K 的 hash 值在 HashMap 中不存在，则执行插入，若存在，则发生碰撞；

ii.如果 K 的 hash 值在 HashMap 中存在，且它们两者 equals 返回 true，则更新键值对；

iii. 如果 K 的 hash 值在 HashMap 中存在，且它们两者 equals 返回 false，则插入链表的尾部（尾插法）或者红黑树中（树的添加方式）。

（JDK 1.7 之前使用头插法、JDK 1.8 使用尾插法）（注意：当碰撞导致链表大于 TREEIFY_THRESHOLD = 8 时，就把链表转换成红黑树）

获取对象时，将 K 传给 get() 方法：①、调用 hash(K) 方法（计算 K 的 hash 值）从而获取该键值所在链表的数组下标；②、顺序遍历链表，equals()方法查找相同 Node 链表中 K 值对应的 V 值。

hashCode 是定位的，存储位置；equals是定性的，比较两者是否相等。

3.当两个对象的 hashCode 相同会发生什么？

因为 hashCode 相同，不一定就是相等的（equals方法比较），所以两个对象所在数组的下标相同，"碰撞"就此发生。又因为 HashMap 使用链表存储对象，这个 Node 会存储到链表中。为什么要重写 hashcode 和 equals 方法？推荐看下。

4.你知道 hash 的实现吗？为什么要这样实现？

JDK 1.8 中，是通过 hashCode() 的高 16 位异或低 16 位实现的：(h = k.hashCode()) ^ (h >>> 16)，主要是从速度，功效和质量来考虑的，减少系统的开销，也不会造成因为高位没有参与下标的计算，从而引起的碰撞。

5.为什么要用异或运算符？

保证了对象的 hashCode 的 32 位值只要有一位发生改变，整个 hash() 返回值就会改变。尽可能的减少碰撞。

6.HashMap 的 table 的容量如何确定？loadFactor 是什么？该容量如何变化？这种变化会带来什么问题？

①、table 数组大小是由 capacity 这个参数确定的，默认是16，也可以构造时传入，最大限制是1<<30；

②、loadFactor 是装载因子，主要目的是用来确认table 数组是否需要动态扩展，默认值是0.75，比如table 数组大小为 16，装载因子为 0.75 时，threshold 就是12，当 table 的实际大小超过 12 时，table就需要动态扩容；

③、扩容时，调用 resize() 方法，将 table 长度变为原来的两倍（注意是 table 长度，而不是 threshold）

④、如果数据很大的情况下，扩展时将会带来性能的损失，在性能要求很高的地方，这种损失很可能很致命。

7.HashMap中put方法的过程？

答：“调用哈希函数获取Key对应的hash值，再计算其数组下标；

如果没有出现哈希冲突，则直接放入数组；如果出现哈希冲突，则以链表的方式放在链表后面；

如果链表长度超过阀值( TREEIFY THRESHOLD==8)，就把链表转成红黑树，链表长度低于6，就把红黑树转回链表;

如果结点的key已经存在，则替换其value即可；

如果集合中的键值对大于12，调用resize方法进行数组扩容。”

8.数组扩容的过程？

创建一个新的数组，其容量为旧数组的两倍，并重新计算旧数组中结点的存储位置。结点在新数组中的位置只有两种，原下标位置或原下标+旧数组的大小。

9.Hashmap链表长度为8时转换成红黑树，为什么是8？

当链表长度大于或等于阈值（默认为 8）的时候，如果同时还满足容量大于或等于 MIN_TREEIFY_CAPACITY（默认为 64）的要求，就会把链表转换为红黑树。

同样，后续如果由于删除或者其他原因调整了大小，当红黑树的节点小于或等于 6 个以后，又会恢复为链表形态。

每次遍历一个链表，平均查找的时间复杂度是 O(n)，n 是链表的长度。由于红黑树有自平衡的特点，可以防止不平衡情况的发生，所以可以始终将查找的时间复杂度控制在 O(log(n))。

最初链表还不是很长，所以可能 O(n) 和 O(log(n)) 的区别不大，但是如果链表越来越长，那么这种区别便会有所体现。所以为了提升查找性能，需要把链表转化为红黑树的形式

通过查看源码可以发现，默认是链表长度达到 8 就转成红黑树，而当长度降到 6 就转换回去，这体现了时间和空间平衡的思想.

如果 hashCode 分布良好，也就是 hash 计算的结果离散好的话，那么红黑树这种形式是很少会被用到的，因为各个值都均匀分布，很少出现链表很长的情况。在理想情况下，链表长度符合泊松分布，各个长度的命中概率依次递减，当长度为 8 的时候，概率仅为 0.00000006。这是一个小于千万分之一的概率，通常我们的 Map 里面是不会存储这么多的数据的，所以通常情况下，并不会发生从链表向红黑树的转换。转为红黑树更多的是一种保底策略，用来保证极端情况下查询的效率。

https://blog.csdn.net/kyle_wu_/article/details/113578055

10.HashMap出现Hash DOS攻击的问题

无论我们服务端使用什么语言，我们拿到json格式的数据之后都需要做jsonDecode(),将json串转换为json对象，而对象默认会存储于Hash Table，而Hash Table很容易被碰撞攻击。我只要将攻击数据放在json中，服务端程序在做jsonDecode()时必定中招，中招后CPU会立刻飙升至100%。16核的CPU，16个请求就能达到DoS的目的

https://www.shuzhiduo.com/A/n2d92M3vzD/

11.jdk1.8之前并发操作HashMap时为什么会有死循环的问题？

JDK1.7中，当两个线程同时操作hashmap进行扩容时，会导致链表形成环形数据结构，查找时会陷入死循环

https://blog.csdn.net/qq_38157516/article/details/81024027

12.HashMap扩容时每个entry需要再计算一次hash吗？

jdk1.7 以及jdk1.8 对于每一个元素 都只会计算一次hash值，计算得到hash之后就将这个hash值放置到entry中，以后都不会再次计算

https://segmentfault.com/q/1010000009741782

13.HashMap的数组长度为什么要保证是2的幂？

当数组长度不为2的n次幂 的时候，hashCode 值与数组长度减一做与运算 的时候，会出现重复的数据，

因为不为2的n次幂 的话，对应的二进制数肯定有一位为0 , 这样不管你的hashCode 值对应的该位，是0还是1 ,

最终得到的该位上的数肯定是0，这带来的问题就是HashMap上的数组元素分布不均匀，而数组上的某些位置，永远也用不到

https://blog.csdn.net/Tane_1018/article/details/103392267

14.扩容时rehash的优化

在JDK1.7的时候，是将数组扩容为两倍，然后将HashMap中所有的key重新进行hash寻址然后再放入到新的位置

hash寻址算法是 index =（n - 1） & hash，n是数组的容量，hash是key的hash值

JDK1.8中，只需要看原来的hash值在扩容后新增的那一位是1还是0，如果是0的话原索引没变，是1的话索引变成“原索引+oldCap”

参考：

https://blog.csdn.net/LO_YUN/article/details/104993680?utm_medium=distribute.pc_aggpage_search_result.none-task-blog-2~aggregatepage~first_rank_ecpm_v1~rank_v31_ecpm-1-104993680.pc_agg_new_rank&utm_term=HashMap%E6%89%A9%E5%AE%B9%E6%97%B6%E9%81%BF%E5%85%8Drehash%E7%9A%84%E4%BC%98%E5%8C%96&spm=1000.2123.3001.4430

15.拉链法导致的链表过深问题为什么不用二叉查找树代替，而选择红黑树？为什么不一直使用红黑树？

之所以选择红黑树是为了解决二叉查找树的缺陷，二叉查找树在特殊情况下会变成一条线性结构（这就跟原来使用链表结构一样了，造成很深的问题），遍历查找会非常慢。推荐：面试问红黑树，我脸都绿了。

而红黑树在插入新数据后可能需要通过左旋，右旋、变色这些操作来保持平衡，引入红黑树就是为了查找数据快，解决链表查询深度的问题，我们知道红黑树属于平衡二叉树，但是为了保持“平衡”是需要付出代价的，但是该代价所损耗的资源要比遍历线性链表要少，所以当长度大于8的时候，会使用红黑树，如果链表长度很短的话，根本不需要引入红黑树，引入反而会慢。

16.说说你对红黑树的见解？

• 每个节点非红即黑

• 根节点总是黑色的

• 如果节点是红色的，则它的子节点必须是黑色的（反之不一定）

• 每个叶子节点都是黑色的空节点（NIL节点）

• 从根节点到叶节点或空子节点的每条路径，必须包含相同数目的黑色节点（即相同的黑色高度）

17.jdk8中对HashMap做了哪些改变？

在java 1.8中，如果链表的长度超过了8，那么链表将转换为红黑树。（桶的数量必须大于64，小于64的时候只会扩容）

发生hash碰撞时，java 1.7 会在链表的头部插入，而java 1.8会在链表的尾部插入

在java 1.8中，Entry被Node替代（换了一个马甲）

18.HashMap，LinkedHashMap，TreeMap 有什么区别？

HashMap 参考其他问题；

LinkedHashMap 保存了记录的插入顺序，在用 Iterator 遍历时，先取到的记录肯定是先插入的；遍历比 HashMap 慢；

TreeMap 实现 SortMap 接口，能够把它保存的记录根据键排序（默认按键值升序排序，也可以指定排序的比较器）

19.HashMap & TreeMap & LinkedHashMap 使用场景？

一般情况下，使用最多的是 HashMap。

HashMap：在 Map 中插入、删除和定位元素时；

TreeMap：在需要按自然顺序或自定义顺序遍历键的情况下；

LinkedHashMap：在需要输出的顺序和输入的顺序相同的情况下。

20.LinkedHashMap：了解基本原理、哪两种有序、如何用它实现LRU ?

LinkedHashMap继承HashMap，基于HashMap+双向链表实现。（HashMap是数组+链表+红黑树实现的）

LinkedHashMap是有序的，有两种顺序：插入顺序和访问顺序。默认为插入顺序，如果为访问顺序，那么put和get已存在的节点时，会将该节点移动到双向链表的尾部（实际上是先删后插）插入顺序和访问顺序的转换是定义accessOrder参数的值，默认为false，为true则表示为访问顺序

LinkedHashMap与HashMap的存取数据操作基本是一致的，只是增加了双向链表保证数据的有序性

LinkedHashMap与HashMap都是线程不安全的

##################################

定义LRULinkedHashMap继承LinkedHashMap，并重写removeEldestEntry() 方法，这个方法返回boolean值，返回true代表需要删除最老的节点，在插入元素时，会判断是否达到移除元素的时机。

要注意的就是创建实例对象的时候需要传入size和accessOrder参数（accessOrder= ture）

21.HashMap 和 HashTable 有什么区别？

①、HashMap 是线程不安全的，HashTable 是线程安全的；

②、由于线程安全，所以 HashTable 的效率比不上 HashMap；

③、HashMap最多只允许一条记录的键为null，允许多条记录的值为null，而 HashTable不允许；

④、HashMap 默认初始化数组的大小为16，HashTable 为 11，前者扩容时，扩大两倍，后者扩大两倍+1；

⑤、HashMap 需要重新计算 hash 值，而 HashTable 直接使用对象的 hashCode

22.Java 中的另一个线程安全的与 HashMap 极其类似的类是什么？同样是线程安全，它与 HashTable 在线程同步上有什么不同？

ConcurrentHashMap 类（是 Java并发包 java.util.concurrent 中提供的一个线程安全且高效的 HashMap 实现）。

HashTable 是使用 synchronize 关键字加锁的原理（就是对对象加锁）；

而针对 ConcurrentHashMap，在 JDK 1.7 中采用 分段锁的方式；JDK 1.8 中直接采用了CAS（无锁算法）+ synchronized。

23.HashMap & ConcurrentHashMap 的区别？

除了加锁，原理上无太大区别。另外，HashMap 的键值对允许有null，但是ConCurrentHashMap 都不允许。

24.为什么 ConcurrentHashMap 比 HashTable 效率要高？

HashTable 使用一把锁（锁住整个链表结构）处理并发问题，多个线程竞争一把锁，容易阻塞；

ConcurrentHashMap

• JDK 1.7 中使用分段锁（ReentrantLock + Segment + HashEntry），相当于把一个 HashMap 分成多个段，每段分配一把锁，这样支持多线程访问。锁粒度：基于 Segment，包含多个 HashEntry。

• JDK 1.8 中使用 CAS + synchronized + Node + 红黑树。锁粒度：Node（首结

点）（实现 Map.Entry）。锁粒度降低了。

25.针对 ConcurrentHashMap 锁机制具体分析（JDK 1.7 VS JDK 1.8）

JDK 1.7 中，采用分段锁的机制，实现并发的更新操作，底层采用数组+链表的存储结构，包括两个核心静态内部类 Segment 和 HashEntry。

①、Segment 继承 ReentrantLock（重入锁） 用来充当锁的角色，每个 Segment 对象守护每个散列映射表的若干个桶；

②、HashEntry 用来封装映射表的键-值对；

③、每个桶是由若干个 HashEntry 对象链接起来的链表

JDK 1.8 中，采用Node + CAS + Synchronized来保证并发安全。取消类 Segment，直接用 table 数组存储键值对；当 HashEntry 对象组成的链表长度超过 TREEIFY_THRESHOLD 时，链表转换为红黑树，提升性能。底层变更为数组 + 链表 + 红黑树。

26.ConcurrentHashMap 在 JDK 1.8 中，为什么要使用内置锁 synchronized 来代替重入锁 ReentrantLock？

①粒度降低了；

②JVM 开发团队没有放弃 synchronized，而且基于 JVM 的 synchronized 优化空间更大，更加自然。

③在大量的数据操作下，对于 JVM 的内存压力，基于 API 的 ReentrantLock 会开销更多的内存。

27.ConcurrentHashMap 简单介绍？

①、重要的常量：

private transient volatile int sizeCtl;

当为负数时，-1 表示正在初始化，-N 表示 N - 1 个线程正在进行扩容；

当为 0 时，表示 table 还没有初始化；

当为其他正数时，表示初始化或者下一次进行扩容的大小。

②、数据结构：

Node 是存储结构的基本单元，继承 HashMap 中的 Entry，用于存储数据；

TreeNode 继承 Node，但是数据结构换成了二叉树结构，是红黑树的存储结构，用于红黑树中存储数据；

TreeBin 是封装 TreeNode 的容器，提供转换红黑树的一些条件和锁的控制。

③、存储对象时（put() 方法）：

如果没有初始化，就调用 initTable() 方法来进行初始化；

如果没有 hash 冲突就直接 CAS 无锁插入；

如果需要扩容，就先进行扩容；

如果存在 hash 冲突，就加锁来保证线程安全，两种情况：一种是链表形式就直接遍历

到尾端插入，一种是红黑树就按照红黑树结构插入；

如果该链表的数量大于阀值 8，就要先转换成红黑树的结构，break 再一次进入循环

如果添加成功就调用 addCount() 方法统计 size，并且检查是否需要扩容。

④、扩容方法 transfer()：默认容量为 16，扩容时，容量变为原来的两倍。

helpTransfer()：调用多个工作线程一起帮助进行扩容，这样的效率就会更高。

⑤、获取对象时（get()方法）：

计算 hash 值，定位到该 table 索引位置，如果是首结点符合就返回；

如果遇到扩容时，会调用标记正在扩容结点 ForwardingNode.find()方法，查找该结点，匹配就返回；

以上都不符合的话，就往下遍历结点，匹配就返回，否则最后就返回 null。

28.ConcurrentHashMap 的并发度是什么？

程序运行时能够同时更新 ConccurentHashMap 且不产生锁竞争的最大线程数。默认为 16，且可以在构造函数中设置。

当用户设置并发度时，ConcurrentHashMap 会使用大于等于该值的最小2幂指数作为实际并发度（假如用户设置并发度为17，实际并发度则为32）

29.ConcurrentHashMap 如何统计所有的元素个数

JDK1.7的实现方式：

size为各个分段节点数目的总和，sum为各个segment的modCount的总和。我们知道，当segment对应的hashmap底层结构发生修改时(执行了put、remove操作)，modCount值便会加一，也就是modCount为segment对应的hashMap修改的次数，sum即为各个segment的修改次数的总和。last为上一次统计的各个segment的修改次数。通过源码我们可以得知，其会先进行两次非获取独占锁的统计，当sum==last时，也就是上一次统计和这一次统计的过程中，ConcurrentHashMap的各个分段都没有发生过改动(既没有新增节点，也没有删除节点)，则size即为对应的结果。否则，就一次性获取各个分段的独占锁，再度统计两次各个分段的节点数，而由于两次统计的过程中一直持有着各个分段的独占锁，为此，两次统计的过程中不可能会有别的线程对该ConcurrentHashMap进行改动，sum和last值必定相同，最终会退出循环。也就是size()方法最多循环执行四次，便可以得到节点数统计的结果。

JDK1.8的实现方式：

当方法被调用的时候，其它线程可能还在进行着修改操作，为此，其最终返回的值并非是精确的当前情况下的统计结果，其只是一个“大概”值。当想要获得精确值时，只能采用对各个计数单元进行加锁的方式来实现。因为ConcurrentHashMap并不需要在并发修改情况下的精确节点数目的值，由于ConcurrentHashMap该数据结构是为并发而生的，为此，获取精确的节点数目的值本身意义并不大。当你消耗了性能，获取了某个时刻节点数目的精确值，随后还是可能会被其他线程修改，导致上一刻的值无法使用，为此获取一个“大概”值便是一个较好的选择。而采用该方法实现也是线程安全的，能够确保没有线程对其进行修改的时候，其值的准确性。

参考：https://www.cnblogs.com/MyStringIsNotNull/p/12706641.html

30.ConcurrentHashMap是如何让多线程同时参与扩容？

扩容流程：

1、根据操作系统的 CPU 核数和集合 length 计算每个核一轮处理桶的个数，最小是16

2、修改 transferIndex 标志位，每个线程领取完任务就减去多少，

比如初始大小是transferIndex = table.length = 64，每个线程领取的桶个数是16，

第一个线程领取完任务后transferIndex = 48，也就是说第二个线程这时进来是从第 48 个桶开始处理，再减去16，依次类推，这就是多线程协作处理的原理

3、领取完任务之后就开始处理，如果桶为空就设置为 ForwardingNode ,

如果不为空就加锁拷贝，只有这里用到了 synchronized 关键字来加锁，为了防止拷贝的过程有其他线程在put元素进来。

拷贝完成之后也设置为 ForwardingNode节点。

4、如果某个线程分配的桶处理完了之后，再去申请，发现 transferIndex = 0，

这个时候就说明所有的桶都领取完了，但是别的线程领取任务之后有没有处理完并不知道，

该线程会将 sizeCtl 的值减1，然后判断是不是所有线程都退出了，如果还有线程在处理，就退出，

直到最后一个线程处理完，发现 sizeCtl = rs<< RESIZE_STAMP_SHIFT 也就是标识符左移 16 位，

才会将旧数组干掉，用新数组覆盖，并且会重新设置 sizeCtl 为新数组的扩容点。

以上过程总的来说分成两个部分：

1、分配任务：这部分其实很简单，就是把一个大的数组给切分，切分多个小份，然后每个线程处理其中每一小份，

当然可能就只有1个或者几个线程在扩容，那就一轮一轮的处理，一轮处理一份。

2、处理任务：复制部分主要有两点，第一点就是加锁，第二点就是处理完之后置为ForwardingNode来占位标识这个位置被迁移过了。

ForwardingNode用于占位。当别的线程发现这个槽位中是 fwd 类型的节点，则跳过这个节点。

31.TreeMap：了解数据结构、了解其key对象为什么必须要实现Compare接口、如何用它实现一致性哈希。

TreeMap底层是红黑树

key实现Compare接口,是为了实现自动排序

https://blog.csdn.net/cyywxy/article/details/81151104

一致性hash

https://www.cnblogs.com/fanguangdexiaoyuer/p/6549306.html

32.CopyOnWriteArrayList 了解写时复制机制、了解其适用场景

CopyOnWrite容器即写时复制的容器。通俗的理解是当我们往一个容器添加元素的时候，不直接往当前容器添加，而是先将当前容器进行Copy，复制出一个新的容器，然后新的容器里添加元素，添加完元素后，再将原容器的引用指向新的容器。这样做的好处是我们可以对CopyOnWrite容器进行并发的读，而不需要加锁，因为当前容器不会添加任何元素。所以CopyOnWrite容器也是一种读写分离的思想，读和写不同的容器。

写入步骤：

1️⃣获取写锁:通过ReentrantLock进行并发写入的同步

2️⃣根据操作拷贝原数组以生成新数组:Arrays.copyOf(......)

3️⃣对新数组执行操作

4️⃣将新数组引用赋值给类中定义的array变量

5️⃣释放锁

适用场景：

CopyOnWrite并发容器用于读多写少的并发场景。比如白名单，黑名单，商品类目的访问和更新场景。

缺点：

1️⃣内存占用问题

2️⃣数据一致性问题

33.思考为什么没有ConcurrentArrayList

很难去开发一个通用并且没有并发瓶颈的线程安全的List。

像ConcurrentHashMap这样的类的真正价值（The real point / value of classes）并不是它们保证了线程安全。而在于它们在保证线程安全的同时不存在并发瓶颈。举个例子，ConcurrentHashMap采用了锁分段技术和弱一致性的Map迭代器去规避并发瓶颈。

所以问题在于，像“Array List”这样的数据结构，你不知道如何去规避并发的瓶颈。拿contains() 这样一个操作来说，当你进行搜索的时候如何避免锁住整个list？

CopyOnWriteArrayList是一个有趣的例子，它规避了只读操作（如get/contains）并发的瓶颈，但是它为了做到这点，在修改操作中做了很多工作和修改可见性规则。 此外，修改操作还会锁住整个List，因此这也是一个并发瓶颈。所以从理论上来说，CopyOnWriteArrayList并不算是一个通用的并发List。

34.BlockingQueue 了解LinkedBlockingQueue、ArrayBlockingQueue、DelayQueue、SynchronousQueue。

DK7提供了7个阻塞队列。分别是：

ArrayBlockingQueue ：一个由数组结构组成的有界阻塞队列。

LinkedBlockingQueue ：一个由链表结构组成的有界阻塞队列。

PriorityBlockingQueue ：一个支持优先级排序的无界阻塞队列。

DelayQueue：一个使用优先级队列实现的无界阻塞队列。

SynchronousQueue：一个不存储元素的阻塞队列。

LinkedTransferQueue：一个由链表结构组成的无界阻塞队列。

LinkedBlockingDeque：一个由链表结构组成的双向阻塞队列。

35.LinkedBlockingQueue、DelayQueue是如何实现的？

https://blog.csdn.net/qq_31865983/article/details/105390529