大厂面试官与水货程序员马飞机的HashMap及ConcurrentHashMap对话录

大厂面试官与水货程序员马飞机的HashMap及ConcurrentHashMap对话录

在互联网大厂的一次Java开发岗位面试中，面试官遇到了一位自称对Java有深入了解的求职者——马飞机。下面就是这次关于HashMap和ConcurrentHashMap源码实现及其原理探讨的故事。

第一轮提问

面试官： 你好，马飞机，请问你能说一下什么是HashMap吗？它的基本结构是怎样的？
马飞机： 哦，这个简单！HashMap啊，它就像一个超级大的储物柜，每个格子都有一个编号，那个编号就叫key，放进去的东西叫value。通过key就能快速找到对应的value了。
（内心OS：哎呀，这问题也太基础了吧）
面试官： 很好，那你知道它是如何解决哈希冲突的呢？
马飞机： 这个嘛...用的是链地址法，如果两个key算出来的位置一样，就把它们串成一条小火车，新的元素加到末尾去。
（内心OS：这个问题稍微有点难度，不过还好我昨晚刚复习过）
面试官： 非常不错，那你能否解释下当链表长度超过一定阈值时会发生什么？
马飞机： 超过8的话就会变成红黑树，这样查找速度更快！哇塞，您这个问题问得真好，一下子就切中要害了！

第二轮提问

面试官： 了解了这些基础知识后，我想知道你是否清楚JDK 1.7和JDK 1.8版本之间的主要差异是什么？
马飞机： 啊，这个问题嘛...让我想想，好像是1.8开始支持了并行流处理，还有就是优化了数据结构来提高性能吧？
（内心OS：好像在哪里看过，但具体细节记不清了）
面试官： 具体来说，在处理哈希碰撞方面有什么不同呢？
马飞机： 嗯...1.7是用链表，而1.8改成了红黑树对吧？哈哈，您的问题真是越来越深入了，佩服佩服！
（内心OS：希望蒙对了...）
面试官： 对于扩容机制你又了解多少？
马飞机： 扩容啊，就是当元素数量达到当前容量的负载因子时会触发扩容，然后重新分配空间，把旧的数据搬过去...大概就是这样吧？

第三轮提问

面试官： 我们换个话题，谈谈ConcurrentHashMap吧。你知道它与普通HashMap最大的区别是什么吗？
马飞机： 当然知道啦！ConcurrentHashMap是线程安全的，适合多线程环境使用。而且它还采用了分段锁技术，提高了并发性能。
（内心OS：终于有个我能答得上来的了）
面试官： 分段锁具体是怎么工作的呢？
马飞机： 就是将整个Map分成若干个小部分，每个部分都有自己的锁，这样即使某个区域被锁定，其他区域仍然可以正常访问。
（内心OS：虽然不太懂细节，但听起来挺厉害的样子）
面试官： 在JDK 1.8之后，ConcurrentHashMap是如何进一步改进以减少竞争的？
马飞机： 改进了？应该是取消了Segment结构，直接采用CAS算法加上synchronized关键字来保证线程安全了吧？哇，您真是专业，这些问题都问得好细致啊！

第四轮提问

面试官： 如果让你选择在一个高并发读写的场景下使用哪种集合类，你会怎么选？
马飞机： 那肯定是ConcurrentHashMap啦！因为它天生就是为了高并发设计的，不用担心线程安全问题。
（内心OS：总算有个能稳稳答上来的问题了）
面试官： 为什么在这种情况下不考虑使用Collections.synchronizedMap()方法包装后的HashMap呢？
马飞机： 因为那样做的话整个map都会被一把大锁给锁住，效率太低了。ConcurrentHashMap只锁住需要修改的部分，更高效。
（内心OS：幸好之前听说过这点）
面试官： 最后一个问题，你能简述一下WeakHashMap的工作原理吗？
马飞机： WeakHashMap？嗯...它是让键对象弱引用的，当没有强引用指向键对象时，垃圾回收器就可以回收该键值对，从而节省内存空间。哈哈，这个问题也很有意思哦，感觉我们聊得很愉快呢！

第五轮提问

面试官： 谢谢你的分享，马飞机。今天的讨论就到这里吧，我们会尽快给你回复。
马飞机： 感谢您给我这次机会，期待您的好消息！

答案解析

问题	答案
HashMap的基本结构	基于数组+链表/红黑树实现的散列表。
HashMap解决哈希冲突的方式	采用拉链法或红黑树（JDK 1.8以后）存储相同hash值的节点。
JDK 1.7与1.8 HashMap的区别	1.8引入了红黑树结构，并且改变了扩容时机等细节。
ConcurrentHashMap与HashMap的主要差异	前者提供了线程安全的操作，适用于多线程环境。
ConcurrentHashMap在JDK 1.8中的改进	移除了Segment概念，改为使用CAS+synchronized控制同步。
WeakHashMap工作原理	允许其内部使用的键是弱引用类型，便于GC自动清理不再使用的映射关系。