HashMap (JDK 8+ / 21) 面试核心

简介: 本资料系统梳理HashMap(JDK 8+/21)面试核心:涵盖基础特性、数组+链表+红黑树结构、哈希计算与扰动函数、树化退化条件、扩容机制、线程不安全原因及ConcurrentHashMap等解决方案、时间复杂度、常用方法及JDK版本演进对比,助你高效备战技术面试。(239字)

├── 1. 基础认知(必背开场)
│ ├── 实现接口:Map、Cloneable、Serializable
│ ├── 允许:1个 null key + 多个 null value
│ ├── 不允许:重复 key(覆盖旧值)
│ ├── 非线程安全
│ ├── 无序(不保证迭代顺序)
│ └── 默认参数
│ ├── 初始容量:16
│ ├── 负载因子:0.75f
│ └── 扩容阈值:capacity × loadFactor(默认12)

├── 2. 底层数据结构(最核心考点)
│ ├── 整体:数组 + 链表 + 红黑树(JDK 8 引入,至今不变)
│ ├── 数组:Node[] table(哈希桶 / bucket)
│ ├── 链表:Node 节点(冲突时链式存储)
│ └── 红黑树:TreeNode(链表长度 ≥8 且 容量 ≥64 时转换)
│ ├── TREEIFY_THRESHOLD = 8(转树阈值)
│ ├── UNTREEIFY_THRESHOLD = 6(退化阈值)
│ └── MIN_TREEIFY_CAPACITY = 64(最小树化容量)

├── 3. Hash 计算与定位(常追问细节)
│ ├── hash() 方法:key.hashCode() 高16位 ^ 低16位(扰动函数)
│ ├── 索引计算:(n-1) & hash (n=容量,必须2的幂)
│ └── 为什么 2 的幂?位运算更快,等价 hash % n

├── 4. 冲突解决与树化(高频深度题)
│ ├── 冲突 → 链表(JDK 7/8 头插 vs 尾插)
│ ├── 链表长度 ≥8 + 容量 ≥64 → treeifyBin() → 红黑树
│ ├── 为什么 8?泊松分布下概率极低 → hash 很可能失效
│ ├── 为什么不直接转树?小容量转树浪费内存,先扩容
│ └── 退化:remove / resize 时 ≤6 → untreeify → 链表

├── 5. 扩容机制(resize,高频必问)
│ ├── 触发:size > threshold(容量 × 负载因子)
│ ├── 新容量 = 旧容量 × 2
│ ├── rehash:所有节点重新计算索引(JDK 8+ 优化,不全量重算)
│ ├── JDK 7:头插法 → 多线程死循环
│ └── JDK 8+:尾插法 → 无死循环,但仍可能数据覆盖

├── 6. 线程不安全 & 解决方案(并发必考)
│ ├── JDK 7 表现:死循环(环形链表)
│ ├── JDK 8+ 表现:数据丢失 / 覆盖
│ └── 线程安全替代方案(按推荐顺序背)
│ ├── ConcurrentHashMap(首选,CAS + synchronized 细粒度锁)
│ ├── Collections.synchronizedMap(new HashMap<>())(全局锁,效率低)
│ ├── Hashtable(过时,全方法 synchronized)
│ └── 业务加锁(ReentrantLock / synchronized)

├── 7. 性能与复杂度
│ ├── 平均:O(1) get / put / remove
│ ├── 最坏:O(log n)(树化后)
│ ├── 极端无树化:O(n)
│ └── 迭代时间 ≈ capacity + size(容量浪费影响迭代)

├── 8. 关键方法 & 使用技巧(函数式编程常考)
│ ├── put / get / remove / containsKey
│ ├── getOrDefault
│ ├── putIfAbsent
│ ├── computeIfAbsent(懒初始化神器)
│ ├── merge(累加 / word count 经典)
│ └── forEach / entrySet / keySet / values

├── 9. JDK 版本对比(高级追问)
│ ├── JDK 7 及以前:数组 + 链表 + 头插法 + 死循环风险
│ └── JDK 8+(至今):尾插法 + 红黑树 + 扰动函数 + 无死循环

└── 10. 常见追问一句话总结(快速应对)
├── 为什么容量 2 的幂? → 位运算代替取模
├── 负载因子为什么 0.75? → 时间与空间折中
├── 为什么用红黑树而不是 AVL? → 插入/删除更快,红黑树更平衡代价小
├── 自定义对象做 key 必须做什么? → 重写 equals + hashCode,且保持一致
└── 项目中怎么优化 HashMap? → 预估容量避免多次扩容、选择合适初始容量、避免 hash 冲突严重的 key
参考文档:
https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/HashMap.html
https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/HashMap.java

目录
相关文章
|
7月前
|
存储 缓存 安全
【HashMap】HashMap 系统性知识体系全解(附《HashMap 面试八股文精简版》)
本文以JDK8为核心,对比JDK7差异,从基础认知、底层结构(数组+链表+红黑树)、哈希函数、扩容机制、线程安全、最佳实践及面试考点七大维度,系统解析HashMap原理与应用,助你构建完整知识体系。
|
缓存 网络协议 网络安全
计算机网络:应用层(上篇)
计算机网络:应用层(上篇)
511 2
|
11月前
|
运维 监控 供应链
Alibaba交易平台TMF2.0介绍
2017双11交易峰值达32.5万笔/秒,面对高并发与复杂业务需求,阿里推出TMF2.0框架,通过业务与平台分离、全链路可视化、配置化发布等创新,实现需求开发周期缩短至12天,支撑多业务快速试错与复用,构建可配置、可监控、可运维的电商技术新体系。
1414 5
Alibaba交易平台TMF2.0介绍
|
存储 NoSQL 调度
redis线程模型
redis线程模型
466 0
|
8月前
|
人工智能 运维 自然语言处理
2026年阿里云部署OpenClaw(Clawdbot)及Skills全场景应用指南
在AI智能体技术深度落地的2026年,OpenClaw(原Clawdbot,曾用名Moltbot)凭借大模型+技能插件的组合模式,打破了传统AI仅能语言交互的局限,成为个人办公提效、企业轻量协作的核心工具。而阿里云轻量应用服务器推出的OpenClaw专属一键部署方案,将原本繁琐的环境配置、依赖安装流程高度简化,让零基础用户也能快速搭建属于自己的AI自动化助手。本文将基于阿里云2026年最新部署方案,完整覆盖OpenClaw快速部署、默认Skills实战、新技能安装配置及故障排查全流程,嵌入可直接复用的代码命令,同时新增极简部署步骤速查,帮助用户高效解锁OpenClaw+Skills的全量能力。
587 1
|
5月前
|
人工智能 弹性计算 对象存储
阿里云2026优惠券全攻略:学生300元无门槛+百炼优惠券,企业迁云与出海补贴优惠券解析
阿里云2026年推出多类型优惠券,包括无门槛的学生300元优惠券及有门槛的算力、出海扶持和百炼“先用后返”等优惠券。学生优惠券覆盖广,有效期一年,适用于多种云产品,可拆分使用并与折扣叠加。百炼优惠券面向AI开发者,提供特别优惠。用户可通过阿里云控制台管理优惠券,需注意使用范围、有效期和叠加规则。企业用户可组合使用不同优惠券以优化成本。
|
7月前
|
存储 缓存 监控
90% 的 JVM 元空间 OOM,都栽在类加载与类卸载上!调优 + 排查全攻略
本文深入剖析JVM元空间OOM、频繁Full GC等生产问题,聚焦类加载机制、元空间内存模型与类卸载三要素,详解自定义类加载器泄漏、线程上下文类加载器未恢复等5大高频场景,提供参数调优、日志观测、MAT排查及修复实战方案。
981 3
|
8月前
|
存储 缓存 人工智能
10 个提升 Python 性能的实战技巧:从慢如蜗牛到快如闪电
Python常被误认为“慢”,实则瓶颈多在写法。本文提炼PyCharm团队推荐的10大性能技巧:用set查元素、预分配列表、__slots__省内存、math替代**、避免异常控制流等,每招皆可提升数倍至百倍性能,且不损可读性。(239字)
547 1
10 个提升 Python 性能的实战技巧:从慢如蜗牛到快如闪电
|
8月前
|
存储 人工智能 BI
2026年OpenClaw实战攻略:阿里云部署+200个Skills解锁+ClawHub技能生态详解
OpenClaw作为开源Agent框架的标杆,彻底改变了AI的使用逻辑——它不再是单纯的对话工具,而是能调用本地工具、系统程序、第三方服务的“全能执行者”。而Skills(技能插件)正是其核心竞争力所在,如同为AI配备了“超级外挂”,让OpenClaw能完成实时数据查询、PPT生成、邮件管理、代码开发等复杂任务。
2430 1
|
存储 缓存 NoSQL
如何解决缓存击穿?
缓存击穿是指热点数据失效时大量请求直接冲击数据库,可能导致系统崩溃。解决方案包括:永不过期策略避免缓存失效瞬间的穿透;互斥锁控制并发访问;热点预热提前刷新缓存;熔断降级在数据库压力大时返回默认值;二级缓存降低Redis压力。实际中常组合使用多种方案,如热点预热+互斥锁+熔断降级,以提升系统稳定性与性能。
1549 0