Java（编程语言）核心基础与集合

正式学习入口

本文件保留早期单篇教材，便于兼容既有链接；精通级复习、详细答案、图解和综合题请以拆分后的正式子文档为准。

顺序	正式子文档	核心目标
0	知识图谱与复习路线	学习顺序、版本边界和迁移说明
1	Object（对象基类）、String（字符串）与不可变设计	对象契约、字符串底层和稳定业务键
2	泛型、反射、注解与异常	类型系统、元数据和事务异常边界
3	List（列表接口）、Set（集合接口）与 Queue（队列接口）集合体系	集合选型、扩容、顺序与背压
4	HashMap（哈希映射）与哈希集合	桶定位、扩容、树化和可变键故障
5	ConcurrentHashMap（并发哈希映射）与集合并发	桶级协调、协助扩容和单机并发边界
6	项目案例、排障与综合题库	WMS（仓储管理系统）、支付、IoT（物联网）与线上排障

兼容保留的旧版正文

1. 简历关联点

简历里写到 Java（编程语言）全栈高级开发、WMS（仓储管理系统）、跨境物流、库存防超卖、支付资金一致性、异步任务、Runner（执行器）调度和 IoT（物联网）报警风暴治理。这些项目虽然看起来更偏架构和业务，但面试官经常会从 Java（编程语言）基础和集合体系切入，判断候选人是不是只会使用框架。

本模块要支撑下面几类追问：

Object（对象基类）的 equals（相等判断方法）和 hashCode（哈希码方法）为什么必须一起重写。
String（字符串）为什么不可变，StringBuilder（可变字符串构建器）和 StringBuffer（线程安全字符串构建器）怎么选。
final（最终关键字）、static（静态关键字）、泛型、反射、注解、异常体系在工程里怎么用。
ArrayList（数组列表）、LinkedList（链表列表）、HashMap（哈希映射）、LinkedHashMap（链式哈希映射）、TreeMap（树映射）、HashSet（哈希集合）分别适合什么场景。
HashMap（哈希映射）底层数组、链表、红黑树、扩容、扰动函数、线程不安全怎么讲。
ConcurrentHashMap（并发哈希映射）为什么比 Hashtable（哈希表）更适合高并发场景。

2. 面试主线

回答 Java（编程语言）核心基础问题时，不要只背 API（应用程序接口），要按“对象语义 -> 内存和不可变性 -> 集合数据结构 -> 并发安全 -> 项目落地”展开。

Object（对象基类）定义了 Java（编程语言）对象的基础行为，equals（相等判断方法）和 hashCode（哈希码方法）决定对象在 HashMap（哈希映射）和 HashSet（哈希集合）里的身份语义。
String（字符串）不可变性带来线程安全、缓存复用和哈希稳定，但大量拼接要用 StringBuilder（可变字符串构建器）。
集合不是只看“能不能存数据”，要看查询、插入、删除、排序、去重、并发和内存成本。
HashMap（哈希映射）是高频重点，必须能讲清 hash（哈希）定位、冲突处理、树化、扩容和线程不安全。
项目落地时，要把集合选择和订单去重、库存聚合、支付流水幂等、报警窗口聚合这些场景绑定起来。

3. 基础知识

3.1 Object（对象基类）核心方法

Object（对象基类）是所有 Java（编程语言）类的根类。面试重点不是背有哪些方法，而是讲清对象身份、对象相等、对象哈希、对象克隆和对象生命周期相关方法的边界。

方法	作用	面试重点
equals（相等判断方法）	判断两个对象业务语义是否相等	默认比较引用地址，业务对象通常要重写
hashCode（哈希码方法）	返回对象哈希值	与 equals（相等判断方法）保持一致，否则 HashMap（哈希映射）查找会异常
toString（字符串展示方法）	输出对象可读信息	日志排查时很重要，避免输出敏感字段
clone（克隆）	创建对象副本	浅拷贝和深拷贝要分清
wait（等待方法）/notify（通知方法）	对象监视器协作	必须持有 synchronized（同步锁）监视器
finalize（终结方法）	对象回收前回调	不推荐依赖，可能导致 GC（垃圾回收）不可控

equals（相等判断方法）和 hashCode（哈希码方法）的核心约束：

如果两个对象 equals（相等判断方法）返回 true（真值），hashCode（哈希码方法）必须相同。
如果两个对象 hashCode（哈希码方法）相同，equals（相等判断方法）不一定返回 true（真值），因为可能发生 hash collision（哈希冲突）。
作为 HashMap（哈希映射）键的对象，参与 equals（相等判断方法）和 hashCode（哈希码方法）计算的字段最好保持不可变。

HashMap（哈希映射）判断“键是否已经存在”不是只调用 equals（相等判断方法），而是分两级完成：

flowchart LR
    A["传入 key（键）"] --> B["调用 hashCode（哈希码方法）"]
    B --> C["扰动并计算 bucket（桶）下标"]
    C --> D{"bucket（桶）是否为空?"}
    D -->|"是"| E["确定不存在"]
    D -->|"否"| F["比较 hash（哈希值）"]
    F --> G{"hash（哈希值）相同?"}
    G -->|"否"| H["继续检查下一个节点"]
    G -->|"是"| I["调用 equals（相等判断方法）"]
    I --> J{"业务语义相等?"}
    J -->|"是"| K["命中同一个键"]
    J -->|"否"| H

具体数据演绎：有两个支付对象 A 和 B，它们的支付流水号都是 PAY-1001。业务重写 equals（相等判断方法）后，A.equals(B) 返回 true（真值），但如果没有同步重写 hashCode（哈希码方法），二者仍可能使用对象身份生成不同哈希值。假设容量为 16，A 最终进入 3 号 bucket（桶），B 查询时却先定位到 11 号 bucket（桶）。HashMap（哈希映射）只在 11 号 bucket（桶）中继续调用 equals（相等判断方法），根本不会遍历 3 号 bucket（桶），所以会错误地认为 A 不存在。

操作	对象	equals（相等判断方法）业务字段	hashCode（哈希码方法）	bucket（桶）	结果
写入	`A`	`PAY-1001`	35	3	写入成功
查询	`B`	`PAY-1001`	75	11	查找失败

正确实现应让相同业务字段参与 equals（相等判断方法）和 hashCode（哈希码方法）计算，使 A 与 B 得到一致的哈希结果。反方向则不要求成立：不同对象可以有相同 hashCode（哈希码方法），HashMap（哈希映射）会继续用 equals（相等判断方法）解决 hash collision（哈希冲突）。

3.2 String（字符串）与不可变对象

String（字符串）不可变，意味着对象创建后内容不能被修改。看似简单，但它支撑了字符串常量池、线程安全、缓存复用和 HashMap（哈希映射）键稳定性。

类型	是否可变	是否线程安全	适用场景
String（字符串）	否	是	常量、配置、缓存 key（键）、业务编号
StringBuilder（可变字符串构建器）	是	否	单线程大量字符串拼接
StringBuffer（线程安全字符串构建器）	是	是	多线程共享拼接，实际项目较少使用

String（字符串）不可变的价值：

线程安全：多个线程共享同一个 String（字符串）对象不会改变内容。
常量池复用：相同字面量可以复用，减少内存浪费。
哈希稳定：作为 HashMap（哈希映射）键时，hashCode（哈希码方法）不会因为内容变化而失效。
安全边界：URL（统一资源定位符）、文件路径、类名、权限标识不容易被中途篡改。

String（字符串）的不可变性不是只靠 final（最终关键字），而是由一组设计共同保证：

String（字符串）类本身使用 final（最终关键字）修饰，外部不能通过继承覆盖关键方法来伪造“内容不变”的语义。
保存字符内容的字段对外不可见。JDK（Java 开发工具包）8 主要使用 private final char[]；JDK（Java 开发工具包）9 以后主要使用 private final byte[] 和 coder（编码标记），这项 Compact Strings（紧凑字符串）设计可让拉丁字符以单字节保存，降低内存占用。
String（字符串）没有公开修改内部存储的方法。concat（连接）、replace（替换）、substring（截取）等操作需要变化时返回新的 String（字符串），原对象仍保持不变；若结果没有变化，某些方法也可以直接返回原对象。
构造和转换过程不应把可变数组直接暴露给调用者，而是通过复制或受控创建避免外部持有内部存储引用；toCharArray（转为字符数组）返回的是副本，修改副本不会改变原 String（字符串）。
hashCode（哈希码方法）可以缓存计算结果，因为内容永远不变；同一个 String（字符串）多次作为 HashMap（哈希映射）的键时无需担心哈希值改变。

flowchart LR
    A["String（字符串）对象 A<br/>内容: PAY"] --> B["concat（连接）追加 -1001"]
    B --> C["创建新 String（字符串）对象 B<br/>内容: PAY-1001"]
    A --> D["原对象仍为 PAY"]
    C --> E["B 可进入 StringTable（字符串常量池表）或作为稳定 key（键）"]

要区分“引用不变”和“对象不变”：final（最终关键字）引用只是不允许重新指向，若它指向普通数组，数组元素依然能被修改。String（字符串）之所以不可变，是类封闭、字段封装、没有修改入口、防御性处理和所有变换返回新对象共同形成的结果。使用反射或底层不安全接口强行改内存属于突破封装，不是正常 Java（编程语言）语义下的可变能力。

3.3 final（最终关键字）、static（静态关键字）和不可变设计

final（最终关键字）用于限制变化，static（静态关键字）用于表达类级别共享。面试时要能讲清“限制变化”和“共享状态”的边界。

关键字	修饰对象	含义	风险点
final（最终关键字）	类	类不能被继承	扩展性降低
final（最终关键字）	方法	方法不能被重写	子类无法改变行为
final（最终关键字）	变量	引用不能重新指向	引用对象内部仍可能可变
static（静态关键字）	字段	类级别共享字段	共享可变状态容易引发并发问题
static（静态关键字）	方法	类级别方法	不依赖实例状态
static（静态关键字）	内部类	不持有外部类实例	常用于工具或节点结构

不可变对象常见设计：

类用 final（最终关键字）修饰，避免子类破坏不可变约束。
字段用 private（私有访问控制）和 final（最终关键字）修饰。
构造时完成所有字段赋值。
不暴露可变对象引用，必要时做 defensive copy（防御性拷贝）。

3.4 泛型、反射和注解

泛型让集合和组件具备类型约束，反射让程序运行时检查和操作类信息，注解则把元数据声明在代码结构上。三者在 Spring（Java 应用框架）、MyBatis（持久层框架）、序列化、参数校验、权限控制中非常常见。

机制	解决问题	工程场景
泛型	编译期类型约束，减少强制转换	`List<Order>`、统一返回结果、仓储接口
反射	运行时获取类、字段、方法信息	Spring（Java 应用框架）创建 Bean（对象实例）、MyBatis（持久层框架）映射字段
注解	在代码上声明元数据	Controller（控制器）、事务、权限、校验、日志埋点

泛型的核心限制是 type erasure（类型擦除）：Java（编程语言）泛型主要在编译期生效，运行期很多泛型信息会被擦除。因此 List<String> 和 List<Integer> 在运行期原始类型都接近 List（列表接口）。

反射的风险：

性能成本比直接调用高。
破坏封装，可能访问 private（私有访问控制）成员。
运行期才暴露错误，缺少编译期保护。
在高频路径使用反射要谨慎，通常需要缓存 Field（字段元信息）或 Method（方法元信息）。

3.5 异常体系

Java（编程语言）异常体系分为 Throwable（可抛出对象）、Error（严重错误）和 Exception（异常）。面试重点是 checked exception（受检异常）和 unchecked exception（非受检异常）的边界，以及项目里如何设计业务异常。

flowchart TD
    T["Throwable（可抛出对象）"] --> E1["Error（严重错误）"]
    T --> E2["Exception（异常）"]
    E2 --> CE["checked exception（受检异常）"]
    E2 --> RE["RuntimeException（运行时异常）"]
    RE --> NPE["NullPointerException（空指针异常）"]
    RE --> IAE["IllegalArgumentException（非法参数异常）"]
    E1 --> OOM["OutOfMemoryError（内存溢出错误）"]
    E1 --> SOE["StackOverflowError（栈溢出错误）"]

异常设计建议：

参数错误、状态错误、业务规则不满足，通常用业务异常或 RuntimeException（运行时异常）子类。
外部系统调用失败要保留 error code（错误码）、requestId（请求标识）、TraceId（链路标识）和原始异常。
不要吞异常；至少要记录上下文，必要时转换成业务可理解的错误。
事务方法里要注意异常类型和 rollback（回滚）规则，避免异常被捕获后事务误提交。

4. 底层原理

4.1 ArrayList（数组列表）和 LinkedList（链表列表）

ArrayList（数组列表）底层是动态数组，LinkedList（链表列表）底层是双向链表。面试官常问“插入删除是不是 LinkedList（链表列表）一定快”，答案不是绝对的。

维度	ArrayList（数组列表）	LinkedList（链表列表）
底层结构	连续数组	双向链表
随机访问	快，按下标 O(1)（常数复杂度）	慢，需要遍历 O(n)（线性复杂度）
尾部追加	通常快，扩容时有成本	快
中间插入	找位置快，移动元素有成本	找位置慢，改指针快
内存占用	相对低	每个节点有前后指针，额外成本高
实际项目常用度	高	较低

ArrayList（数组列表）扩容过程：

新增元素时发现数组容量不足。
创建更大的新数组。
把旧数组元素复制到新数组。
新元素放入新数组。
原数组等待 GC（垃圾回收）。

4.2 HashMap（哈希映射）底层结构

HashMap（哈希映射）是面试最高频集合。它的核心结构是“数组 + 链表 + 红黑树”。数组负责快速定位 bucket（桶），链表或红黑树负责处理 hash collision（哈希冲突）。

flowchart LR
    K["key（键）"] --> H["hashCode（哈希码方法）"]
    H --> S["扰动函数"]
    S --> I["定位 bucket（桶）"]
    I --> B0["数组槽位"]
    B0 --> N1["Node（节点）"]
    N1 --> N2["链表节点"]
    N2 --> T["冲突过多时树化为红黑树"]

HashMap（哈希映射）put（写入）流程：

对 key（键）调用 hashCode（哈希码方法）。
通过扰动函数让高位参与运算，降低冲突概率。
用数组长度减一后按位与，定位 bucket（桶）。
bucket（桶）为空时直接放入。
bucket（桶）不为空时，先比较 hash（哈希）值，再用 equals（相等判断方法）判断是否同一个 key（键）。
key（键）已存在则覆盖 value（值），不存在则追加到链表或红黑树。
元素数量超过 threshold（扩容阈值）时触发 resize（扩容）。

HashMap（哈希映射）线程不安全的原因：

并发 put（写入）可能导致数据覆盖。
resize（扩容）期间多个线程同时迁移节点可能造成结构异常。
一个线程修改结构，另一个线程遍历，可能触发 ConcurrentModificationException（并发修改异常）。

4.3 LinkedHashMap（链式哈希映射）、TreeMap（树映射）和 HashSet（哈希集合）

LinkedHashMap（链式哈希映射）在 HashMap（哈希映射）基础上维护双向链表，所以可以保留插入顺序或访问顺序。TreeMap（树映射）基于红黑树，支持 key（键）有序。HashSet（哈希集合）底层通常借助 HashMap（哈希映射）实现，只关心 key（键）是否存在。

集合	底层重点	适用场景
LinkedHashMap（链式哈希映射）	HashMap（哈希映射）+ 双向链表	保序、LRU（最近最少使用）缓存
TreeMap（树映射）	红黑树	范围查询、按 key（键）排序
HashSet（哈希集合）	HashMap（哈希映射）的 key（键）集合	去重、存在性判断

4.4 ConcurrentHashMap（并发哈希映射）

ConcurrentHashMap（并发哈希映射）用于并发场景，目标是在保证线程安全的同时降低锁竞争。和 Hashtable（哈希表）整表加锁不同，ConcurrentHashMap（并发哈希映射）会把锁粒度控制得更细。

版本	核心实现	特点
JDK（Java 开发工具包）7	Segment（分段）锁	多个 Segment（分段）降低整表锁竞争
JDK（Java 开发工具包）8	CAS（比较并交换）+ synchronized（同步锁）+ Node（节点）	首节点加锁，结构更紧凑

JDK（Java 开发工具包）8 ConcurrentHashMap（并发哈希映射）写入主线：

bucket（桶）为空时，用 CAS（比较并交换）尝试放入节点。
bucket（桶）不为空时，对首节点使用 synchronized（同步锁）。
链表或红黑树内查找 key（键），存在则更新，不存在则新增。
扩容时多个线程可协助迁移，降低单线程扩容压力。

5. 架构图与流程图

5.1 集合选型流程

flowchart TD
    A["需要存多个元素"] --> B{"是否需要 key（键）到 value（值）映射"}
    B -->|是| C{"是否需要排序"}
    C -->|是| D["TreeMap（树映射）"]
    C -->|否| E{"是否需要保留顺序"}
    E -->|是| F["LinkedHashMap（链式哈希映射）"]
    E -->|否| G{"是否多线程共享写"}
    G -->|是| H["ConcurrentHashMap（并发哈希映射）"]
    G -->|否| I["HashMap（哈希映射）"]
    B -->|否| J{"是否需要去重"}
    J -->|是| K["HashSet（哈希集合）"]
    J -->|否| L{"是否频繁随机访问"}
    L -->|是| M["ArrayList（数组列表）"]
    L -->|否| N["按场景评估 LinkedList（链表列表）或 Queue（队列接口）"]

5.2 HashMap（哈希映射）扩容数据流

sequenceDiagram
    participant App as 应用线程
    participant Map as HashMap（哈希映射）
    participant Old as 旧数组
    participant New as 新数组
    App->>Map: put（写入）新元素
    Map->>Map: 判断 size（大小）是否超过 threshold（扩容阈值）
    Map->>New: 创建更大数组
    loop 迁移每个 bucket（桶）
        Map->>Old: 读取旧节点
        Map->>New: 重新分布节点
    end
    Map->>New: 写入新元素
    Map-->>App: 返回写入结果

6. 表格对比

场景	推荐结构	不推荐原因
批量订单顺序处理	ArrayList（数组列表）	LinkedList（链表列表）随机访问慢、内存成本高
SKU（库存单位）数量聚合	HashMap（哈希映射）	TreeMap（树映射）排序成本不必要
支付流水去重	HashSet（哈希集合）或数据库唯一索引	单靠 List（列表接口）遍历性能差
最近访问缓存	LinkedHashMap（链式哈希映射）	HashMap（哈希映射）不维护访问顺序
排名或范围查询	TreeMap（树映射）	HashMap（哈希映射）无序
多线程任务状态	ConcurrentHashMap（并发哈希映射）	HashMap（哈希映射）线程不安全

7. 数据演绎

7.1 HashMap（哈希映射）扩容演绎

假设一个 HashMap（哈希映射）当前数组长度为 16，load factor（负载因子）为 0.75，那么 threshold（扩容阈值）是 12。

初始容量：16
扩容阈值：16 * 0.75 = 12
当前元素数：12
第 13 个元素写入 -> 触发 resize（扩容）
新容量：32
新阈值：32 * 0.75 = 24

面试表达重点：

扩容不是只改一个数字，而是分配新数组并迁移节点。
如果批量导入 10 万条数据，不设置初始容量会多次扩容，带来数组复制和 GC（垃圾回收）压力。
项目里做库存聚合、订单分组、支付流水映射时，如果能预估数据量，应提前设置容量。

7.2 可变 key（键）导致查找失败

1. 创建 OrderKey（订单键）：orderNo = A100, warehouseId = 8
2. 放入 HashMap（哈希映射），hashCode（哈希码方法）按 orderNo 和 warehouseId 计算
3. 业务代码把 warehouseId 改成 9
4. 再用同一个对象查询
5. 新 hashCode（哈希码方法）定位到另一个 bucket（桶）
6. 原来的 value（值）可能查不到

项目风险：

支付幂等 key（键）可变，会导致重复回调被当成新请求。
库存聚合 key（键）可变，会导致同一个 SKU（库存单位）被拆成多个分组。
报警去重 key（键）可变，会导致重复报警无法合并。

8. 线上排查与实战经验

8.1 集合相关线上问题 SOP（标准操作流程）

现象	可能原因	排查动作
CPU（中央处理器）飙高	HashMap（哈希映射）冲突严重或循环处理大集合	看火焰图、jstack（线程栈工具）、热点方法
OOM（内存溢出）	List（列表接口）无限增长、大对象缓存未释放	jmap（内存映射工具）导出 HeapDump（堆转储），看集合持有链
去重失效	equals（相等判断方法）/hashCode（哈希码方法）错误	构造相同业务对象做单元验证，检查 key（键）字段是否可变
并发异常	多线程修改普通集合	搜索共享 HashMap（哈希映射）/ArrayList（数组列表），替换为线程安全方案或分片合并
缓存命中异常	key（键）拼接规则不一致	统一 key（键）生成器，日志打印关键字段

排查口诀：

先看集合是否无限增长。
再看 key（键）是否稳定。
再看是否多线程共享修改。
最后看是否需要换数据结构，而不是只加机器。

9. 项目落地话术

9.1 WMS（仓储管理系统）库存聚合

可以这样回答：

在 WMS（仓储管理系统）里，库存聚合经常要按 SKU（库存单位）和仓库维度做分组。我一般不会直接用可变对象当 HashMap（哈希映射） key（键），而是抽取稳定的 skuId + warehouseId 作为业务 key（键）。如果是单线程批处理，用 HashMap（哈希映射）预估容量减少 resize（扩容）；如果是多线程分片处理，我会让每个线程维护本地 HashMap（哈希映射），最后归并，或者用 ConcurrentHashMap（并发哈希映射）但注意热点 key（键）竞争。

9.2 支付回调幂等

可以这样回答：

支付回调里我不会依赖整个请求对象做去重，因为对象字段可能变化。幂等核心是稳定业务唯一键，比如支付通道事件 ID（标识）或支付流水号。内存里的 HashSet（哈希集合）只能做短时间保护，真正兜底要靠数据库唯一索引或 Redis（远程字典服务）原子写入，并且把重复请求、状态冲突、验签失败分别记录。

9.3 IoT（物联网）报警风暴治理

可以这样回答：

报警风暴治理里，集合的价值主要是窗口去重和聚合。我会按 deviceId（设备标识） + alarmCode（报警编码） 做 key（键），在时间窗口内用 HashSet（哈希集合）去重；如果要控制内存上限，可以用 LinkedHashMap（链式哈希映射）按访问顺序淘汰最老报警。这个方案还要配合 Redis（远程字典服务）或消息队列做跨实例一致性，否则本地集合只能保证单实例内有效。

10. 高频面试题与追问

为什么 equals（相等判断方法）和 hashCode（哈希码方法）要一起重写？
- 回答思路：先讲相等契约，再讲哈希容器的两阶段查找，最后用可变键说明项目风险。
- 详细答案：HashMap（哈希映射）先通过 hashCode（哈希码方法）缩小到一个 bucket（桶），只在该 bucket（桶）内使用 equals（相等判断方法）判断业务相等。若两个 equals（相等判断方法）相等的对象哈希不同，它们会进入不同 bucket（桶），导致查找、删除和去重失效。反过来哈希相同不要求对象相等，因为 equals（相等判断方法）会继续解决冲突。
- 进阶追问：哪些字段适合参与这两个方法？
- 进阶回答：选择稳定、能够定义业务身份的字段，例如不可变订单号；不要使用状态、更新时间或可变集合。对象作为键后修改参与字段，会使节点留在旧 bucket（桶）而查询去新 bucket（桶）。
HashMap（哈希映射）的 put（写入）流程是什么？
- 回答思路：按哈希、定位、比较、插入或覆盖、树化、扩容六步回答。
- 详细答案：先取得键的 hashCode（哈希码方法）并扰动，让高位也参与下标计算；以容量减一和哈希值按位与得到 bucket（桶）。空桶直接写入，非空桶先比较哈希再比较 equals（相等判断方法），命中则覆盖值，否则追加链表或红黑树；链表过长且容量达到条件时树化，元素数超过阈值时扩容迁移。
- 进阶追问：为什么容量通常设计为二的幂？
- 进阶回答：这样下标可用 (n - 1) & hash（哈希值） 高效计算，扩容翻倍后节点只需根据新增高位判断留在原位置还是移动固定偏移，不必重新做通用取模。
HashMap（哈希映射）为什么线程不安全？
- 回答思路：分别说明普通写、复合操作和结构变更没有同步保护。
- 详细答案：两个线程可能同时判断 bucket（桶）为空并相互覆盖，也可能在更新链表、树化和 resize（扩容）时读取到中间状态。即使单个 get（读取）暂时看似可用，“先检查再写入”也不是原子操作。遍历期间结构变化还可能抛 ConcurrentModificationException（并发修改异常）。
- 进阶追问：给 HashMap（哈希映射）外面加 synchronized（同步锁）可以吗？
- 进阶回答：能保证正确性，但所有操作争用同一锁，组合操作还必须始终遵守同一锁约定。一般优先使用 ConcurrentHashMap（并发哈希映射）及其原子方法，或让每个线程私有聚合后合并。
ConcurrentHashMap（并发哈希映射）为什么并发性能更好？
- 回答思路：对比整表锁，说明读取、空桶写、冲突桶写和扩容分别如何协调。
- 详细答案：JDK（Java 开发工具包）8 中读取通常不加互斥锁，空桶通过 CAS（比较并交换）插入，冲突桶只锁当前首节点，竞争限制在少数 bucket（桶）。扩容时线程还可以协助迁移，避免一个线程独占全部工作。它仍有同步成本，只是把粒度和热点缩小。
- 进阶追问：computeIfAbsent（不存在则计算）里的函数可以做远程调用吗？
- 进阶回答：不推荐。计算函数可能在桶级协调期间执行，长时间远程调用会扩大锁持有和竞争，还要面对重复计算或异常。应把远程加载、超时和缓存写入设计为明确流程。
ArrayList（数组列表）扩容有什么成本？
- 回答思路：说明新数组分配、引用复制、新旧共存和 GC（垃圾回收）四项成本。
- 详细答案：容量不足时要申请更大连续数组并复制已有引用，扩容瞬间新旧数组同时占内存，复制占用 CPU（中央处理器）和内存带宽，旧数组随后等待 GC（垃圾回收）。因此追加的均摊成本虽低，单次扩容仍可能形成延迟尖峰。
- 进阶追问：初始容量是不是越大越好？
- 进阶回答：不是。过大容量会浪费堆并加重并发任务内存峰值。应根据单批上限合理估算，并用分页或流式处理限制总量。
LinkedList（链表列表）插入删除一定比 ArrayList（数组列表）快吗？
- 回答思路：区分“已经持有节点”和“只有下标”两种前提。
- 详细答案：已经拿到目标节点时，LinkedList（链表列表）修改前后指针是常数成本；但按下标插入前必须遍历定位，完整成本仍是 O(n)（线性复杂度）。ArrayList（数组列表）需要移动元素，但连续内存批量复制和缓存局部性通常很好，实际业务里往往更快且更省内存。
- 进阶追问：频繁从队头进出应该用什么？
- 进阶回答：使用 ArrayDeque（数组双端队列）通常比 LinkedList（链表列表）更紧凑、更快；并发生产消费则根据阻塞和容量需求选择 BlockingQueue（阻塞队列）。
String（字符串）为什么能作为 HashMap（哈希映射）常用 key（键）？
- 回答思路：从不可变、哈希稳定、相等语义和跨系统表达回答。
- 详细答案：String（字符串）创建后内容不变，因此 hashCode（哈希码方法）可缓存且不会因字段修改导致键失联；equals（相等判断方法）按字符内容比较，语义清晰。它也便于序列化、配置和日志检索，适合订单号和组合业务键。前提是键格式统一且长度受控。
- 进阶追问：超长 String（字符串）键有什么问题？
- 进阶回答：会增加内存、哈希和比较成本，进入 Redis（远程字典服务）后还增加网络与存储开销。可用稳定摘要缩短，但要保留原始业务号映射并评估碰撞风险。
StringBuilder（可变字符串构建器）和 StringBuffer（线程安全字符串构建器）怎么选？
- 回答思路：先看是否共享，再看数据规模和输出方式。
- 详细答案：StringBuilder（可变字符串构建器）没有同步开销，适合方法内部单线程拼接；StringBuffer（线程安全字符串构建器）在方法上同步，只有多个线程必须操作同一缓冲区时才有意义。更常见的设计是每个线程独立构建后合并，避免共享可变对象。
- 进阶追问：超大文件导出用 StringBuilder（可变字符串构建器）就足够吗？
- 进阶回答：不够。超大构建器仍会把全部内容留在堆里，应分页读取并通过 BufferedWriter（缓冲字符输出流）流式写出，仅让一个批次驻留内存。
final（最终关键字）能保证对象不可变吗？
- 回答思路：区分变量不可重新赋值和对象状态不可改变。
- 详细答案：final（最终关键字）基本类型值不能重赋，引用不能改指向，但引用对象仍可能改变。不可变类还要封闭继承、私有字段、构造期赋值、无修改方法，并对数组和集合做深层防御性处理。
- 进阶追问：返回 Collections.unmodifiableList（不可修改列表包装方法）就完全不可变了吗？
- 进阶回答：它通常只是禁止通过该视图增删，底层原列表若被其他引用修改，视图仍会变化；列表元素本身也可能可变。真正快照需要复制容器并保证元素不可变或深复制。
static（静态关键字）字段有什么风险？
- 回答思路：从共享、生命周期、并发和多实例不一致四方面回答。
- 详细答案：静态可变字段被进程内所有线程共享，易出现竞态、可见性和请求数据串扰；它通常与 ClassLoader（类加载器）同生命周期，错误引用还会阻止对象回收。分布式部署时每个实例又各有一份，不能代表全局状态。
- 进阶追问：哪些 static（静态关键字）用法相对安全？
- 进阶回答：真正不可变常量、无状态纯函数和经过严格并发设计的共享基础设施较安全。任何按请求变化的用户、订单和临时结果都不应放静态字段。
泛型的 type erasure（类型擦除）是什么？
- 回答思路：说明编译期检查、运行期替换和由此产生的限制。
- 详细答案：编译器检查类型参数后，把它们替换为上界或 Object（对象基类），并在读取位置插入类型转换，以兼容早期字节码。由此不能直接 new T()、不能创建普通泛型数组，也不能只按参数类型重载方法。声明签名中的部分泛型元数据仍可供反射读取。
- 进阶追问：什么是 heap pollution（堆污染）？
- 进阶回答：当参数化类型变量实际引用了不符合其声明类型的对象时就发生堆污染，常见来源是原始类型、未经检查转换和可变参数泛型数组，最终可能在远处读取时抛 ClassCastException（类型转换异常）。
反射为什么慢？
- 回答思路：从元数据查找、访问检查、参数包装和优化难度回答，同时避免夸大。
- 详细答案：反射调用比静态调用多了成员查找、访问控制、参数数组和类型转换等路径，JIT（即时编译）也更难像固定调用点那样内联优化。现代运行时会做一定优化，所以低频配置和启动扫描通常不是问题；高频序列化或映射应缓存 Field（字段元信息）、Method（方法元信息）和转换器，必要时使用代码生成。
- 进阶追问：优化前应该先做什么？
- 进阶回答：用启动分析或性能剖析确认反射确实占主要耗时，再优化扫描范围和缓存。数据库、网络或错误批次设计往往才是更大瓶颈。
注解本身会执行逻辑吗？
- 回答思路：说明声明与执行分离，并举事务注解为例。
- 详细答案：注解只把结构化元数据放在类、方法、字段或参数上；运行时框架必须扫描并解释它，编译期注解处理器也可以生成代码。Transactional（事务注解）之所以生效，是容器创建代理并由事务拦截器读取规则，不是注解自己开启事务。
- 进阶追问：为什么自己 new（创建）的对象上事务注解常不生效？
- 进阶回答：对象没有经过 Spring（Java 应用框架）容器和后置处理器，不会被包装为事务代理，外部调用自然没有拦截器。
checked exception（受检异常）和 unchecked exception（非受检异常）区别是什么？
- 回答思路：从编译器约束、调用方恢复能力和接口污染讨论。
- 详细答案：受检异常要求调用方 catch（捕获）或 throws（抛出声明），适合调用方确实能采取恢复策略的情况；非受检异常不强制声明，常表达编程错误、参数错误和统一处理的业务异常。选择不应只为少写代码，而要看调用方是否能够有意义地恢复。
- 进阶追问：第三方受检异常要原样向上抛吗？
- 进阶回答：通常在基础设施边界转换为领域可理解异常，并保留原异常作为 cause（原因），附上渠道、操作和错误码，避免业务层耦合具体客户端类型。
为什么业务异常常继承 RuntimeException（运行时异常）？
- 回答思路：说明统一异常边界、事务默认规则和不能滥用的边界。
- 详细答案：业务规则失败通常由统一异常处理器映射为错误码，调用链各层并不都能恢复，使用 RuntimeException（运行时异常）可减少机械声明，也默认触发常见 Spring（Java 应用框架）事务回滚。异常仍需有明确类型、稳定错误码和安全信息，不能所有情况都抛一个模糊异常。
- 进阶追问：业务校验失败一定要回滚吗？
- 进阶回答：如果校验发生在任何写入之前，可以直接失败；若事务内已修改数据，通常应回滚。审计失败记录若必须保留，可通过独立事务或可靠事件记录，但要防止连接池和一致性问题。
HashSet（哈希集合）底层是什么？
- 回答思路：解释元素作为键、占位值和去重契约。
- 详细答案：HashSet（哈希集合）内部通常维护 HashMap（哈希映射），add（添加）相当于把元素写成 key（键），value（值）使用共享占位对象。是否已存在由 hashCode（哈希码方法）和 equals（相等判断方法）共同决定，因此元素相等契约错误会直接导致去重失败。
- 进阶追问：HashSet（哈希集合）能保证遍历顺序吗？
- 进阶回答：普通 HashSet（哈希集合）不保证稳定顺序；需要插入顺序使用 LinkedHashSet（链式哈希集合），需要排序使用 TreeSet（树集合），并明确比较器与 equals（相等判断方法）的一致性。
TreeMap（树映射）适合什么场景？
- 回答思路：从有序能力和 O(log n)（对数复杂度）成本回答。
- 详细答案：TreeMap（树映射）基于红黑树，按自然顺序或 Comparator（比较器）维护键，适合范围查询、邻近键、最大最小键和持续有序迭代。其查找写入通常为 O(log n)（对数复杂度），若只需要等值查找，HashMap（哈希映射）通常更快。
- 进阶追问：比较器返回零但 equals（相等判断方法）不相等会怎样？
- 进阶回答：TreeMap（树映射）会把比较结果为零的键视为同一个排序位置，后写值可能覆盖前值，导致与其他集合的相等语义不一致。比较器应与业务身份保持一致。
LinkedHashMap（链式哈希映射）为什么能做 LRU（最近最少使用）？
- 回答思路：哈希表负责定位，双向链表负责顺序，访问后移动并淘汰头部。
- 详细答案：启用 accessOrder（访问顺序标志）后，每次命中把节点移到链表尾部，头部始终是最久未访问节点；新增后通过 removeEldestEntry（移除最老条目方法）判断是否淘汰头部。它适合小型单机缓存，但默认不线程安全，也不具备过期、权重和分布式一致性。
- 进阶追问：生产本地缓存还应考虑什么？
- 进阶回答：容量、按大小权重、过期时间、并发、加载穿透、统计和淘汰回调。通常优先采用成熟缓存库，而不是只继承 LinkedHashMap（链式哈希映射）。
为什么不能把所有缓存都放到本地 Map（映射接口）？
- 回答思路：说明内存上限、实例隔离、生命周期和一致性。
- 详细答案：本地 Map（映射接口）占用应用堆，无界增长会与业务对象争夺内存；每个实例各有副本，扩缩容、重启和请求路由都会改变命中；数据更新还要广播失效。它适合小规模、允许短暂不一致的热点数据，不能承担共享锁、全局幂等和最终业务状态。
- 进阶追问：多级缓存如何处理一致性？
- 进阶回答：数据库更新成功后发布版本化失效事件，各实例清理本地缓存，分布式缓存采用旁路更新；事件可能丢失时还需较短本地过期、版本校验和监控兜底。
项目里如何避免集合导致 OOM（内存溢出）？
- 回答思路：控制进入速率、驻留数量、单对象大小和生命周期，并建立监控。
- 详细答案：查询和导出按游标分页，处理后立即释放批次；缓存、去重集、重试队列都设容量和过期；线程池使用有界队列，ThreadLocal（线程本地变量）在 finally（最终清理）中清除；大文件采用流式读写。监控集合条目、任务堆积、堆占用、分配速率和 GC（垃圾回收）回收后基线，避免只等 OOM（内存溢出）告警。
- 进阶追问：已经发生 OOM（内存溢出）如何定位到具体集合？
- 进阶回答：先保留 heap dump（堆转储），用 MAT（内存分析工具）查看支配树和可疑泄漏报告，找到占用最大的集合及其到垃圾回收根的路径，再结合任务、缓存和线程池指标确认谁在持续写入；止血后修容量和生命周期，而不是只增加堆。

11. 本模块复习清单

能讲清 equals（相等判断方法）和 hashCode（哈希码方法）的约束。
能讲清 String（字符串）不可变的原因和项目价值。
能讲清 final（最终关键字）引用不可变和对象不可变的区别。
能讲清泛型、反射、注解分别解决什么问题。
能讲清 Java（编程语言）异常体系和事务回滚关系。
能画出 HashMap（哈希映射）put（写入）和 resize（扩容）流程。
能对比 ArrayList（数组列表）、LinkedList（链表列表）、HashMap（哈希映射）、TreeMap（树映射）、HashSet（哈希集合）。
能说明 ConcurrentHashMap（并发哈希映射）的并发优势和使用边界。
能把集合选择绑定到 WMS（仓储管理系统）、支付幂等、IoT（物联网）报警治理项目。

Java（编程语言）核心基础与集合

正式学习入口

兼容保留的旧版正文

1. 简历关联点

2. 面试主线

3. 基础知识

3.1 Object（对象基类）核心方法

热门面试题

3.2 String（字符串）与不可变对象

热门面试题

3.3 final（最终关键字）、static（静态关键字）和不可变设计

热门面试题

3.4 泛型、反射和注解

热门面试题

3.5 异常体系

热门面试题

4. 底层原理

4.1 ArrayList（数组列表）和 LinkedList（链表列表）

热门面试题

4.2 HashMap（哈希映射）底层结构

热门面试题

4.3 LinkedHashMap（链式哈希映射）、TreeMap（树映射）和 HashSet（哈希集合）

热门面试题

4.4 ConcurrentHashMap（并发哈希映射）

热门面试题

5. 架构图与流程图

5.1 集合选型流程

5.2 HashMap（哈希映射）扩容数据流

6. 表格对比

7. 数据演绎

7.1 HashMap（哈希映射）扩容演绎

7.2 可变 key（键）导致查找失败

8. 线上排查与实战经验

8.1 集合相关线上问题 SOP（标准操作流程）

9. 项目落地话术

9.1 WMS（仓储管理系统）库存聚合

9.2 支付回调幂等

9.3 IoT（物联网）报警风暴治理

10. 高频面试题与追问

11. 本模块复习清单