Java技术栈复习

招聘平台岗位要求提炼的 Java 技术栈全量清单与复习路线

📊 速览

• 口径 A：技术域复习优先级（表 2）——按“面试中被追问的深度”排序，决定先读哪一章。
• 口径 B：面试必备清单（第 10 章 10.1/10.2）——按“资深岗位候选人投递前必须准备”排序，决定哪些必须带案例。

两者不一致是有意设计：MySQL/Redis/MQ 在技术域层面归 P1（意味着不必像 JVM 那样追到 C++ 源码级），但在面试必备清单中归 P0（意味着必须准备真实故障案例与量化数据）。下表“26 项 / 24 项”指表 24/25 的打勾项数量，不含第 10 章核心必备清单中的 MySQL/Redis/MQ。

🧭 阅读导航

📑 目录

摘要

本报告面向 Java 后端工程师及资深技术岗位候选人，目标岗位包括资深 Java 工程师、Staff/Principal Engineer、系统架构师、技术专家、后端负责人及研发负责人。资深岗位不只是要求掌握更多初中级知识点；招聘方通常会进一步验证候选人是否具备复杂系统设计、线上疑难问题闭环、技术决策与权衡、核心模块交付、跨团队推动和团队技术影响力。

公开职位样本反复出现的基础组合是 Java/JVM/并发、Spring Boot/Spring Cloud、MySQL、Redis、MQ、分布式系统、生产排障和架构设计；Docker/Kubernetes、CI/CD、测试与代码质量也经常出现。岗位行业、公司规模和职位级别差异很大，因此下文的 P0/P1/P2 是备考优先级建议，不是对整个招聘市场的统计比例，不能把个别职位样本外推成“所有岗位都要求”或精确占比。

两套分层口径：

对资深岗位候选人，面试准备必须从“会使用技术”升级为“能解释机制、说明边界、给出数据、讲清取舍、证明结果”。建议每个 P0 主题至少准备：原理图、典型追问、生产案例、量化结果、方案替代项及其代价。

招聘信息来源与使用边界

本次检索到的公开职位样本包括智联招聘上的高级 Java／架构类职位，以及猎聘上的 Java 架构师、资深 Java 岗位列表。样本中明确出现 Java 核心与 JVM、Spring Boot/Cloud、MySQL、Redis、MQ、分布式与高并发、SQL 调优、容器化、CI/CD、代码质量、系统架构和团队协作等要求。

0. 资深 Java 岗位定位与能力标准

0.1 资深岗位候选人的面试目标

表 1：五类目标岗位与其考察重点

0.2 技术掌握深度的四级标准

0.3 资深岗位需要额外补齐的“责任型能力”

0.4 面试回答黄金九步法模板（架构/选型/故障通用）

遇到架构设计、技术选型和生产故障类问题时，可按此结构组织回答：

1. 背景（Context）     ：业务目标、规模（QPS/TPS/存储量）、当前架构与核心业务约束。
2. 问题（Problem）     ：系统的主要瓶颈、高可用风险、一致性隐患或突发故障现象。
3. 原因（Root Cause）  ：从系统证据链（日志/Metrics/堆栈/内核）推理出的深层机制，绝不凭空猜测。
4. 方案（Options）     ：列举 2~3 个候选方案，说明最终的技术选型。
5. 取舍（Trade-offs）  ：为什么不选替代方案？说明延迟、一致性、改造成本、复杂度与运维的权衡。
6. 落地（Execution）   ：配置改动、代码重构、数据迁移、发布顺序与灰度步骤。
7. 验证（Verification）：压测对比数据、P99/QPS 改善比例、线上监控看板变化证明方案有效。
8. 兜底（Fallback）    ：降级开关、熔断阈值、数据对账补偿机制与一键回滚方案。
9. 结果（Impact）      ：量化业务收益（如：P99 从 300ms 降至 45ms，服务器成本降低 30%）。

0.5 资深岗位候选人必备 11 个生产实战案例库

复习时必须结合自身经历整理出以下 11 个真实案例，做到“有背景、有证据、有参数、有取舍、有数字”：

1. JVM / 堆外内存泄漏 / 线程池打满故障排查（结合 NMT、pmap、Glibc Arena、jstack、Arthas、MAT）。
2. 生产慢 SQL 深入调优与锁争用解除（结合 optimizer_trace、死锁日志分析、索引优化）。
3. 缓存击穿 / 穿透 / 雪崩 / 大 Key 治理与双写一致性保障。
4. 消息积压、消息重复消费与死信补偿闭环。
5. 分布式事务 / 跨系统资金级业务幂等与对账补偿设计。
6. 线上 P0 故障应急响应、止血策略与全链路事后复盘（RCA）。
7. 遗留单体系统重构或技术债清理（绞杀者模式落地与双写双读切换）。
8. 亿级大表不停机迁移、在线 DDL 或平滑分库分表（结合 CDC 与对账校验）。
9. 一次重大发布故障回滚与新旧版本数据兼容性防护（Expand-Contract 模式）。
10. 软件供应链漏洞修复与系统安全性加固（如 Log4j/SpringShell/SSRF/权限垂直越权治理）。
11. AI 大模型 API 企业级接入工程化或 RAG 系统落地的召回调优与降级兜底。

1. 技术栈总览与优先级分层

表 2：Java 技术栈全景（按优先级分层）

1.1 P0 栈的深度标准

表 3：P0 主题的三层追问落点（自检用）

1.2 P1 栈的组织方式

P1 的目标是“能解释机制、能诊断常见故障、能给出工程取舍”，而不是把每个中间件都追到 C/C++ 源码级。对 MySQL、Redis、消息队列、微服务治理等主题，应能说明关键数据结构或协议路径、配置项语义、常见故障、观测指标、容量边界和替代方案。

• 深度标准：能讲清核心原理与失败模式；能结合执行计划、监控指标、日志或压测数据定位问题。
• 项目证明：至少准备一个真实案例，说明当时规模、症状、证据链、备选方案、上线验证、回滚条件和最终收益。
• 学习边界：以目标岗位 JD、实际使用技术和个人短板决定优先顺序，不以“清单越长”作为学习完成标准。

1.3 P2 栈的取舍规则

P2 用于形成岗位差异化，不要求所有人同时深挖 AI、大数据、金融安全、平台工程和云原生。先选定行业与岗位方向，再选择 1–2 个可形成竞争力的专题，建立“概念与边界—可运行 Demo—生产化风险—项目案例—可量化结果”的证据链。

• AI 企业应用：侧重模型 API 治理、RAG 数据与权限、工具调用安全、评测回归、成本与延迟。
• 平台／SRE／云原生：侧重容量规划、可观测性、自动化发布、故障隔离、恢复演练与成本治理。
• 金融／交易／数据平台：侧重一致性、幂等、审计、数据对账、恢复目标、合规与跨版本迁移。

2. Java 语言核心与 JVM 栈

2.1 JVM 与性能诊断栈

表 4：JVM 栈复习条目

2.1.1 三个收集器的停顿目标与适用边界

🔹 G1

• G1 的 -XX:MaxGCPauseMillis 默认目标值为 200ms（目标而非硬上限）；10–200ms 常用于建立调优直觉，但实际停顿取决于对象存活率、分配速率、堆布局、CPU 配额等。目标值设得过严可能使单次回收工作量下降、回收频率上升或吞吐降低，需用 GC 日志和压测验证，不应断言必然发生“断崖式下跌”。
• -XX:InitiatingHeapOccupancyPercent（IHOP）的初始/静态阈值默认为 45%；默认启用的自适应 IHOP 会根据历史标记周期与分配情况动态调整触发点，不能把 45% 当成运行时永远固定的阈值。
• -XX:ConcGCThreads 默认约为并行 GC 线程数的 1/4。
• 大对象处理：对象大小 \(\ge\) Region/2 进 Humongous Region（逻辑属老年代），不走 PretenureSizeThreshold。

🔹 ZGC

• 停顿时间亚毫秒级且不随堆大小增长；代价是读屏障开销与较多 CPU 核数。
• 染色指针（Colored Pointers）：在 64 位引用的可用虚拟地址位中编码 GC 元数据；经典布局使用 Marked0、Marked1、Remapped、Finalizable 四个颜色位，但它们不应笼统描述为原始指针的“最高 4 位”，具体位布局取决于平台与 JDK 实现。
• 读屏障（Load Barrier）：ZGC 通过读屏障（Load Barrier）在读取引用时检测状态，并在需要时借助转发表自愈指针；但不要把它概括成“所有版本绝无写侧屏障”：分代 ZGC 还需跟踪跨代引用并维护记忆集，会引入相关写侧屏障成本。屏障细节应按目标 JDK 的分代模式与实现版本核对。
• G1 vs ZGC 屏障哲学：G1 用写屏障+SATB 解决并发标记漏标；ZGC 用读屏障+染色指针解决并发转移的指针修正。
• SATB vs 增量更新：SATB（G1）记录删除的引用，保证标记开始时存活的快照；增量更新（CMS）记录新增的引用。

🔹 Shenandoah

• 目标是降低停顿，但实际暂停时间、CPU 开销与吞吐损失取决于堆规模、分配速率、负载与构建版本，不应把“低停顿目标（非 SLA；需实测验证）”当作保证。JDK 25 的 JEP 521 引入分代 Shenandoah；具体发行版是否包含、默认状态与启动参数以供应商构建说明为准。

2.1.2 线上故障的排查证据链与诊断流程

排查 CPU 100%、频繁 Full GC 或线程死锁必须遵循可复现的证据链：

1. 监控确认：确认故障发生时间点，比对请求量、P99 延迟、CPU、内存、GC 与连接池监控。
2. 进程诊断：
   - CPU 100%：top -> top -Hp <pid> -> printf "%x\n" <tid> -> jstack <pid> | grep -A 30 <nid_hex>
   - 区分业务线程与 GC task thread（若 GC 线程打满说明内存告急触发连续回收）。
3. 内存与转储：
   - jstat -gcutil <pid> 1000 查看分代使用率与 GC 频率。
   - jcmd <pid> VM.native_memory summary 排查堆外内存（需提前开启 NMT）。
   - 必要时通过 jcmd <pid> GC.heap_dump 生成堆转储，严禁在高峰期对超大堆做 jmap -dump。
4. 应急止血：先通过切流、降级或扩容恢复服务，妥善保留 core dump 与 heap dump 供线下复盘。

2.1.3 对象的一生：从分配到晋升

类加载检查 → 分配内存（指针碰撞 / 空闲列表 + TLAB） → 零值初始化 → 设置对象头 → 执行 <init>

• 分配路径与标量替换：JVM 逃逸分析判断对象是否逃逸出方法。若不逃逸，JIT 会进行标量替换（Scalar Replacement），把聚合对象拆成可单独优化的标量值，由 JIT 放入寄存器或适当的栈槽等位置；这不代表对象一定被分配到 Java 栈，也不保证每次都能消除堆分配。
• 直接进老年代的情况：
  • Serial/ParNew：超过 -XX:PretenureSizeThreshold 直接进老年代。
  • G1：对象大小 \(\ge\) Region/2 进 Humongous Region。
  • 达到晋升年龄阈值（受 -XX:MaxTenuringThreshold、收集器实现、Survivor 占用与动态年龄判定影响）；不要把“默认 15”或历史 CMS 的某个默认值视为所有 JDK/收集器的固定行为，应查看目标运行时参数与 GC/年龄分布日志。
  • 动态对象年龄判定：Survivor 空间中相同年龄所有对象大小总和大于 Survivor 空间的一半，大于或等于该年龄的对象直接进老年代。
• 紧凑对象头：JEP 519 在 JDK 25 将该功能从实验性状态转为产品功能；JDK 27 通过 JEP 534 默认启用。官方描述的 64 位 HotSpot 对象头布局从 96 bit 缩减至 64 bit，但应用整体堆占用的改善幅度取决于对象数量与内存布局，不能直接承诺固定比例。

2.1.4 类的一生：加载、使用与卸载

• 类卸载的关键条件与边界：类通常随其定义类加载器一起卸载；需要类加载器在 GC 根可达性分析中变为不可达，并且没有其他强引用链继续保活该加载器/其类元数据。单纯“某个类的实例都已回收”并不足以保证卸载；同一加载器定义的类通常以加载器为生命周期边界一起处理。卸载时机还受收集器与运行时策略影响，不承诺在某次 GC 立即发生。
• Metaspace OOM 典型场景：CGLIB/Javassist/Groovy 动态生成大量类且不断创建新 ClassLoader；Tomcat 热部署后旧 WebappClassLoader 泄漏（常因 ThreadLocal 未清理或静态字段引用）；排查使用 jstat -gcmetacapacity 与 jmap -clstats。

2.1.5 GC 选型决策表（表 36）

表 36：GC 选型决策表

2.1.6 JIT 编译器深入：C1/C2/分层编译/方法内联/去优化

• 分层编译：Level 0 解释执行 \(\to\) Level 1~3 C1 编译（带 profiling） \(\to\) Level 4 C2 激进优化。
• 方法内联（Inline）：消除调用压栈弹栈开销，铺平逃逸分析与死代码消除。内联失败的常见原因包括字节码体积超过当前内联阈值、调用点类型信息不足导致动态分派难以去虚拟化，以及递归/编译预算等限制。不要把 325 字节当作统一的固定上限；需区分 MaxInlineSize、FreqInlineSize 等参数，并结合目标 JDK、方法热度、调用点类型信息和编译日志判断。
• 去优化（Deoptimization）：基于推测优化的机器码在假设破灭（如类加载出现新子类）时，必须通过 Safepoint 撤销优化回退到解释器，频繁去优化会导致 P99 毛刺与 CPU 瞬时飙高。

2.1.7 JVM 类加载器体系详解

• 层级架构：Bootstrap ClassLoader（HotSpot 传统实现中由 VM 负责） \(\to\) JDK 8 及以前的 Extension ClassLoader／JDK 9+ 的 Platform ClassLoader \(\to\) Application ClassLoader \(\to\) 自定义 ClassLoader。
• 打破双亲委派三大经典：
  1. SPI：利用线程上下文类加载器（Thread.currentThread().getContextClassLoader()）实现父加载器委派子加载器加载实现类。
  2. Tomcat WebappClassLoader：打破常规顺序，优先加载 /WEB-INF/classes 和 /WEB-INF/lib，实现各应用依赖隔离。
  3. OSGi / 热部署：网状类加载器拓扑，根据模块 bundle 动态加载并随时销毁 ClassLoader 实现热替换。

2.1.8 JVM 隐藏长停顿：TTSP 与 Counted Loop 安全点陷阱

生产上常出现“GC 日志记录单次 GC 仅停顿 15ms，但 APM 监控显示该请求 STW 停顿了超过 2000ms”的怪异现象。根因往往不在 GC 本身，而在 TTSP（Time-To-Safepoint，到达安全点等待时间）。

2.1.9 操作系统内存分配黑洞：Glibc ptmalloc Arena 膨胀与 jemalloc 治理

容器化生产中经常出现经典故障：“JVM 堆监控完全正常，NMT 统计的堆外内存（DirectMemory、Metaspace、线程栈）加起来也就 2GB，但容器的物理内存 RSS 已经飙到了 6GB，最终触发 Linux 内核 cgroup OOMKilled”。Glibc 内存分配器的碎片与 Arena 行为是候选原因之一，但 RSS 与 NMT 不是一一对应关系。还应排查 JNI/本地库分配、直接映射、线程栈、代码缓存、共享映射以及 NMT 未覆盖或未开启的内存；结合 /proc/<pid>/smaps、pmap、NMT 和原生分配剖析交叉验证。

表 62：内存分配器 ptmalloc vs jemalloc 对比

生产落地动作：

1. 临时应急规避：在容器启动脚本中设置环境变量 export MALLOC_ARENA_MAX=2 或 4，将 Arena 数量强行压制，减少虚高内存池。
2. 候选治理方案（需验证）：在镜像中安装与发行版、架构匹配的 jemalloc，并在受控环境评估通过 LD_PRELOAD 预加载的可行性。它可能改善部分 glibc 分配器碎片问题，但无法保证消除所有 RSS 虚高或 OOM；需验证 JNI/本地依赖兼容性、崩溃风险、RSS、吞吐与尾延迟，再分阶段发布并准备回滚。

2.1.10 全量十款垃圾收集器深度解析与机制对比

HotSpot JVM 经历多年架构演化，针对吞吐量、低延迟及特殊场景构建了全量十款垃圾收集器：

表 63：十大垃圾回收器特性与选型对比总表

选型表中的停顿、堆容量和吞吐损失是帮助形成直觉的经验量级，不是厂商 SLA，也不是跨硬件/工作负载的保证值。JDK 版本、堆布局、分配速率、CPU 配额、容器限制与业务延迟目标都会改变结果；正式选型应在目标版本和同类流量下压测，并同时比较 P95/P99、吞吐、CPU、RSS 与故障恢复表现。

垃圾收集器核心演进机制深度剖析

1. Parallel 吞吐量平衡公式： $\(Throughput = \frac{T_{exec}}{T_{exec} + T_{gc}}\)$ 提供 -XX:MaxGCPauseMillis（期望最大停顿）与 -XX:GCTimeRatio（吞吐量倒数，默认 99，即允许 1% 的 GC 时间），配合 -XX:+UseAdaptiveSizePolicy 动态平衡堆分代。
2. CMS 运行阶段与三大致命缺陷：
   • 四大阶段：初始标记（STW） \(\to\) 并发标记 \(\to\) 重新标记（STW，增量更新） \(\to\) 并发清除。
   • 致命缺陷 ①：内存碎片与 Concurrent Mode Failure：基于标记-清除（Mark-Sweep）不移动对象，大量碎片导致大对象无法分配，被迫退化为单线程 Serial Old 进行全堆 STW 整理，卡顿几十秒。
   • 致命缺陷 ②：浮动垃圾（Floating Garbage）：并发清除阶段产生的垃圾只能留待下一次 GC 清除，必须通过 -XX:CMSInitiatingOccupancyFraction 提前预留空间。
   • 致命缺陷 ③：CPU 敏感：默认开启 (CPU + 3) / 4 个线程，核心数少时严重挤占业务算力。
3. G1 的 RSet、CSet 与 Card Table 架构：
   • 堆划分为约 2048 个独立 Region（1MB~32MB，大小为 2 的幂）。
   • CSet（Collection Set）：依据历史衰减均值预测停顿时间，选出回收价值最高的 Region 集合。
   • RSet（Remembered Set）：记录“谁引用了我”（Points-into 结构），解决跨 Region 引用扫描全堆的开销；结合 Card Table（卡表，每 512B 对应 1B 卡页）分层管理（稀疏、细粒度、粗粒度）。
4. ZGC 染色指针与自愈机制：
   • 经典 ZGC 染色指针布局会利用 64 位引用中的未使用地址位存储元数据，常见四个颜色位为 Marked0、Marked1、Remapped、Finalizable；不要脱离平台和 JDK 实现，把它们简单说成 64 位数值的最高 4 位。
   • 读屏障（Load Barrier）与转发表（Forwarding Table）：应用线程读取指针时若处于未 Remapped 状态，触发读屏障自愈更新指针地址，彻底实现并发对象移动。JDK 21 引入分代 ZGC（JEP 439），通过更高效地处理年轻代对象改善部分分配密集型负载；它并不能消除所有内存耗尽风险，仍需保证堆空间余量、并发回收能力和分配速率相匹配。
5. Epsilon No-Op 收集器（JEP 318）：
   • 应用线程仍可通过 TLAB/分配路径申请对象，收集器本身不执行任何垃圾回收逻辑；堆耗尽时应用会因分配失败而 OOM。专门用于无外部干扰的微基准性能测试（Microbenchmarking）以及秒级执行完毕即销毁的 Serverless 函数。

2.1.11 三色标记与并发屏障机制深度横评

在并发标记阶段，并发垃圾回收器面临三色标记的“对象漏标”风险。发生漏标导致存活对象被误清除必须同时满足两个充要条件：

       [黑色对象] ────────── 新增引用 (条件一) ──────────> [白色对象]
           │                                                   ▲
           │                                                   │
       [灰色对象] ────────── 删除引用 (条件二) ─────────────────┘

1. 充要条件一：黑色对象（已遍历完毕）新增了指向白色对象（未遍历）的直接或间接引用。
2. 充要条件二：灰色对象（正在遍历）删除了指向该白色对象的直接或间接引用。

各大并发回收器采用完全不同的哲学破坏上述充要条件：

2.1.12 JVM 运行时全链路架构：从 class 文件到机器码

理解 JVM 时要把规范定义、HotSpot 的常见实现、操作系统内存管理分开。JVM 规范规定类文件格式、运行时数据区与指令语义；HotSpot 的 TLAB、分代收集器、C1/C2、对象头压缩和具体命令行参数属于实现层能力，不应直接套用于所有 JVM。

源码 (.java)
  └─ javac / 编译器插件
       └─ class 文件：常量池 + 字节码 + 字段/方法元数据 + 属性
            └─ 类加载器：加载
                 └─ 连接：验证 → 准备 → 解析（解析时机允许延迟）
                      └─ 初始化：执行类初始化方法 <clinit>
                           └─ 解释执行 + 运行时画像（profiling）
                                └─ JIT 分层编译：C1 / C2（实现可能不同）
                                     └─ 本地机器码、内联、去优化与 OSR

对象运行链：分配（TLAB / 慢路径）→ 可达性分析 → GC 标记与屏障 → 回收 / 复制 / 整理
运行时保障：Safepoint / Thread Handshake、异常处理、同步、类卸载
诊断观测：jcmd / jstat / jstack / JFR / -Xlog / NMT / OS 指标

JVM 内存指标必须分层看

• Heap used / committed / max：used 是当前使用量，committed 是 JVM 已提交可使用的量，max 是上限；三者含义不同。GC 后 used 下降不意味着 committed 或 RSS 同步下降。
• Metaspace：存放类元数据；其 native 使用会随类加载器、代理类/动态生成类、类卸载情况变化。持续增长要优先检查类加载器引用链和动态类数量。
• Direct/native：直接缓冲区和其他本地分配可能消耗容器内存，但不都由 Java 堆 GC 直接控制。要结合 `BufferPoolMXBean`、NMT、进程 RSS 与容器 cgroup 数据。
• 线程栈：线程数与栈大小一起决定潜在本地内存；大量平台线程、线程池失控或阻塞线程都可能推高 RSS。

2.1.13 JDK 8–27 的 JVM 演进主线：按维度看差异

表 6 按每个主要版本列出语言、标准库与 JVM/GC 变化；下面再按工程决策维度归纳，避免只背版本号。重点记住“何时引入、何时成为默认、何时移除”是不同问题。

分代 Shenandoah、ZGC、Graal JIT、AOT 等功能的可用性和默认值可能因 OpenJDK 发行版、Oracle JDK、平台与构建选项而不同。本文版本矩阵以 Java SE / Oracle JDK 与 OpenJDK 的官方发行说明为主，不能替代目标发行版的实际验证。

2.1.14 JVM 生产诊断工具与命令矩阵

常见生产排障顺序是先采证据、再定位、最后调参。命令参数会随 JDK 版本和权限/容器环境有差异；在生产执行堆转储、长时间记录或高频采样前，应评估磁盘空间、CPU 开销、停顿风险与敏感数据暴露。

JVM 排障证据链模板

1. 先界定现象：响应时间 / 错误率 / QPS / CPU / RSS / GC pause 哪个首先变化，影响范围与起止时间是什么。
2. 获取同一时间窗证据：部署版本与 JVM 参数、GC/安全点日志、JFR、线程快照、容器指标、业务流量与下游延迟。
3. 提出可证伪假设：例如分配率过高、存活集变大、线程池饥饿、锁竞争、native 内存增长或 safepoint 到达延迟。
4. 一次只改一个变量并对照：用相同流量/数据集比较 P50/P95/P99、错误率、CPU、内存与暂停分布，保留回滚方案。

2.1.15 从 JDK 8 升级到最新版本：兼容性核对清单

一次跨越 JDK 8 → 27 的升级不是简单替换运行时。建议用“目标版本选择、构建兼容、依赖与反射、运行参数、性能基线、灰度回滚”分阶段推进；业务系统不一定应直接生产采用非 LTS 的最新 feature release。

• 构建与字节码：确认构建 JDK、编译目标与生产 JRE/JDK；用 `--release N` 锁定语言/API/字节码兼容级别，使用 `javap -verbose` 核对 major version（JDK 8 为 52，JDK 27 为 71）。
• 模块与依赖：扫描 Java EE/CORBA、JAXB/JAX-WS、Nashorn、内部 `sun.*` API、`setAccessible` 深反射、Java Agent、字节码增强框架；先升级依赖到兼容版本，再考虑精确的 `--add-opens` 过渡。
• JVM 启动参数：在目标 JDK 的真实构建上执行 `java -XX:+PrintFlagsFinal -version`（各版本参数支持有差异）并检查启动 warning；移除已经删除/失效的 CMS、旧 GC 日志以及旧参数。
• GC 和对象布局：核对默认 GC 是否改变；JDK 23/24 的分代 ZGC 行为变化、JDK 27 G1 全环境默认与 Compact Object Headers 默认启用均应列入回归测试。
• 虚拟线程与任务上下文：若引入虚拟线程，检查 `ThreadLocal` 大对象驻留、MDC/追踪上下文传播、锁和 pinning、数据库/HTTP 连接池上限，以及取消与超时是否能释放下游资源。
• 本地接口与工具链：验证 JNI、Unsafe/对象偏移假设、探针/Profiler、AOT/CDS 缓存、容器运行镜像；确认供应商构建支持目标 GC 与诊断选项。
• 性能与容量基线：同数据/同流量比较冷启动、预热时间、吞吐、P95/P99、GC CPU、分配率、live set、Metaspace、direct memory、RSS 与容器 OOM 风险。
• 预览 API：JDK 27 的 Primitive Types in Patterns、Lazy Constants、Structured Concurrency 等仍为预览，Vector API 为孵化；除非明确接受版本锁定与变更成本，不作为一般业务的稳定 API 依赖。
• 发布与回滚：在兼容性测试、压测、灰度和生产观测中逐步推进；把类加载失败、反射异常、GC 暂停、native RSS、TLS/字符集与时间区变化列入验收门槛。

专项官方参考： JDK 27 合并发行说明 · JDK 27 版本变化与移除项 · JDK 26 发行说明 · JDK 24 迁移重要变化 · JDK 21 版本变化 · JDK 17 版本变化

2.1.16 JVM 深水区：NUMA、致命崩溃与容器资源感知

本节将 JVM 参数、操作系统硬件拓扑和生产崩溃诊断放在同一个证据链中。NUMA、cgroup 与崩溃行为均有平台、JDK 更新版本和 GC 实现差异，不能把单一机器的压测结论推广为所有生产环境的规则。

NUMA：先识别拓扑，再判断是否需要绑核/绑内存

致命崩溃与 Core Dump：从 hs_err 到 JNI/本地库

1. 保留证据：收集 hs_err_pid<pid>.log、Core 文件、JDK 精确版本/build、完整启动参数、容器限制、最近变更和动态库版本。
2. 识别信号但不武断归因：SIGSEGV 常见于非法地址访问，SIGBUS 可能涉及未对齐访问或映射文件/底层内存异常；信号仅是线索，需结合 fault address、线程栈和 native frame 定位。
3. 解析现场：用匹配的符号文件与调试符号，通过 gdb、coredumpctl、jhsdb（适用时）查看崩溃线程、寄存器、混合栈、堆与线程状态；不要用不同 build 的符号强行解释。
4. 定位 JNI/FFM：核对 native library 的加载路径、ABI、符号、生命周期与缓冲区边界；排除过期指针、重复释放、越界写、错误的 direct buffer 地址和第三方 native 库。
5. 复现与止血：在隔离环境缩小触发条件，必要时暂时关闭相关本地加速路径或回滚依赖；不要把升级 JDK 当作唯一诊断手段。

Core Dump 提前检查：Linux 下需确认进程 core-size 限制、kernel.core_pattern、容器写入权限、磁盘容量和敏感数据保管策略；生产 Core 可能包含凭据、业务数据和密钥，必须控制访问与保留期限。

cgroup v1/v2 与 JVM 容器感知

• 容器 CPU 配额不等于宿主机逻辑核数；若 JVM 误判可用 CPU，GC 线程、ForkJoinPool、应用线程池与框架默认并行度可能被放大，导致调度抖动和 CPU throttling。
• JDK 的容器感知能力随发行商与更新版本演进；早期 JDK 8 更新、厂商回移补丁、cgroup v1/v2 挂载方式可能不同，不能笼统说所有 JDK 8 都不支持 cgroup v2。
• 排查时检查容器的 cpu.max/cpu.cfs_quota_us、cpuset.cpus.effective、memory.max/memory.limit_in_bytes；在支持的 JDK 上用 -Xlog:os+container=trace（旧版本日志参数不同）核验 JVM 的识别结果。
• -XX:ActiveProcessorCount=N 可在支持的 JDK 中限制 JVM 对可用处理器数的认知，但应作为有依据的修正手段；还要同步检查线程池、连接池和 GC 并行度，而非仅修一个参数。

2.1.17 Async-profiler、Safepoint Bias 与 CPU/Wall-clock Profiling

性能剖析首先要分清“线程正在消耗 CPU”与“请求整体耗时很长”。部分依赖安全点协调或安全点抓栈的采样方案可能产生 Safepoint Bias：采样分布偏向容易在安全点停下的代码，从而低估某些长时间运行的紧密循环。Async-profiler 结合 Linux perf_events 与 HotSpot 的 AsyncGetCallTrace 等能力，降低传统安全点偏差，并支持 CPU、wall-clock、分配和锁竞争等剖析模式；它仍是采样工具，不保证捕获每个瞬间，也受操作系统权限、符号解析和平台限制。

实战判断：CPU 使用率持续高而请求延迟升高，先看 CPU profile；CPU 不高但请求仍慢，优先看 wall-clock、线程状态、连接池等待、远程依赖和锁。采样结果要与压测、请求 trace、GC 日志和系统指标交叉验证。采集前确认 perf_event 权限、容器 capability、安全策略及工具版本；生产火焰图可能暴露类名、SQL 或业务调用路径，需要按生产数据治理要求保存。

2.1.18 DirectByteBuffer、PhantomReference 与 Cleaner 堆外回收链

DirectByteBuffer 的 Java 包装对象位于堆中，其数据区通常来自堆外本机内存。包装对象不可达后，引用处理与 Cleaner/清理动作可安排底层内存释放；这条链路不是“堆内存释放即物理内存立即归还”的同步保证。JDK 内部实现（包括 Bits.reserveMemory、显式 GC 的重试策略与 deallocator 路径）会随版本变化，理解其原理后仍应以目标 JDK 的源码和运行指标为准。

Java 9 引入 Cleaner API；finalization 从 JDK 18 起被弃用并标记为待移除，而非所有 JDK 版本都已移除。排查时要区分 Java 堆 OOM、direct buffer 配额耗尽、容器 cgroup OOM 与系统原生内存不足。

2.1.19 JIT 逃逸分析衍生优化：锁消除与锁粗化

HotSpot JIT 可能基于类型信息、调用点与逃逸分析优化同步操作，但这些属于编译器在特定版本、编译层级和运行时剖面下作出的优化决策，不是源码里写了 synchronized 就一定消除锁。解释字节码、JIT 日志与真实竞争指标时，要把“语言语义保证”和“运行时优化可能性”分开。

面试回答建议：先说明 HotSpot “可能”执行的优化，再讲触发条件、失效边界和如何测量，而不是把某一版 JVM 的实现细节说成 Java 语言规范。

2.2 并发编程栈（JUC 源码级与 JMM 深度）

表 5：并发栈复习条目

2.2.1 并发三大特性与 Java 内存模型（JMM）

表 55：并发三大特性与底层解决机制

// volatile 经典状态标记应用（仅保证可见性，业务方法需自行保证线程安全）
private volatile boolean running = true;

public void stop() {
    running = false;
}

public void runLoop() {
    while (running) {
        doWork();
    }
}

2.2.2 三个共享模式组件的源码级区别

表 39：AQS 三组件对比

2.2.3 虚拟线程适用边界与迁移三问

• 适用场景：高并发 I/O 密集型业务（HTTP 调用、数据库查询、RPC）。不适用 CPU 密集型计算。
• Pinning 解决状态：JDK 24 起（JEP 491）已消除 synchronized 块引起的载体线程挂起锁定；调用 JNI/Native 方法阻塞仍可能导致 Pinning。
• 迁移三问：
  1. 虚拟线程要不要池化？不要。 “one virtual thread per task”是设计初衷，池化会破坏 M:N 调度模型。
  2. ThreadLocal 怎么迁移？对不可变、具有明确动态作用域的上下文值，可优先评估 JDK 25 转正的 ScopedValue（JEP 506）；它不是所有 ThreadLocal 用法的直接替代，ThreadLocal 也不会仅因虚拟线程数量多就必然泄漏。
  3. 怎么渐进替换？ 先替换下游纯 RPC/阻塞调用的线程池，配合 JFR 观察调度延迟与 Pinning 监控指标。

2.2.4 结构化并发的版本状态

截至 JDK 27（2026-10），结构化并发仍为预览特性：JDK 25 为第五次预览（JEP 505）、JDK 26 为第六次预览（JEP 525）、JDK 27 为第七次预览（JEP 533）。使用预览 API 需按对应 JDK 的要求在编译与运行阶段启用 --enable-preview；接口仍可能调整，不应把它描述为已正式稳定。

2.2.5 锁升级、CAS 与并发设计五问

• 锁升级：偏向锁（JDK 15 废弃、JDK 21 彻底移除） \(\to\) 轻量级锁（CAS 修改 Mark Word 为栈帧 Lock Record） \(\to\) 重量级锁（膨胀为 ObjectMonitor，线程挂起于 WaitSet/EntryList）。
• CAS 与 ABA 问题：硬件级 cmpxchg 指令保证原子比较交换；ABA 问题通过版本号解决（如 AtomicStampedReference）。
• 并发计数优化：LongAdder 在高并发冲突下优于 AtomicLong，利用分段 Cell[] 数组通过哈希映射分散单点 CAS 竞争，最后聚合汇总。
• 并发设计前必须回答的五问：
  1. 并发操作是否必须原子执行？
  2. 是否允许短暂的最终一致？
  3. 竞争是否集中在少数热点变量上？
  4. 是否存在 ABA 或状态回退风险？
  5. 是否可以通过批处理、分段分区或无状态化从架构上消除竞争？

2.2.6 线程池的运行机制、监控与容量估算

• 任务提交与扩容逻辑：核心线程 \(\to\) 阻塞队列 \(\to\) 最大线程 \(\to\) 拒绝策略。
• 避免无界队列：Executors.newFixedThreadPool 默认采用无界 LinkedBlockingQueue，突发流量下极易导致 OOM。
• 线程池运行监控指标（八大指标）：
  1. 活跃线程数；2. 当前池大小与最大池大小；3. 队列当前长度与剩余容量；4. 任务提交总数；5. 任务完成总数；6. 任务拒绝总数（Reject Count）；7. 任务平均与 P99 执行耗时；8. 任务在队列中的排队等待耗时。
• CompletableFuture 三大陷阱：
  1. supplyAsync 默认使用 ForkJoinPool.commonPool()，慢 I/O 会耗尽公共池并拖死全局 parallelStream，必须显式传递自定义业务线程池。
  2. thenApply 由执行前一阶段的线程执行，非异步；需显式使用 thenApplyAsync(..., executor) 隔离。
  3. orTimeout 仅使 Future 超时完成，不会物理中断正在进行的底层网络连接，超时预算必须下沉到底层 Client。

2.2.7 线程协作式中断、任务取消与超时传播

• 协作式中断机制：Thread.interrupt() 并不强制杀死线程，只是设置中断状态。若线程在 sleep/wait/join 阻塞，会抛出 InterruptedException 并重置标志位。
• 正确处理规范：捕获 InterruptedException 后，若无法在本层处理，必须重新设置中断位（Thread.currentThread().interrupt()）或向上抛出，绝不能吞没中断信号。

try {
    blockingOperation();
} catch (InterruptedException e) {
    // 恢复中断标记，确保上层调度器获知中断请求
    Thread.currentThread().interrupt();
    return;
}

• 超时与取消传播：Future.cancel(true) 会尝试调用执行线程的中断，但若底层网络库或驱动不支持响应中断，连接仍将卡死；分布式场景必须结合超时预算与调用链 Context 主动取消下游。

2.2.8 死锁、活锁与资源依赖排查证据链

• 死锁四个必要条件：互斥、占有且等待、不可抢占、循环等待。打破策略：固定全局锁加锁顺序、引入 tryLock(timeout) 超时退避。
• 活锁与饥饿：活锁即线程都在主动退让重试却都无法推进（引入随机退避 Jitter 解决）；饥饿即低优先级线程长期拿不到 CPU 或锁资源。
• 七步排查顺序：
  1. 发现接口超时、吞吐断崖下跌或监控告警；
  2. jstack -l <pid> 获取线程转储，排查 BLOCKED 与 WAITING 状态线程；
  3. 搜索 Found one Java-level deadlock: 明确相互等待的 monitor 锁持有者；
  4. 检查是否有父子任务共用同一个有界线程池导致的“线程池饥饿间接死锁”；
  5. 对照数据库连接池与外部 RPC 调用栈；
  6. 修复锁顺序或打破循环等待；
  7. 引入并发压测回归验证。

2.2.9 CPU 缓存行伪共享（False Sharing）与 LMAX Disruptor 无锁架构

当多线程高并发系统要求单机承载百万级 QPS 时，性能瓶颈会直接转移到 CPU 硬件级缓存一致性协议（MESI）。伪共享（False Sharing）是这一层级的头号杀手。

2.2.10 并发核心 API 与协作题型对照

PDai 的并发题库强调线程状态、互斥与协作、线程池、ThreadLocal、FutureTask、ScheduledThreadPoolExecutor、Phaser 和 Exchanger；《成神之路》也强调 start/run、sleep/wait、notify/notifyAll 与生产者—消费者。下面整理成便于面试对比的语义表，并与本章线程池、JMM 和中断专题配合复习。

表 81：并发 API 语义与协作机制

2.2.11 VarHandle：Plain、Opaque、Acquire/Release 与 Volatile

VarHandle 是 Java 9 引入的强类型变量访问抽象，可引用实例字段、静态字段、数组元素等，并提供不同内存序的读写与原子更新。它不是简单地“替代所有 Unsafe”，而是把可用访问模式和内存语义显式化。

硬件屏障不是 Java API 承诺的直接一一映射：HotSpot 会基于目标 CPU 架构和 JIT 生成必要指令。面试时应先陈述 Java 内存模型保证，再谈 x86/ARM 上可能的实现差异；未经测量，不应仅为减少屏障而从 volatile 改成较弱模式。

2.2.12 JCTools 无锁队列与虚拟线程的阻塞边界

JCTools：根据生产者/消费者拓扑选队列

• 伪共享：热点游标/计数器被不同核心频繁修改时，缓存行所有权转移会增加成本。部分实现使用 padding/字段布局降低 false sharing，但内存开销、JDK 字段布局和版本实现均需实测。
• 环形序列：生产者发布槽位前必须确保元素可见；消费者读取后应正确回收槽位。容量、游标回绕和发布顺序属于算法正确性的一部分，不应仅根据“无锁”标签推断一定更快。
• 生产使用：优先选择成熟队列实现，不自创无锁算法；验证满队列策略、背压、取消、内存可达性、队列观测成本与压测尾延迟。

虚拟线程与普通文件 I/O：不要把所有阻塞都等同于 Socket 阻塞

虚拟线程对许多 JDK 支持的阻塞操作能在等待时卸载载体线程，但并非任意本地调用/文件系统操作都保证以相同方式卸载。普通文件 I/O 的可等待语义与 Socket/selector 不同，具体行为受 JDK、文件系统、Native 路径和实现影响。对高频文件读写、同步文件系统调用或 native 库调用，必须在目标 JDK 与生产文件系统上验证载体线程占用；需要时用异步 I/O、专用有界执行器、批量化与背压隔离，不能只把平台线程替换成虚拟线程就认为容量问题消失。

2.3 语言版本与新特性栈

2.3.1 JDK 8–27 核心功能演进全景对照

表 6：JDK 8–27 核心功能演进全景（含语言、标准库、JVM 与 GC）

class 文件主版本号从 JDK 8 的 52 起每个主要版本递增 1：major = JDK 主版本 + 44。使用 `javap -verbose SomeClass` 可检查字节码版本；构建兼容性优先使用 `javac --release N`，而不是只设 `-source`/`-target`。

官方版本资料： JDK 27 合并发行说明 · JDK 27 迁移重要变化 · JDK 25 迁移重要变化 · 各 JDK 版本发行说明索引

2.3.2 GraalVM AOT 的收益、限制与选型判断

• 核心收益：启动时间从秒级降至毫秒级，内存显著降低，无 JIT 预热，契合 Serverless/FaaS。
• 核心限制：反射、动态代理、动态类加载、JNI 需要在编译前提供完整的 JSON 元数据配置；构建时间极长；调试困难。
• 替代路线 CRaC：Coordinated Restore at Checkpoint，通过内存快照实现亚秒级极速热启动，无需牺牲 JIT 峰值吞吐。

2.3.2.1 Java 启动加速三条路线：Native Image、CRaC 与 Leyden AOT Cache

不要把三条路线简单排成固定优劣序。它们优化的阶段不同：Native Image 把应用与可达代码提前编译为本机可执行文件；CRaC 恢复检查点前已经运行/预热的 JVM 进程状态；Project Leyden 的 HotSpot AOT Cache 仍运行在常规 JVM 上，逐步缓存类加载/链接、方法画像与对象数据。必须在目标 JDK、依赖和部署环境上实测冷启动、首请求延迟、稳态吞吐、RSS 与运维复杂度。

版本口径：JEP 483 在 JDK 24、JEP 514/515 在 JDK 25、JEP 516 在 JDK 26 引入相应 AOT Cache 能力。它是渐进演进的启动加速方案，不应写成“开放世界下无需校验任何动态行为”或“无需预热即可达到峰值 JIT 性能”。

2.3.3 Java 21/25 新特性深入：模式匹配与有序集合

• Pattern Matching for instanceof & Switch：消除显式强转，支持空值处理与条件守卫（when）。
• Record Patterns：解构对象属性，配合 sealed class 实现模式穷尽性检查。
• Sequenced Collections（JEP 431）：统一了 getFirst()、getLast()、reversed() 访问有序视图的 API 规范。

2.3.4 Project Panama（FFM API）：告别 JNI，安全调用原生代码

表 44：JNI 与 Project Panama (FFM API) 对比

// Panama FFM API 典型用法：分配原生内存并保证安全回收
try (Arena arena = Arena.ofConfined()) {
    MemorySegment segment = arena.allocate(100);
    segment.set(ValueLayout.JAVA_BYTE, 0, (byte) 42);
} // 离开作用域立即自动安全释放堆外物理内存

2.3.5 JDK 26/27 新特性与版本状态（截至 2026 年 10 月）

截至 2026-10-27，Oracle JDK 27.0.1.0.3 于 2026-10-24 正式发布；Oracle 下载页当前将 JDK 27 标为最新功能版本、JDK 25 标为最新 LTS。 这只代表 Oracle 发行线；其他 OpenJDK 发行版的版本、补丁、支持周期与安全基线应以各供应商公告为准。新版本 GA 不代表所有生产系统都应立即升级，需结合依赖兼容、测试基线、支持周期与回滚能力判断。

• LTS 与生产基线：Java 25 是 LTS 并不意味着必须立即迁移；对现有 Java 8/11/17/21 系统，应按依赖、JDK 供应商、安全支持、GC 行为、Agent/native library 兼容性和灰度回滚方案制定升级计划。
• 版本事实边界：JDK 的特性预览次数、默认参数和废弃/移除状态都可能逐版本变化。回答面试题时先说清 JDK 版本，再说明该版本的具体行为；不把某一发行版的实现细节泛化为 Java 语言规范。

官方资料：JDK 27 Release Notes · JDK 27 Changes and Issues · JDK 26 Release Notes · JDK 27 GC Tuning Guide.

2.4 Java 语言机制、集合框架与标准库边界

2.4.1 Java 集合框架源码级深入与全架构剖析

表 49：核心集合组件机制对比与高频追问

2.4.1.1 Map 体系核心实现原理与底层寻址

1. HashMap 散列扰动函数与高低位扩容：

   • 散列扰动函数：

     static final int hash(Object key) {
         int h;
         return (key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16);
     }
     

     通过高 16 位与低 16 位异或，在数组较小（如 16，掩码 15 即低 4 位为 1）时，将高位特征混合至低位，极大降低低位特征相同引发的哈希冲突。

   • 高低位指针扩容（JDK 8+）： 扩容翻倍后，无需重新计算 hash。依据 (e.hash & oldCap) == 0：

     • 若为 0：新位置等于原位置（loHead/loTail 链表）；
     • 若为 1：新位置等于原位置 + oldCap（hiHead/hiTail 链表）。 JDK 8 改用尾插分拆链表，避免了 JDK 7 头插法在特定并发扩容场景中出现链表成环的经典问题；但 HashMap 依然不是线程安全容器，并发写仍需外部同步或改用并发容器。

   • 树化阈值 8 与退化阈值 6 的数学依据： 在理想随机哈希码等假设下，桶节点数可用泊松分布近似描述（参数 \(\lambda \approx 0.5\)），桶中达到 8 个及以上节点的概率约为 \(6 \times 10^{-8}\)（约一亿分之六）。这说明长链桶在理想分布下较少见，但不代表每次都由攻击导致。JDK 8 HashMap 在容量达到 MIN_TREEIFY_CAPACITY = 64 时才优先树化；容量不足时优先扩容。树化/退化阈值是实现策略，不是并发安全保证。

2. LinkedHashMap：双向链表与 LRU 实现机制：
   • 继承 HashMap，其节点 Entry<K,V> 增加 before 和 after 指针构成独立于哈希桶的全局双向链表。
   • accessOrder = true：开启访问顺序。调用 get() 或命中 put() 时，触发 afterNodeAccess 将节点移动至双向链表尾部。
   • 重写 removeEldestEntry(Map.Entry eldest) 方法，在 size() > MAX_ENTRIES 时返回 true，配合 afterNodeInsertion 自动淘汰双链表头部（最久未访问）元素，实现定长 LRU 缓存。
3. TreeMap 与 ConcurrentSkipListMap：有序检索与并发跳表：
   • TreeMap：基于红黑树实现，依靠节点的左旋、右旋与变色维持平衡，操作复杂度严格 \(O(\log N)\)。非线程安全。
   • ConcurrentSkipListMap：并发有序场景下若使用红黑树，旋转再平衡操作需锁定多个祖先和兄弟节点，锁竞争剧烈。因此采用多层跳表（SkipList），利用 CAS 与 Marker Node（辅助标记删除节点）实现无锁并发插入与删除，支持高并发读写且复杂度稳定为 \(O(\log N)\)。
4. WeakHashMap 与 IdentityHashMap：内存语义与引用感知：
   • WeakHashMap：其内部 Entry 继承 WeakReference，将 Key 包装为弱引用并关联 ReferenceQueue。当 Key 无强引用被 GC 回收后，JVM 自动将弱引用压入队列。在后续调用 put()/size() 等方法时触发 expungeStaleEntries 懒清理，将失效节点从桶链表移除。避坑：若 Value 强引用了 Key 会导致引用成环使弱引用失效；禁止使用缓存常驻对象（如 Integer.valueOf(1)）作为 Key。
   • IdentityHashMap：比较 Key 相等性强制采用引用全等（k1 == k2），哈希计算强制采用 System.identityHashCode(k)。放弃拉链法，采用扁平大数组（偶数存 Key，奇数存 Value）结合开放寻址法（线性探测 Linear Probing）解决冲突。广泛用于 Spring 循环依赖解析与 Jackson/Fastjson 对象图防环递归检测。

2.4.1.2 List 体系物理内存布局与访问开销

1. ArrayList：连续内存、扩容边界与视图陷阱：
   • 扩容算法：newCapacity = oldCapacity + (oldCapacity >> 1)（1.5 倍）。
   • 底层由 System.arraycopy 本地方法映射操作系统底层 memmove 汇编指令迁移内存。
   • subList() 强绑定视图陷阱：subList 返回的是内部类，仅保存对原数组的索引偏移量和原数组的 modCount。原 List 发生任何结构性修改（add/remove）都会使原 List modCount 自增，后续访问 subList 立即抛出 ConcurrentModificationException。长期持有一小段 subList 还会导致整个原底层大数组无法被 GC 释放，造成隐蔽的内存泄漏。
2. LinkedList：指针膨胀与 CPU 缓存行击穿：
   • 双向链表实现，node(index) 采用折半二分法减少一半遍历。
   • 性能劣势：每个数据项包装为 Node 对象，64 位开启压缩指针下每个节点占用 24 字节（对象头 12B + 3个引用 12B），内存利用率极低；堆中节点内存离散分布，破坏 CPU 硬件预取（Hardware Prefetching），导致高频 L1/L2 缓存行未命中（Cache Miss），遍历性能远逊于 ArrayList。
3. CopyOnWriteArrayList：写时复制与弱一致性迭代器：
   • 读操作无锁访问 volatile Object[] array；写操作加独占锁 ReentrantLock 复制 len + 1 大小的新数组完成修改并替换 volatile 引用。
   • 迭代器获取创建瞬间的快照数组引用，迭代期间其他线程写入不影响遍历，迭代器弱一致且不支持修改。
   • 严禁用于高频写场景：频繁深拷贝大数组会导致年轻代被瞬间填满，引发连续 GC 与严重内存尖刺。

2.4.1.3 Queue 与 Deque 体系高效实现

1. ArrayDeque：基于位运算的高性能循环数组：
   • 底层为可扩容数组；容量管理与回绕实现属于 JDK 具体版本的实现细节。阅读源码时，应以目标 JDK 的 ArrayDeque 实现为准。
   • 在采用位掩码回绕的实现中，可通过位运算计算循环索引；不要将某一版本的内部实现当作 Java API 的永久契约：
     • head = (head - 1) & (elements.length - 1)
     • tail = (tail + 1) & (elements.length - 1)
   • 数组实现避免了每个元素对应的链表节点对象开销；官方 API 文档指出其作为栈通常比 Stack 快、作为队列通常比 LinkedList 快，但实际表现仍受操作分布、扩容、容量和 JDK 实现影响，关键路径应以目标负载基准测试确认。
2. PriorityQueue：基于完全二叉堆的高效优先级队列：
   • 数组物理存储映射逻辑完全二叉小顶堆（Min-Heap）。
   • 父子节点索引关系：父节点 (i - 1) >>> 1；左子节点 (i << 1) + 1；右子节点 (i << 1) + 2。
   • 核心调整：插入元素执行 siftUp（上浮，与父节点比较交换，时间 \(O(\log N)\)）；弹出堆顶执行 siftDown（下沉，与较小子节点比较交换，时间 \(O(\log N)\)）。

表 64：Java 核心集合容器底层原理与复杂度特性对比表

2.4.2 泛型、类型擦除与桥接方法

• 类型擦除原理：Java 泛型是编译期检查，编译后类型参数被擦除为边界类型（无界则擦除为 Object），并自动插入类型强转指令。因此在运行时无法直接 new T()、new T[] 或使用 instanceof List<String>。
• PECS 原则：Producer Extends, Consumer Super。只读数据源用 ? extends T（协变），只写消费容器用 ? super T（逆变）。
• 桥接方法（Bridge Method）：当子类继承泛型类或重写协变返回类型的方法时，编译器会自动在字节码中生成带有原始签名的合成桥接方法（Synthetic Bridge），在其中调用具体重写方法，确保多态分派正确。

// 泛型原始类型破坏类型安全示例：
List<String> names = new ArrayList<>();
List raw = names; // 编译器警告：原始类型赋值
raw.add(123);     // 编译通过！破坏泛型约束
String name = names.get(0); // 运行时抛出 ClassCastException！

2.4.3 equals、hashCode 与对象契约

• 契约准则：两对象 equals() 相等，hashCode() 必须相等；反之不要求。重写 equals() 必须重写 hashCode()。
• 可变 Key 灾难：如果作为 HashMap 的 key 对象，其计算 hashCode 的字段在 put 后被修改，后续 map.get(key) 将因定位到错误的桶而返回 null，引发逻辑数据丢失甚至内存泄漏。
• BigDecimal 比较陷阱：BigDecimal.equals() 同时比对数值与标度（scale），new BigDecimal("1.0").equals(new BigDecimal("1.00")) 返回 false；纯数值大小比较必须使用 compareTo() == 0。

2.4.4 集合迭代器、并发修改与视图陷阱

• fail-fast 机制局限：通过 modCount 检查并发修改，一旦发现多线程或迭代器外部 list.remove() 即抛出 ConcurrentModificationException。它绝不能作为并发安全保证，其检查是尽最大努力的；安全单线程移除必须使用 Iterator.remove()。
• 只读视图 vs 深度不可变：Collections.unmodifiableList() 只是原集合的浅层只读包装，原集合被修改时视图依然同步改变；真正不可变需要防御性拷贝或使用 JDK 9+ List.of()。
• Arrays.asList() 边界：返回的是内部固定长度适配数组，调用 add()/remove() 会抛出 UnsupportedOperationException。

2.4.5 异常设计与资源管理规范

• 受检 vs 非受检：受检异常代表业务可预见且可恢复的场景，非受检异常（RuntimeException）代表编程错误或不可恢复的基础设施故障。现代框架普遍采用非受检异常结合明确错误码。
• 异常链保留：转换异常类型时必须保留原始 cause（new BusinessException("msg", cause)），严禁 catch 后仅记录日志却吞没异常导致调用链上下文断裂。
• try-with-resources 与 Suppressed Exception：自动关闭实现 AutoCloseable 的资源。若 try 块与 close 方法均抛出异常，try 块异常为主异常抛出，close 产生的异常被追加到 e.getSuppressed() 中，彻底消除传统 finally 中异常覆盖的问题。

2.4.6 时间、时区与高精度金额计算

• 时间规范：严禁混用旧版 java.util.Date 与 Calendar。后端存储及接口传输必须统一使用 Instant（标准 UTC 时间戳）或带明确时区偏移的 OffsetDateTime；前端展示再由业务按时区渲染。
• 金额精确计算：严禁直接使用 double/float 运算。金额运算必须使用 BigDecimal 且必须使用字符串构造方法（new BigDecimal("19.99")）。乘除运算必须明确指定小数精度与舍入模式（如 RoundingMode.HALF_UP），舍入规则必须由业务契约清晰定义。

// 金额标准运算：明确指定精度与舍入模式
BigDecimal amount = new BigDecimal("19.90");
BigDecimal taxRate = new BigDecimal("0.13");
BigDecimal tax = amount.multiply(taxRate).setScale(2, RoundingMode.HALF_UP);

2.4.7 序列化与跨系统对象兼容性治理

• Java 原生序列化禁令：Java 原生序列化开销大且存在严重的反序列化 RCE 漏洞风险，跨服务及缓存禁止使用。跨系统交互首选 JSON（Jackson）、Protobuf 或 Avro。
• 兼容性演进原则：字段只增不减；新增字段必须设置默认值；禁止重命名已有字段；生产者与消费者必须配置忽略未知字段（FAIL_ON_UNKNOWN_PROPERTIES=false）。

2.4.8 Java 基础语义、数值、编码与时间陷阱

对照两份知识图谱后，补齐容易在“会用框架”阶段被忽略、但基础面试常追问的语言语义与标准库边界。已有集合、泛型、equals/hashCode、时间与序列化专题仍保留，本节只整理交叉核对后需要集中对比的基础点。

表 80：Java 基础语义与标准库常见陷阱

2.4.9 反射、注解、内部类、对象复制与序列化补充

上传 PDF 的“Java 基础”部分还专门列出反射、注解、内部类、对象复制和 Java 序列化。这些内容在现有语言语义专题中有交集，但值得形成一张独立的面试速查表；以下按现代 JDK 的封装与安全边界重新整理。

表 92：反射、注解、内部类、复制与序列化的核心边界

2.4.10 SPI / ServiceLoader、字符串常量池与类初始化顺序（表 110）

JavaGuide 的基础题目录明确涵盖 SPI、序列化、反射与 String；现有报告已覆盖反射、注解和序列化，但没有把 SPI 与字符串常量池作为独立面试专题。本节补足这几个常见追问，并强调实现细节应结合目标 JDK 验证。

面试回答建议：先讲规范层面的结论，再用一个最小代码片段验证目标 JDK 的结果；若问题问“JVM 一定如何实现”，应区分规范约束和 HotSpot 当前实现。

2.5 字节码增强与 Java Agent 栈

2.6 设计模式速查

表 50：经典设计模式在 Spring/Java 框架中的映射

2.6.1 GoF 设计模式全量速查与 SOLID 原则

《Java 工程师成神之路》对设计原则、创建型/结构型/行为型模式、单例实现与 Spring 中的模式应用有系统分类。本表补齐原速查表未逐组列出的模式目录；复习重点是识别问题与权衡，不要求每个模式都在项目中强行套用。

表 82：GoF 23 种设计模式与 SOLID 原则

3. 框架与中间件栈

3.1 Spring 全家桶栈

阅读顺序：3.1.1–3.1.5 是循环依赖、扩展点、事务失效、异步/定时代理、配置与就绪诊断的专题深挖；3.1.6–3.1.14 是系统化知识地图、生态矩阵与场景自检。两部分有意采用“高频问题深挖 + 全景覆盖”的双层结构；复习时把前者当作机制案例，后者用于查漏，不必重复背诵同一结论。

表 7：Spring 栈复习条目

面试覆盖边界：本节把 Spring Core、Boot、MVC、AOP/事务、安全、数据访问、缓存、任务调度、测试与主流生态项目纳入同一地图；不代表每个岗位都要求全部背到源码级，优先按 P0/P1 和目标 JD 选择深度。

3.1.1 三级缓存：为什么二级不够

三级缓存存的是 ObjectFactory（lambda），只有在“确实发生循环依赖且允许提前引用”时才调用 getObject()，由 getEarlyBeanReference 决定是否在此刻创建 AOP 代理。本质是把代理对象的创建时机推迟到确定真的有人提前引用它的那一刻。如果直接放二级缓存，在有 AOP 的场景下其他 Bean 拿到的会是原始对象而不是代理对象。

3.1.2 BFPP 与 BPP：Spring 真正的扩展点

表 40：BFPP 与 BPP 对比

3.1.3 事务失效根因与长事务治理

• 代理失效五大根因：自调用（绕过代理对象）、非 public 方法、异常被内部 catch 吞掉、受检异常未指定 rollbackFor=Exception.class、多线程环境下分属于不同 Connection 连接。
• 长事务危害与治理：长事务会持续占用数据库连接；事务已获取的行锁等资源可能一直持有到提交/回滚，从而耗尽 HikariCP 连接池并放大锁等待。通常应避免在持有数据库事务的同时调用慢 RPC/HTTP 或执行耗时计算；可先完成外部校验，再开短事务完成 DB 更新。若业务要求跨系统协作，评估 Outbox、Saga、状态机和补偿机制，而不是简单地把事务边界机械收缩到单条 SQL。

3.1.4 @Async 与 @Scheduled 的代理陷阱

3.1.5 配置治理与应用启动就绪诊断

• 配置覆盖优先级：命令行参数 > Java 系统属性（-D） > 环境变量 > application-{profile}.yml > 内部 application.yml。生产凭据禁止明文硬编码于 Git 仓库，必须通过 Vault/K8s Secret 或配置中心动态下发。
• 启动诊断与探针分离：
  • Liveness Probe（存活探针）：检测容器死锁或严重崩溃，失败后重启 Pod。
  • Readiness Probe（就绪探针）：检测应用内部连接池、下游依赖是否准备就绪，未就绪时仅摘除流量，绝不随意重启 Pod。
  • Startup Probe（启动探针）：保护慢启动 Java 应用避免在初始化期间被存活探针误杀。

3.1.6 IoC 容器、Bean 生命周期与依赖解析全景

面试不能只背“控制反转、依赖注入”。要能从 BeanDefinition 注册、实例化、依赖填充、Aware 回调、初始化前后处理、初始化方法、代理暴露到销毁阶段，讲清对象由谁创建、何时可被其他 Bean 引用、哪些扩展点能改变定义或包装实例。

表 71：Spring IoC 容器与 Bean 生命周期面试对照

• 面试答题主线：先说容器中元数据何时注册，再说对象何时实例化和注入，最后解释后处理器、代理、生命周期回调及销毁。
• 源码入口：AbstractApplicationContext.refresh()、DefaultListableBeanFactory、AbstractAutowireCapableBeanFactory、DefaultSingletonBeanRegistry；应结合目标 Spring 版本读源码，不要把某个版本的内部调用顺序当成永恒 API 契约。

3.1.7 AOP、代理机制与切面执行链

表 72：Spring AOP 代理机制与切面执行链对照

• 能解释为什么事务、缓存、权限、异步注解经常共享代理失效模式，以及如何通过重构服务边界、独立 Bean 或显式编程式 API 修复。
• 源码阅读建议关注自动代理创建器、Advisor 匹配、代理创建时机和拦截器链；以当前 Spring 官方文档为基准，避免记忆早期版本的实现细节。

3.1.8 Spring 声明式事务：传播、隔离与真实边界

表 73：Spring 事务传播行为与真实边界对照

• 回滚规则：默认情况下，运行时异常和 Error 通常触发回滚；受检异常需结合 rollbackFor 等规则，不应死记为“所有异常都会回滚”。确认当前 Spring 版本的默认回滚规则及项目自定义配置。
• 隔离与传播不是一回事：传播定义如何加入/创建事务，隔离级别定义并发事务的数据可见性；实际效果还取决于数据库、驱动和事务管理器。
• 线程边界：传统 JDBC 事务上下文通常绑定当前线程；切换线程、@Async、虚拟线程任务交接不意味着自动继承同一事务。响应式事务则使用 Reactor Context 等不同机制。
• 长事务：避免持有数据库事务执行慢 RPC、消息等待或大规模计算；跨服务一致性优先评估 Outbox、Saga、幂等与补偿，而不是把本地事务误当全局事务。
• 事务管理器：理解 PlatformTransactionManager、TransactionTemplate、JDBC/JPA/R2DBC 管理器的资源边界；多数据源场景需明确事务管理器绑定，跨库原子提交另做方案设计。

3.1.9 Spring Boot：自动配置、配置绑定与启动过程

• 启动主流程：SpringApplication.run()、环境准备、配置数据加载、ApplicationContext 创建、Bean 定义注册、自动配置条件评估、上下文刷新、Runner 执行和就绪事件。能说清 ApplicationRunner/CommandLineRunner 与应用真正接流量前后的边界。
• 自动配置原理：@SpringBootApplication 的组合含义；自动配置类、条件注解和 META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports（适用于相关现代版本）；@ConditionalOnClass、@ConditionalOnMissingBean、@ConditionalOnProperty、排除项与 Condition Evaluation Report。
• Starter 与依赖治理：starter 负责聚合常用依赖，自动配置负责按条件注册 Bean；理解 BOM/依赖管理、版本对齐、传递依赖冲突、排除规则和 Boot/Framework/Cloud 兼容矩阵。不要无验证地强行覆盖 Spring 管理的底层依赖版本。
• 配置绑定：@ConfigurationProperties 适合类型安全、分组、校验的配置；@Value 适合少量简单注入。掌握 profile、多文档配置、环境变量命名、外部文件覆盖、命令行覆盖、配置刷新机制及其组件边界。
• 生产能力：Actuator health/info/metrics/prometheus、启动与就绪探针、优雅停机、线程池和连接池指标、敏感端点保护、HTTP 暴露范围及自定义健康指标。暴露 Actuator 不等于自动完成安全配置。
• 原生镜像 / AOT：理解 AOT 生成阶段、反射/动态代理/资源提示、可达性元数据与 Native Image 的启动/内存收益及动态特性限制；把它作为选型专题，不要与普通 JVM 启动混为一谈。

3.1.10 Spring MVC 请求链、参数绑定与异常处理

高频请求链可按“Servlet 容器 → Filter → DispatcherServlet → HandlerMapping → HandlerAdapter → 参数解析/数据绑定/校验 → Controller → 返回值处理/HttpMessageConverter → 异常解析器 → 响应”讲述。具体实现以使用的 Spring MVC 版本和配置为准。

表 74：Spring MVC 请求链与参数处理对照

3.1.11 Spring Security：认证、授权与安全过滤器链

• 请求安全链：SecurityFilterChain、安全过滤器顺序、SecurityContext、Authentication、AuthenticationManager/Provider、UserDetailsService、PasswordEncoder，以及认证成功/失败处理。
• 认证与授权的区别：认证回答“你是谁”，授权回答“你能做什么”；掌握请求级授权、方法级安全（例如 @PreAuthorize）、角色/权限表达式、对象级授权与多租户隔离。
• Session / JWT：无状态不等于无需撤销策略；讨论 Token 过期、刷新、密钥轮换、撤销/黑名单、受众与签发方校验、时钟偏差、密钥泄露与日志脱敏。JWT 不是加密的同义词。
• OAuth 2.0 / OpenID Connect：区分授权与身份认证，理解 Authorization Code + PKCE、Resource Server、Client、Issuer、Scope、ID Token 与 Access Token。不要在新系统中照搬已不适合公有客户端的旧流程。
• CSRF / CORS / 安全头：CSRF 主要取决于浏览器是否自动携带凭据；CORS 是浏览器跨域策略，不是后端授权。按 Cookie、Bearer Token、跨域凭据和前后端部署方式分别选型。
• 面试故障：自定义 Filter 顺序错误、SecurityContext 在异步线程丢失、OPTIONS 预检失败、方法权限绕过、JWT 算法/密钥错误、开放重定向与登录回调校验缺失。

3.1.12 数据访问、缓存、事件、任务调度与测试

表 75：Spring 数据访问、缓存与测试边界对照

3.1.13 Spring 生态框架矩阵与版本兼容

“Spring 全家桶”不是单一框架。面试中要能说清核心框架、Boot 装配层、Cloud 分布式组件、数据集成模块和外围项目的职责。以下列的是资深 Java 岗位常见候选，而不是每个岗位都要求全部掌握。

表 76：Spring 生态框架与能力分层矩阵

• 版本策略：以官方兼容矩阵和依赖 BOM 对齐 Spring Boot、Spring Framework、Spring Cloud release train、Spring Kafka/AMQP 等版本；先确认 JDK 基线、Jakarta 命名空间和第三方 starter 的适配范围，再升级。不要把“最新版本”自动等同于现有生产系统的最佳版本。
• 重点迁移项：Spring 5 → 6 / Boot 2 → 3 涉及 Java 基线、javax → jakarta、部分 API 与依赖变化；Spring 6 → 7 / Boot 3 → 4 则需继续检查 JDK 基线、依赖模块拆分、自动配置和第三方集成兼容性。以目标小版本迁移指南为准。

官方版本快照（核验截至 2026-10-27，供复习时识别版本边界，不是升级推荐）：Spring Boot 稳定线包含 4.1.2，要求 Java 17 起并声明兼容到 Java 27；对应 Spring Framework 7.0.10。Spring Cloud 2025.1.x（Oakwood）对应 Boot 4.0.x，且从 2025.1.2 起支持 Boot 4.1.x；Spring for Apache Kafka 4.1.2 与 Boot 4.1.x 对应，Spring AMQP 4.1.2。Boot 系统要求、Spring Cloud 兼容矩阵、Spring Kafka 版本矩阵、Spring AMQP 当前版本。特别提醒：Boot、Framework、Cloud train、各集成项目和第三方 Starter 必须按官方兼容矩阵/BOM 联动，不能只把某个依赖升到最新号。

3.1.14 Spring 高频场景题自检

• 为什么循环依赖有时可解决、有时失败？构造器循环依赖和 AOP 代理提前暴露有何区别？
• 为什么 @Transactional 在自调用、非代理调用、异常被吞、多线程和多数据源情况下会失效或产生不同结果？
• 一个 Bean 为什么没有按预期自动配置？如何用条件评估报告、Bean 列表、依赖树定位？
• Filter、HandlerInterceptor、AOP 的边界与顺序如何影响认证、链路追踪和异常处理？
• JWT 登录后接口仍返回 401/403，如何区分认证失败与授权失败，并沿过滤器链排查？
• Spring Cache 与 MQ 事件如何避免双写不一致？如何定义失败重试和补偿？
• 服务启动慢、Readiness 一直失败、优雅停机丢请求，应从哪些日志、指标和生命周期点定位？
• 如何把一个启动慢、堆内存增长、线程池耗尽的 Spring Boot 服务拆成可复现的证据链，而不是盲目增加机器？

3.1.15 Servlet 容器、Tomcat 线程模型与生命周期

两份资料都将 Servlet 容器、Tomcat/Jetty/WebLogic 等传统 Web 基础纳入 Java 工程师知识图谱。资深岗位不一定要求容器源码级掌握，但应能说明请求如何进入应用、线程与连接如何受限，以及故障如何从容器层定位。

表 83：Servlet 容器与 Web 请求处理边界

3.1.16 动态数据源与声明式事务：连接过早绑定陷阱

使用 AbstractRoutingDataSource 或读写分离路由时，路由键通常在连接获取阶段决定。事务拦截器若已经开始事务并将连接绑定到当前线程，之后再修改 ThreadLocal 路由键通常不会把已绑定连接“切换”为另一个库。

1. 典型错误：外层方法带 @Transactional，进入方法时事务管理器已获取/绑定主库连接；方法内部再设置“读库”标记，后续 JDBC 仍使用当前事务绑定的连接。
2. 排查证据：检查数据源切面与事务切面的执行顺序、实际 Connection 的 JDBC URL、连接获取时的路由 key、事务同步状态及 propagation；仅打印 ThreadLocal 值不足以证明连接已切换。
3. 方案一：在事务开始前由更外层路由切面选择数据源，确保路由逻辑先于事务拦截器获得连接，避免依靠模糊的默认 AOP 顺序。
4. 方案二：把读写动作拆分到独立 Spring Bean/独立服务方法，使用明确事务边界；必要时通过编程式 TransactionTemplate 在正确的数据源/事务管理器下运行。注意 REQUIRES_NEW 会创建新事务，但如果路由切面仍顺序错误或事务管理器绑定错误，依然不能自动修复问题。
5. 方案三：明确读后写一致性、事务内读路由、只读事务标记与复制延迟策略；“readOnly=true”并不等于自动选择从库。

3.1.17 Spring Boot + Kubernetes 优雅停机的完整时序

建议把 spring.lifecycle.timeout-per-shutdown-phase、server.shutdown=graceful（按 Spring Boot 版本核对）和 Kubernetes 宽限期放在同一部署模板里管理。发布演练应验证：摘流后不再接新流量、在途请求成功率、消息消费者停止拉取、连接池清理、超时强杀比例及回滚行为。

3.1.18 Spring Boot 3/4、Framework 6/7：AOT、Runtime Hints 与 Native Image

AOT 会在构建阶段分析 Spring 容器并生成更固定的初始化/调用安排；Native Image 构建还要求显式描述某些反射、资源、序列化与代理的动态使用。不是所有库都要手工注册 Hints，Spring 已能推导一部分元数据；重点是找到运行时动态行为与可达性分析之间的缺口。

final class AppRuntimeHints implements RuntimeHintsRegistrar {
    @Override
    public void registerHints(RuntimeHints hints, ClassLoader classLoader) {
        hints.resources().registerPattern("dicts/*");
        hints.reflection().registerType(
            MyPayload.class,
            MemberCategory.INVOKE_PUBLIC_CONSTRUCTORS,
            MemberCategory.INVOKE_PUBLIC_METHODS);
    }
}

@Configuration
@ImportRuntimeHints(AppRuntimeHints.class)
class NativeImageHintsConfiguration {}

示例展示资源和反射提示的基本形式，需按应用类型选择最小权限的 MemberCategory。Spring Framework AOT 与 Spring Boot Native Image 的具体插件、测试支持及兼容版本请按项目使用的 Framework/Boot 版本查阅对应官方文档。

3.1.19 Spring Cloud Gateway：Netty EventLoop、阻塞调用与 DataBuffer 生命周期

Spring Cloud Gateway 的响应式请求通常运行在 Reactor Netty EventLoop 上。一个 EventLoop 负责多个连接；若在过滤器中直接执行阻塞 JDBC、同步 HTTP、长时间锁等待或大量 CPU 计算，会拖住该 EventLoop 上的其他连接，表现为看似“整个网关随机变慢”。同理，Request/Response Body 的缓冲与转发需要遵守 DataBuffer 的所有权和释放约定。

不要把所有 DataBuffer 都机械地手动 release：先确认缓冲区所有权、是否已被框架消费，以及使用的是哪一版 Spring Framework/Reactor API。泄漏检测应在测试环境打开并覆盖取消、异常和重试路径。

3.2 微服务与分布式框架栈

表 8：Spring Cloud Alibaba 组件栈复习条目

表 9：Dubbo SPI 与 JDK SPI 五维对比

• Sidecar Mesh vs Proxyless Mesh（Sermant）：Sidecar 具有多语言优势但增加一跳网络延迟；Proxyless Mesh 基于 Java Agent 在进程内直连控制面，保持零额外时延。

3.2.1 RPC 契约与跨语言协作

• 协议选择：比较 REST/OpenAPI 与 gRPC/Protobuf 的可调试性、代码生成、跨语言契约、流式调用、网关支持和运维门槛；不要只按吞吐量决定。
• 可靠性边界：为调用设置 deadline 并向下游传播；定义重试条件、幂等要求、最大重试预算、取消语义和背压行为，避免重试叠加放大流量。
• 契约演进：兼容新增字段、未知字段和枚举扩展，明确破坏性变更策略；对跨服务变更使用契约测试、灰度验证和可回滚的发布顺序。
• 可观测与身份：传播 trace context、调用方/服务身份与必要审计字段；在网关、服务和业务对象层分别执行授权，而不是仅凭网络可达判定权限。

3.2.2 微服务治理：发现、配置、流量与韧性

• 服务发现与注册：理解注册、心跳/租约、健康实例、摘除与缓存一致性；区分存活探针、就绪探针和注册中心中的健康状态。Nacos、Consul、Eureka 等的协议、数据模型和一致性语义不同，不能把所有注册中心都理解成同一种强一致 KV。
• 配置中心：配置来源优先级、profile/环境隔离、动态刷新边界、配置变更审计、密钥与普通配置分离；对不可热更新的线程池、数据源或安全参数应采用受控重建/滚动发布，而非假设所有配置都能实时生效。
• 网关与负载均衡：路由、鉴权、限流、灰度标记、超时与请求体限制要有明确职责边界；对象级授权仍需在业务服务执行，不能仅凭请求经过可信网关就跳过资源权限校验。
• 超时、重试与熔断隔离：设置端到端 deadline 并向下游传播；为每层明确连接/读取/总超时、重试条件、幂等前提、指数退避与抖动、重试预算；通过 Circuit Breaker、Bulkhead、限流和负载 shedding 控制级联故障。多层重试相乘可能放大流量。
• 发布与兼容：滚动、蓝绿、金丝雀/灰度发布要与 API/消息 Schema 的向后兼容策略配合；数据库采用 Expand–Migrate–Contract，确保新旧版本并存期间字段和事件契约兼容，并准备暂停、回滚与数据补偿。
• 可观测性：统一 trace context、服务身份、关键业务 ID 和错误分类；从请求延迟分位数、依赖错误率、线程池/连接池饱和度、重试次数和 SLO/error budget 判断是否限流、降级或扩容。

3.2.3 RPC 与客户端框架选型：Dubbo、gRPC、OpenFeign 与 HTTP

• Dubbo：关注服务接口契约、注册/发现、集群容错、负载均衡、过滤器链、SPI 扩展、超时与重试；具体行为依 Dubbo 主版本和协议/注册中心扩展而异。
• gRPC：关注 Protobuf 契约、生成代码、HTTP/2、多路复用、deadline、状态码、取消传播、拦截器和四类 RPC（Unary/Client streaming/Server streaming/Bidirectional streaming）；浏览器、网关和负载均衡环境还需核对代理与协议支持。
• OpenFeign / REST Client / WebClient：理解同步阻塞与异步/响应式调用差异、连接池、DNS、TLS、超时、重试和错误映射；WebClient 本身并不会自动让下游业务链路无阻塞，也不能把阻塞数据库调用放到事件循环线程。
• 跨语言契约：REST 优先看 OpenAPI 与 HTTP 语义；RPC 看 IDL/Protobuf/Avro 等 Schema 兼容、枚举扩展、未知字段、错误码、认证、版本发布顺序和契约测试。避免把 Java 原生序列化对象作为长期跨服务协议。
• 选型结论：按调用模型、跨语言、流式需求、端到端 deadline、调试与治理工具、团队熟悉度和运维成本选择；不以单次吞吐测试决定。服务网格可以承接部分流量治理能力，但不替代业务幂等、领域授权和应用级错误处理。

3.2.4 ZooKeeper：会话、ZNode、Watch 与 ZAB 协调机制

上传 PDF 第 11 章（目录标注页 171–174）整理了 ZooKeeper 角色、ZAB、投票与 ZNode。面试时应把它视为协调服务，而不是泛化的高吞吐数据库；重点理解会话、临时节点和一致性协议如何组合支撑注册发现、配置协调与分布式互斥。

表 93：ZooKeeper 核心结构与常见追问

3.2.5 负载均衡、入口高可用与算法选型

上传 PDF 第 18 章（目录标注页 203–213）覆盖四层/七层负载均衡、算法、LVS、Keepalived、Nginx 与 HAProxy。以下保留其知识主线，并按现代部署的分层职责整理。

表 94：负载均衡常见产品、算法与适用边界

3.2.6 Netty 与自定义 RPC：事件循环、编解码和请求关联

上传 PDF 第 8 章（目录标注页 147–158）涉及 Netty 高性能机制、Reactor、零拷贝、内存池、RPC 请求 ID、回调映射、Protobuf、Thrift 与 RMI。资深面试更关注网络线程模型与失败处理，而不是只背“异步、NIO、高性能”。

表 95：Netty/RPC 的关键机制

3.3 消息队列栈

表 10：四款消息中间件考察侧重对照

面试范围：至少能比较 Kafka、RocketMQ、RabbitMQ，并理解 Pulsar、JMS/ActiveMQ Artemis、云托管消息服务及 Spring 集成框架的定位。把 Broker、客户端库、Spring 适配器和流处理工具区分清楚。

3.3.1 MQ 通用基础：模型、投递语义与顺序边界

表 77：MQ 通用模型与投递语义对照

3.3.2 消息端到端防丢、消费幂等与重试风暴防范

• 防丢闭环：生产端带回调重试；Broker 采用同步落盘/多副本同步；消费端严禁自动提交位点，业务处理成功后再手动 ACK。
• 消费幂等兜底：在至少一次投递、消费者超时重试、提交确认丢失或进程故障等场景下，可能出现重复投递/重复处理。对这类业务应使用“业务唯一键 + 本地数据库唯一约束（或分布式状态机）”实现原子防重，并明确消费位点提交与业务事务的边界。

覆盖范围说明：原版只对 Kafka 机制做了较细说明，并用 Kafka、RocketMQ、RabbitMQ、Pulsar 做了产品级对比；对 MQ 通用语义、各 Broker 内部机制、JMS/云托管消息服务及 Spring/集成框架覆盖不完整。本轮已补齐主流面试地图。消息产品持续演进，以下按“常见度 + 机制代表性”整理，不声称罗列全球所有商用产品。

3.3.3 Kafka 核心机制与可靠性因果链条

• 高吞吐五大来源：顺序追加写（Append-only）、OS 页缓存利用、sendfile 零拷贝（省去两次 CPU 拷贝与用户态切换）、批量压缩、分区分段稀疏索引（每 4KB 记录一条索引）。
• 可靠性链条：acks=-1(all) + min.insync.replicas=2；Leader 维护 ISR，HW 决定消费者可见性边界，防止未提交数据在 Leader 切换时引发脏读。
• 生产端幂等：enable.idempotence=true，分配 PID 并通过单调递增 Sequence 避免重复发送。

3.3.4 Kafka 深入：日志、消费者组、事务与运维

• 存储模型：Topic/Partition、Leader/Follower、日志段、索引、保留策略与 log compaction；区分消息保留和消费者是否已消费。
• 副本与可见性：ISR、LEO、HW、消费可见性与 Leader 选举；理解 acks、min.insync.replicas、副本数的配合及其在故障时的可用性/数据丢失权衡。
• 生产端：batching、linger、压缩、重试、超时、buffer.memory、幂等生产者 PID/sequence；幂等生产者的范围和配置依赖版本。
• 消费端：Group Coordinator、分区分配、rebalance、心跳/拉取间隔、位点提交、重试与暂停分区；扩容消费者超过可分配分区数后不一定提升并行度。
• 事务与 EOS：事务生产者、read_committed、事务性消费-处理-生产链路；若数据库已提交而 Kafka offset 尚未提交，或外部调用已成功，应由幂等、Outbox/Inbox 或可恢复状态处理跨系统边界。
• 生态：Kafka Streams 的流处理状态、窗口与再处理；Kafka Connect 的 Source/Sink 连接器；Schema Registry 与 Avro/Protobuf/JSON Schema 兼容策略；MirrorMaker 2/复制与跨集群灾备。
• 运维：Consumer Lag、分区不均衡、热点分区、ISR 收缩、磁盘水位、请求队列、网络与请求超时、重平衡循环；用指标定位生产者限流、Broker 瓶颈还是下游消费慢。

3.3.5 RocketMQ 深入：业务消息能力与 4.x/5.x 差异意识

• 架构：NameServer/路由发现、Broker、CommitLog、ConsumeQueue/索引等基础结构；新旧版本在代理、客户端协议、消费模型和部署选项上可能存在差别。
• 消息模型：普通、顺序、延迟/定时、事务消息、批量与过滤；掌握 Topic、Tag、Consumer Group、消费进度、重试主题与死信队列。
• 事务消息：半消息、执行本地事务、提交/回滚以及 Broker 回查；必须讨论本地事务可查询性、回查幂等、最终一致性和业务状态机。
• 顺序消息：按业务 Sharding Key 路由到同一队列并串行消费；需要明确热点业务 Key、失败重试对队头阻塞的影响。
• 重试和死信：区分短暂故障与毒消息；配置最大重试、延迟退避、死信监控、人工修复/重投和业务幂等。
• 迁移题：从 4.x 到 5.x 不应只改客户端依赖；按官方迁移说明核对客户端协议、Broker 版本、部署形态、权限、延迟/定时消息和消费行为。

3.3.6 RabbitMQ 深入：Exchange、Confirm、ACK 与 Quorum Queue

• 路由模型：Exchange 的 direct/topic/fanout/headers 类型，Queue、Binding、Routing Key、Virtual Host、TTL、优先级与死信转发。
• 生产可靠性：Publisher Confirms 确认 Broker 接收/处理状态；Return 处理不可路由消息；结合持久化消息、durable queue 和合适队列类型设计完整链路。
• 消费确认：manual ACK/NACK、requeue、prefetch/QoS、消费者超时与连接断开后的重投；ACK 只代表消息被确认，不代表业务副作用天然原子。
• 队列类型：Quorum Queue 基于 Raft 的复制与一致性取舍；Streams 适用于可重复读取的日志式用法；需理解经典队列与不同版本特性的迁移边界，不能继续把旧式镜像队列当成所有新部署的默认方案。
• 常见故障：连接/Channel 数过多、Unacked 堆积、预取过大、队列持续增长、磁盘告警、不可路由消息、死信循环、重投风暴；结合管理 UI、Broker 指标与应用日志定位。

3.3.7 Apache Pulsar 深入：多租户、订阅与存算分离

• 架构角色：Broker 处理协议与分发，BookKeeper/Bookie 持久化日志，元数据/协调组件负责集群元数据；具体部署依版本和托管形态而异。
• 命名和隔离：Tenant / Namespace / Topic、资源配额、权限、保留和 TTL；多租户平台要同时考虑性能隔离与成本隔离。
• 订阅类型：Exclusive、Failover、Shared、Key_Shared；理解是否保序、并发度与消费者故障切换之间的取舍。
• 进阶能力：分层存储、Schema、重放、事务、地理复制、持久/非持久主题；每项能力都应核对目标版本、配置和运营限制。
• 与 Kafka 对比：从分区/订阅模型、存储架构、多租户、消费模式、生态、团队运维复杂度和迁移成本比较，不以单项吞吐测试直接下结论。

3.3.8 JMS、ActiveMQ Artemis 与传统企业消息系统

• JMS API：理解 ConnectionFactory、Connection、Session、Destination、MessageProducer/Consumer、消息选择器、持久订阅、事务 Session 与 ACK 模式。JMS 是 Java 消息 API/规范体系，不是 Broker 产品。
• ActiveMQ Artemis：Queue/Topic、地址与队列路由、协议支持、DLQ/过期队列、集群/桥接、持久化和事务语义；注意它与 ActiveMQ “Classic”是不同产品线。
• 企业级选项：IBM MQ、Oracle AQ/TxEventQ 等可能出现在金融、制造或既有企业系统；掌握系统边界、事务/安全/运维要求即可，不必在没有目标岗位依据时追所有专有运维细节。
• 与 Spring 对接：Spring JMS、JmsTemplate、监听容器与事务管理；重点理解 JMS Session 事务和数据库事务是否由同一管理器原子协调，不能默认跨资源自动原子化。

3.3.9 MQ 产品与 Java 集成框架总览

面试时要分清三层：Broker/托管消息服务负责存储路由和投递；Java 客户端/适配器负责 API 与确认/重试封装；集成/流处理框架负责抽象、编排、连接器或事件处理。它们不是同一类竞品。

表 78：MQ 产品、客户端、集成与流处理框架矩阵

• 优先掌握：Kafka + RocketMQ + RabbitMQ 的核心区别，至少一种 Spring 集成方式，以及通用可靠消息设计。
• 按岗位扩展：数据平台深入 Kafka/Pulsar/Connect/Flink；交易系统深入 RocketMQ/RabbitMQ/事务消息；金融和大型企业关注 IBM MQ/JMS；IoT 关注 MQTT Broker；云原生/多云平台关注托管消息服务与跨云治理。
• 不应机械背诵所有产品：掌握消息语义、故障边界、运维指标和迁移成本，远比记住几十个产品名称更重要。

官方版本快照（核验截至 2026-10-27，仅用于建立版本意识）：Apache Kafka 4.4.0（2026-10-22 发布）、RabbitMQ 4.4.0（2026-10-20）、Apache RocketMQ 5.5.1（2026-08-20）、Apache Pulsar 5.0.1（2026-10-26）。各项目版本策略、支持周期、客户端/服务端兼容性并不相同；尤其 MQ 升级必须检查协议/元数据格式、集群滚动升级顺序、客户端版本、复制/事务行为及回滚路径。Kafka 官方发布说明、RabbitMQ 支持与发布信息、RocketMQ 官方下载/版本页、Pulsar 官方版本页。

3.3.10 端到端可靠消息：Outbox、CDC、重试与幂等

表 79：端到端可靠消息方案选型对照

• 幂等键：优先使用稳定业务事件 ID/订单号 + 业务动作；不能简单用消息内容 Hash 作为唯一业务依据（合法重复业务可能内容完全相同）。
• 顺序与重试：先定义业务要求的顺序范围；失败后重试时决定阻塞当前分区/队列、退避重投还是进入独立重试队列，并接受相应顺序代价。
• 重放：明确从哪个 Offset/时间点/业务水位重放，如何隔离副作用、避免重复扣款/通知，以及如何验证数据补偿完成。
• 事务边界：说明数据库 commit、Broker confirm、消费 ack/offset 的先后次序，并逐个分析进程在每个时间点崩溃会发生什么。

3.3.11 MQ 性能、监控、安全与故障场景

• 容量估算：消息速率 × 平均消息大小 × 保留时长估算原始数据量，再计入副本、索引、压缩与安全水位；容量规划需按峰值和恢复窗口而非日均吞吐设计。
• 核心指标：生产失败率、发送延迟、Broker 磁盘/网络/请求队列、副本健康、消费 Lag/积压增长率、最老消息年龄、重试和 DLQ 速率、消费处理耗时、未确认消息数。
• 安全：TLS、SASL/认证、ACL/Topic 权限、租户隔离、凭据轮换、敏感载荷治理、审计与网络边界；权限不能只给到集群级通配符。
• 故障题：消息丢失、重复消费、积压持续增长、顺序错乱、Broker 切主、消费者重平衡循环、死信堆积、消息过期、队列不可路由、磁盘打满、跨机房复制延迟。
• 排查顺序：先确认生产端是否发出且收到确认，再确认 Broker 持久化/副本与路由，接着看消费者是否收到、处理耗时和 ack/offset，最后核对下游 DB、线程池、连接池及重试策略。
• 架构决策题：从消息大小、吞吐与延迟、顺序范围、保留/回放、多租户、事务要求、协议兼容、运维能力、云服务费用、团队熟悉度和迁移成本做决策，不用“哪个 MQ 最快”替代场景分析。

3.4 网络与 IO 栈

表 11：网络与 IO 最小必讲集合

3.4.1 连接池与 HTTP 客户端故障模式（表 33）

3.4.2 HTTP/2 与 HTTP/3 协议深入（表 51）

3.4.3 网络请求全链路分阶段耗时排查

生产网络排障应将一次请求分解为六个阶段分别衡量：

$\(\text{总耗时} = \text{DNS解析} + \text{TCP握手} + \text{TLS协商} + \text{请求发送} + \text{服务端处理} + \text{响应传输}\)$

避免将所有延迟笼统归结为“网络慢”。

3.4.4 数据库事务、连接池与线程池协同治理

• 级联枯竭风险：Tomcat 线程在长事务中持有数据库连接并发起慢 RPC，导致 HikariCP 连接池耗尽，阻塞后续请求线程，进而拖垮 Tomcat 线程池引发全局雪崩。
• 容量配比准则：

$\(\text{数据库实例最大承载连接} \ge \sum (\text{各应用实例数} \times \text{HikariCP maximumPoolSize})\)$

保持连接池精简，通过压测寻找吞吐拐点，避免无序放大。

3.4.4.1 HikariCP 小连接池原则与定容起点

连接池不是用来给每个应用线程分配一个数据库连接。数据库能同时高效执行的查询数有限；把连接池从 20 盲目放大到 200，可能增加数据库锁争用、运行队列、上下文切换和 P99 延迟，而不是线性提升吞吐。入口并发应通过线程池/信号量/队列在应用侧受控，并用连接获取耗时、活动连接、等待线程、SQL 执行时间和数据库 CPU 一起判断瓶颈。

定容流程：统计全局 DB 连接预算 → 估算并发 SQL 能力 → 设置保守初值 → 用生产相似的混合负载压测 → 找吞吐和延迟拐点 → 验证连接池耗尽、慢 SQL、DB 故障与流量突增时的保护效果。

3.4.5 零拷贝的暗礁：HTTPS 传输层加密悖论与 Linux kTLS 架构

Kafka 和 Netty 的高性能神话建立在操作系统 sendfile（零拷贝）之上。但在全站 HTTPS / TLS 普及的今天，资深架构师必须洞察一个底层的断裂：传统用户态 TLS 通常不能直接复用纯明文 sendfile 的数据路径；内核态 TLS（kTLS）等机制可在受支持的条件下恢复部分内核态数据路径优化。

表 59：kTLS 与传统用户态 TLS 零拷贝性能对比

架构破局与工程选型：

1. Netty TLS 引擎选型：JDK JSSE/SSLEngine 与 netty-tcnative（OpenSSL/BoringSSL，取决于构建和平台支持）各有兼容性、性能和运维成本。不要预设 JDK 实现必然低效，也不是所有服务都必须引入原生 TLS；应在相同协议、密码套件、证书配置和负载下进行吞吐、延迟、CPU、启动与故障回退压测后再选型。
2. Linux kTLS 接入：Linux 4.13 引入内核 TLS 基础能力，但 TLS 版本、密码套件、发送/接收方向、网卡卸载与应用框架支持随内核及库版本变化。若评估 Netty 与 kTLS/ sendfile 联用，应核对目标 Netty/native transport、OpenSSL/内核版本、TLS 配置和实际使用路径；不是只开启 CONFIG_TLS 就能保证恢复零拷贝。

3.4.6 经典 I/O 模型、网络协议与 Reactor

在 HTTP/2、HTTP/3 与连接池专题之外，补齐 PDai 的 Linux I/O 模型、Reactor、TCP 流语义与基础网络协议问题，以及《成神之路》的 HTTP、DNS、Cookie/Session 与反向代理主题。

表 84：I/O 模型与网络编程核心问法

3.4.7 CDN、边缘缓存与源站保护

上传 PDF 第 9 章（目录标注页 159–168）列出 CDN 的分发、负载均衡与管理系统。把 CDN 理解成“离用户更近的可编程缓存与流量入口”，需要同时理解缓存键、过期、刷新、回源和访问控制。

表 96：CDN/边缘缓存的关键设计点

3.5 响应式编程栈（Reactor/RxJava/WebFlux）

• 核心概念：响应性、弹性、伸缩性与背压（Backpressure）机制。
• 陷阱与禁区：严禁在 Reactor/WebFlux 事件循环线程中调用阻塞式 I/O（如 JDBC、同步 HttpClient），否则将导致少量核心调度线程被永久阻塞，服务瞬间瘫痪。

4. 数据存储与缓存栈

4.1 MySQL 栈

表 12：MySQL 栈复习条目

4.1.1 隔离级别、读类型与幻读两条路径（表 13）

4.1.2 一条 UPDATE 的日志旅程与两阶段提交

1. 写 Undo Log ：记录物理旧值，支撑事务回滚与 MVCC 快照读。
2. 改内存并写 Redo Log (Prepare) ：修改 Buffer Pool 数据页，写 Redo Log 物理日志，状态置为 Prepare（WAL 机制）。
3. 写 Binlog ：Server 层写入逻辑 binlog 并落盘（由 sync_binlog 控制）。
4. 提交并写 Redo Log (Commit) ：Redo Log 状态变更为 Commit，响应客户端成功。

4.1.3 分库分表、不停机迁移与 ShardingSphere 三大坑（表 38）

4.1.3.1 冷热分离与数据归档（表 34）

4.1.3.2 分区表真实代价与大表 DDL 四层方案（表 41）

• 分区表真实代价：分区表是单库内物理分段，分区键必须在主键中；若查询未命中分区键将引发全分区扫描，性能比单表更差；分区过多导致元数据与 DDL 极慢。
• 大表 DDL 四层方案（表 41）：
  1. MySQL 8.0 Instant DDL：秒级修改元数据（仅限追加列等）。
  2. Online DDL INPLACE：支持并发 DML，但仍有 MDL 锁和从库延迟风险。
  3. gh-ost：解析 Binlog 同步至影子表，无触发器开销，首选推荐。
  4. pt-online-schema-change：基于触发器同步，高并发下主库争用大。
• MDL 锁链式阻塞：DDL 等待长事务释放 MDL 读锁，导致后续所有读查询在 MDL 队列排队，瞬间打满连接池。大表 DDL 必须低峰期执行并设置超时。

4.1.3.3 MySQL + ShardingSphere 与 TiDB / OceanBase 选型边界

这是架构权衡而非单纯性能排名。ShardingSphere 以应用侧/代理侧分片与路由为主，保留单分片 InnoDB 的局部低延迟优势，但需要治理跨分片事务、JOIN、全局索引、分布式分页、扩缩容和数据迁移。TiDB/OceanBase 将分布式 SQL、共识复制与分布式事务纳入数据库体系，降低应用层分片编排负担，但跨节点协调、时钟/事务协议、网络 RTT、数据分布和集群运维都会影响延迟与成本。

4.1.4 索引失效七类、深分页与主从延迟

• 索引失效七大场景：1. 隐式类型转换（字符列传数字）；2. 索引列使用函数或表达式；3. 前导通配符 like '%xxx'；4. 联合索引跳过首列（不满足最左前缀）；5. or 条件一侧无索引；6. !=、not in 导致全表；7. 优化器成本估算回表代价过高。
• 深分页优化：采用延迟关联（通过覆盖索引子查询取主键再 JOIN 原表）或游标分页（where id > :last_id order by id limit 20）。
• 主从延迟治理：开启并行复制（slave_parallel_workers，MySQL 8.0 writeset）；关键业务读强制走主库；大事务拆分。

4.1.5 数据库备份、灾备恢复与 RPO/RTO 治理

• RPO（Recovery Point Objective）：业务容忍丢失的最大数据时间跨度（如 \(\le\) 5分钟）。
• RTO（Recovery Time Objective）：发生灾难至恢复可用状态允许的最长耗时（如 \(\le\) 30分钟）。
• PITR（Point-in-Time Recovery）：基于全量物理备份基线重放连续 Binlog，精确恢复至任意历史秒级时间点。定期自动演练校验备份的真实可恢复性。

4.1.6 业务不变量与并发条件更新保护机制

如果业务只在应用层执行无锁的“先查后改”，并发请求可能基于同一旧值继续写入，产生超卖等竞态。应根据业务约束使用数据库原子条件更新、唯一约束、行锁或乐观锁（版本号）实现并发保护：

UPDATE inventory
SET available = available - :quantity
WHERE sku_id = :skuId AND available >= :quantity;

通过检查受影响行数判断扣减成功与否，配合乐观锁版本号（version）防御更新丢失。

4.1.7 关系模型、范式、并发控制与数据库可编程对象

上传 PDF 第 19 章（目录标注页 214–224）除了 MySQL 索引/事务，还列出数据库范式、ACID、存储过程、触发器、乐观/悲观并发策略、锁层级与分库分表。现有 MySQL 专题已经深入 InnoDB，因此本节只补关系设计与通用概念，不重复 MVCC/Next-Key Lock 细节。

表 97：关系数据库基础与并发控制补充

4.1.8 EXPLAIN 执行计划解读与 SQL 优化证据链（表 111）

现有 MySQL 章节已覆盖索引、事务、MVCC、深分页和主从延迟；本节把面试中常见的“如何证明 SQL 慢在哪里”落到执行计划字段和诊断次序，避免只背索引失效场景。

• 诊断顺序：确认慢查询样本和绑定参数 → 看执行计划与实际耗时 → 检查扫描行数、过滤率、JOIN 顺序和回表 → 验证索引/SQL 改动 → 对比 P95/P99、锁等待、CPU 与磁盘 I/O。
• 修复策略优先级：消除不必要查询和返回列、调整谓词与联合索引、优化 JOIN 与分页、更新统计信息或重写 SQL；只有证据支持时才考虑提示或强制索引。
• 版本提示：EXPLAIN ANALYZE 的可用性、输出格式和语义依 MySQL 具体版本而定，阅读执行计划时应使用目标环境的官方手册。

4.1.9 InnoDB Buffer Pool：LRU Old/Young 与刷脏页抖动

Buffer Pool 缓存数据页和索引页。InnoDB 使用带有 old/new 子列表的 LRU 变体来降低扫描污染。默认 old 子列表大约占 3/8，new/young 约占 5/8，不要把两者比例写反或当作固定不变的所有版本常量。

4.1.10 InnoDB 死锁日志：从锁等待到 SQL 证据链

1. 采集：立即执行 SHOW ENGINE INNODB STATUS\G，查看 LATEST DETECTED DEADLOCK；频繁发生时在授权与日志容量评估后开启 innodb_print_all_deadlocks 收集更多样本。
2. 定位两个事务：分别提取 TRANSACTION、持有锁（HOLDS THE LOCK(S)）、等待锁（WAITING FOR THIS LOCK TO BE GRANTED）、SQL 文本和回滚受害者。
3. 回到索引：判断使用的是聚簇主键、普通二级索引还是唯一二级索引；检查扫描范围、间隙/Next-Key 锁、唯一性检查、外键以及是否按不同顺序更新多行。
4. 构造时间线：事务 A 已持有锁 X 等待 Y，事务 B 已持有 Y 等待 X，形成等待环。非主键唯一索引的插入/更新可能涉及唯一性检查和相关索引记录锁，但死锁成因必须按具体锁模式与 SQL 还原，不能简单归因于“二级索引必然 Next-Key 锁”。
5. 整改：缩短事务、按一致顺序访问资源、补齐过滤列索引、避免在事务中做远程调用；应用端对死锁回滚做有边界的重试，保证业务幂等并记录重试率。

SHOW ENGINE INNODB STATUS\G
SHOW VARIABLES LIKE 'innodb_print_all_deadlocks';
-- MySQL 8.0/8.4 可结合 Performance Schema 的 data_locks / data_lock_waits 分析当前等待

死锁与锁等待超时不是同一种错误；InnoDB 通常会检测死锁并回滚一个事务，但事务被选为 victim 后，应用仍需处理失败与重试。官方文档建议保持事务短小，并对涉及多行/多表的操作采用一致访问顺序。

4.1.11 主从延迟下的因果读与 Read-Your-Writes

需求不是“从库永远无延迟”，而是同一用户写入后读取该写入时，不能读到明显旧版本。可采用主库读、复制位点/GTID 等待、会话级一致性路由等策略。

1. 写路径记录因果标识：在提交写事务后获取该事务的 GTID（可评估 MySQL 的 session tracking 能力）；不要随手读取一个全局 GTID 集就误认为它严格只代表当前会话的事务。
2. 读副本前等待：在支持 GTID 的拓扑下，副本侧可用 WAIT_FOR_EXECUTED_GTID_SET(gtid_set, timeout) 等待目标事务已执行；传统 binlog-file/position 模式可用相应位置等待函数。
3. 超时策略：副本在预算内追平则从副本读；超时后按业务选择回源主库、返回显式重试/稍后刷新，或允许旧读。不得无限等待占满连接池。
4. 会话而非全局承诺：把写事务的 GTID/位点与用户会话或请求上下文关联，设置过期和跨服务传递规则。跨库、多个事务或跨地域写入可能需要多个因果标识，而不是单一 GTID。
5. 可观测性：记录副本延迟、等待耗时、超时比例、回源主库比例和读一致性命中率；在容量规划中计入等待占用与主库回退流量。

4.1.12 MySQL 8.0 优化器深水区：Hash Join、倒序索引、不可见索引与 JOIN 顺序

MySQL 优化器的行为必须和具体版本绑定。MySQL 8.0.18 引入 Hash Join；从 8.0.20 起不再使用传统 Block Nested-Loop 算法，并在原本会使用 BNL 的场景采用 Hash Join。Hash Join 的内存受 join buffer 相关预算约束，超出内存时可能使用磁盘文件，不能把它理解成“无索引关联一定很快”。

版本核验：Hash Join 的适用条件、BNL 移除与内存/磁盘行为请以 MySQL 8.0 对应小版本官方手册为准。不要将 MySQL 5.7 的优化器行为直接套用到 8.0。

4.2 Redis 与缓存栈

表 14：Redis 栈复习条目

4.2.1 两组必须给出结论的选型

• 持久化选型：纯 RDB 易丢数据，纯 AOF 恢复慢且文件大。生产首选 RDB + AOF 混合持久化。
• 高可用选型：哨兵解决主从单点故障（提供自动故障转移）；Cluster 解决单机容量与写吞吐上限（16384 槽分片）。两者解决不同维度，超大规模为分片集群每分片做主从。

4.2.2 分布式锁边界：续期不等于安全

Redisson Watchdog 解决业务未执行完锁过期问题；Lua 比对 UUID 保证不误删他人的锁。但分布式锁本质是降低冲突的性能优化手段，绝不是资金级正确性的唯一保障；客户端长时间 GC 停顿或网络分区仍会导致锁失效。强一致业务必须依赖数据库唯一约束、版本号 CAS 条件更新作为最终正确性兜底。

4.2.2.1 Fencing Token 如何在持久层真正生效

分布式锁服务只告诉客户端“曾经获得锁”，不能阻止租约过期后的旧持有者继续运行。Fencing Token 必须由最终资源端校验，且每次成功授予锁时单调递增；随机 UUID 不具备这个属性。

-- 示意：资源行保存已接受的最大 token；具体 SQL 要结合业务更新条件与并发事务设计
UPDATE resource_record
SET payload = :payload, fencing_token = :token
WHERE resource_id = :id
  AND fencing_token <= :token;

• 影响行数为 1：token 为当前最高值或更高值时，更新获准；影响 0 行：通常表示 token 已过旧或记录不存在，需区分处理。允许同一个租约 token 执行该租约内的多个合法写操作（示例用 <=），但一旦更高 token 被资源端接受，旧 token 必须被拒绝。
• 若一次业务跨多行/多表，所有相关写入必须处于同一事务，且不能先执行不可撤销的外部副作用再做 token 校验。
• token 的生成方必须保证对同一资源严格单调；发生锁服务恢复、主从切换或计数器回滚时，需要明确 epoch/持久化语义。
• 如果资源端无法存储或原子比较 token，就不能宣称获得真正 fencing 保护；只能说明该方案提供租约式互斥，并保留失效持有者的风险。

4.2.3 缓存一致性：四种方案的适用边界（表 15）

4.2.4 淘汰策略、过期删除与 big key／热 key 治理（表 16）

• 近似 LRU 与 LFU：LFU 采用 24 bit 存储（高 16 位记录上次衰减时间，低 8 位存储基于概率对数递增的访问计数）。
• String big key 的 lazyfree 边界：UNLINK 命令对集合型 Big Key 能在后台异步释放，但对几 MB 乃至几十 MB 的 String 大对象，Redis 仍可能在主线程直接释放物理内存块引发短暂卡顿。治理方案必须前置拆分或压缩。

4.2.5 Redis Sentinel、Cluster 与故障切换深挖

现有 Redis 小节已列出哨兵、Cluster、持久化与分布式锁，本节把常见面试追问落到判定条件、数据丢失窗口和客户端行为，避免只记住“哨兵高可用、Cluster 分片”两句口号。

表 85：Redis 高可用、复制与集群边界

4.2.6 缓存穿透、击穿、雪崩、预热与降级的完整处置

上传 PDF 第 24 章（目录标注页 257–258）专门列出缓存雪崩、穿透、预热、更新与降级。现有章节已经覆盖 Cache Aside、延迟双删、MQ/CDC 删缓存与 big key；本节把“故障现象—缓解机制—代价”串起来，避免不同问题共用一个答案。

表 98：分布式缓存常见故障与缓解手段

4.2.6.1 Bloom/Cuckoo Filter、SingleFlight 与平滑预热

预热按热点清单分页限速、支持中断和幂等；恢复时逐步增加回填并观察 DB QPS、连接池等待、缓存命中和延迟。降级开关需要动态配置、权限、审计、TTL/自动回收及演练，避免永久降级。

4.2.7 Redis 数据结构、持久化与生产命令治理（表 112）

原报告已细化缓存一致性、淘汰策略、big key、哨兵和 Cluster；本节参考 JavaGuide Redis 面试专题，将数据结构选型、持久化窗口与生产命令风险放在同一张核对表里。来源：JavaGuide Redis 面试题总结。

生产自检：避免高峰期执行未知复杂度的大命令；通过 SLOWLOG、延迟监控、INFO、内存采样和 key 级分析定位问题；任何 Redis 分布式锁、计数器或队列设计都要说明客户端重试、主从切换和数据丢失窗口。

4.2.7.1 Redis 内部编码演进与生产命令审计

4.2.8 Redis 6/7 深水区：网络 I/O 多线程与 Multi-Part AOF

Redis 6 引入可配置的网络 I/O 多线程能力，但它并不意味着 Redis 命令执行整体变成多线程并行：请求解析/读取与响应写回可在配置允许时借助 I/O 线程，数据结构命令执行的核心路径仍以主事件循环串行为主。Redis 7 的 Multi-Part AOF 则把重写基线与增量变更拆分为多个文件，并由 manifest 跟踪。

不要把“Redis 单线程”解读为所有后台工作都是单线程；也不要把“Redis 6 多线程 I/O”解读为普通命令在多个线程并行执行。版本、配置与负载决定具体效果。

4.3 搜索引擎、文档库与向量库栈

• Elasticsearch：倒排索引与 Segment 不可变性；分片路由；写入通过 Translog 与 Refresh 保证近实时；脑裂通过 Quorum 仲裁避免。
• MongoDB：文档型灵活建模；支持 4.0+ 跨文档多表事务（有性能开销）；分片集群与副本集。
• 向量数据库（Milvus / Pinecone）：在高维空间构建 HNSW 索引，支撑 RAG 与语义检索。

4.3.1 MongoDB、HBase 与 Cassandra：模型、存储路径和选型

上传 PDF 第 14–16 章（目录标注页 183–200）分开介绍 HBase、MongoDB 与 Cassandra。当前报告只在数据存储总览中提及部分产品，因此这里补齐适合 Java 后端面试的模型与读写路径；2018 年资料中的旧数据模型叫法不直接作为现代版本结论。

表 99：文档型与宽列型数据库对照

4.3.1.1 MongoDB、HBase、Cassandra 的存储读写路径与放大效应

不要把 HBase、Cassandra 的 LSM/追加写模型等同于“写入没有成本”：它们通常以后台 Flush/Compaction 换取顺序写与规模扩展；读放大、空间放大、修复和数据模型约束仍是核心成本。MongoDB 的事务/读写关注点则要按部署模式、读写 concern、索引和具体版本判断。

4.3.2 Elasticsearch/Lucene：倒排索引、Segment、分片与深分页

定位慢查询时先检查 query profile、命中数、聚合基数、分片数、缓存、segment 数与 merge/refresh 压力；不要仅通过增加分片或副本解决查询慢。

4.3.3 向量检索索引：HNSW 与 IVFFlat 的构建、召回和内存取舍

向量检索的近似索引通常用速度和资源换取一定的召回率。HNSW 通过多层邻近图进行导航；IVFFlat 先将向量划分到若干聚类列表，查询时只探测部分列表。二者的构建流程、内存、查询延迟和过滤后的有效召回不同，必须以目标语料、维度、过滤条件与召回目标做实验。

HNSW 不是“跳表”；它是多层图导航结构。索引参数与名称会随向量数据库实现不同而不同，表中的参数以 pgvector 为代表，其他产品应查对应版本文档。

4.4 ORM 与 SQL 执行层（MyBatis / MyBatis-Plus）

表 29：MyBatis 核心机制与资深岗位追问落点

4.4.1 JPA/Hibernate 与 MyBatis 的边界比较

《成神之路》明确包含 ORM、Hibernate 缓存与懒加载，并比较 Hibernate/iBatis/MyBatis。本节补充到现有 MyBatis 执行链专题之后，重点解释 ORM 的实体状态、缓存和查询副作用。

表 86：ORM 框架机制与选型边界

4.4.2 MyBatis 执行器、插件拦截点与缓存边界深挖

5. 架构设计与方法论栈

5.1 DDD 栈

表 17：DDD 栈复习条目

5.1.1 DDD 战略设计、战术模型与架构依赖方向

面试深问：一个规则放在 Entity、Domain Service 还是 Application Service？先看规则是否围绕单个实体/聚合不变量、是否涉及多个领域对象、是否属于用例编排。不要把所有逻辑塞进 Service，也不要为了“充血”把 I/O 与框架生命周期写进领域实体。

5.2 高并发高可用与分布式可靠性保障

表 18：分布式组件栈复习条目

表 37：单机 vs 分布式限流方案对比

5.2.1 分布式事务四模式选型表（表 19）

Seata 四模式落地失败矩阵

5.2.1.1 表 19 之外的两个轻量工程方案

• 本地消息表（Outbox）：业务数据与消息记录在同一个本地数据库事务中写入，通过定时任务或 CDC 异步投递到 MQ，解耦服务且无需引入重型事务框架。
• 最大努力通知：适用于支付回调等场景，通过带梯度的重试策略通知下游，下游提供主动对账反查接口兜底。

5.2.2 共识算法谱系速查（表 30）

5.2.2.1 Paxos、Raft 与 ZAB：选主、日志与安全性要点

• Paxos：理解 proposer/acceptor/learner 与 prepare/promise/accept 交互；Multi-Paxos 可在稳定领导者条件下摊薄重复选主成本。它解决共识问题，不等于自动提供数据库事务或任意线性一致 API。
• Raft：围绕 term、Leader Election、日志复制、commitIndex/lastApplied 理解安全性；多数派复制与日志匹配属性是核心。领导者变化后，不能把“日志已发送给某个副本”等同于“已提交”。
• ZAB：面向 ZooKeeper 的原子广播与崩溃恢复，包含 epoch/ZXID 等概念；与 Raft 解决的问题相近，但具体选举、恢复和提交流程不同，不能把两个协议的状态机细节混写。
• 复习方法：用同一故障时序比较：Leader 在发出日志后、收到多数派前崩溃；网络分区导致双候选；旧 Leader 恢复；少数派节点落后如何追日志。先回答安全性，再回答可用性和恢复时间。

5.2.3 业务幂等性深度设计方案

1. 客户端在发起请求前生成全局唯一的 idempotency-key 并随 Header 传递；
2. 服务端在网关或业务前置过滤器校验幂等键；
3. 原子防重防穿透机制：严禁仅依赖 Redis SETNX 做唯一防线。Redis 仅用于拦截毫秒级并发重复点击；真正的防重必须依托数据库唯一索引约束；
4. 将幂等记录写入与业务更新置于同一本地事务；
5. 保存执行结果，重复请求直接返回历史快照结果或返回 409 Conflict；
6. 结合合理的 TTL 过期清理策略治理历史幂等记录。

5.2.3.1 多层幂等防线：业务键、状态机与版本 CAS

1. 传输层请求键：客户端生成唯一 Idempotency-Key，定义作用域、过期时间、并发相同键时的响应和结果缓存。
2. 数据库最终约束：在业务表或幂等表上建立业务唯一索引；将防重记录、业务变更和返回结果快照置于合适的本地事务中。
3. 状态机条件：使用“当前状态必须为 X”或版本号 CAS 的条件更新，拒绝过期/重复转换。
4. 外部副作用：MQ 消费端用业务事件 ID + 唯一约束/Inbox，外部支付/配送等依赖对方幂等键或查询对账；不能只靠 Redis SETNX。
5. 冲突响应：区分同键同参数、同键不同参数、处理中与失败可重试状态；对于已成功请求应返回保存的原结果或明确冲突语义。

5.2.4 重试机制、退避算法与重试风暴治理

• 重试风暴根因：当下游微服务因过载变慢，上游超时盲目重试会将流量放大数倍，形成雪崩正反馈。
• 治理规范：
  1. 仅对幂等操作且明确为偶发网络抖动的异常重试，业务失败（如余额不足）绝不重试；
  2. 采用指数退避（Exponential Backoff）配合随机抖动（Jitter）打散脉冲流量；
  3. 全链路纳入重试预算（Retry Budget）：根据服务 SLO、错误预算、下游剩余容量和实测基线设定阈值；可用 10% 作为某些系统的初始试验值，但它不是通用标准。超预算时优先限制额外重试、快速失败或按策略降级，不应不加区分地对所有流量直接熔断。

5.2.5 分布式定时任务与状态流转治理

• 设计解耦：调度平台（XXL-Job / ShedLock）仅负责触发与租约协调，严禁承载业务逻辑；任务执行器负责实际运算。
• 防重与断点续跑：任务执行前必须检查业务状态机；长任务必须设计为分片批处理并保存游标进度，支持节点崩溃重启后断点续跑。

5.2.5.1 分布式调度：分片、漏调度、重叠与补跑策略

• 调度器与执行器分离：调度层负责任务触发、路由、租约/选主和状态观察；执行器负责业务计算。任务状态必须可持久化查询，不能只存在进程内存。
• 任务语义：明确 at-most-once、at-least-once 或近似语义；宕机恢复时是否补跑、跳过错过的触发、合并连续触发，需要按业务选择。
• 分片与广播：分片任务有稳定分片键和幂等游标，节点缩容后能重新分配；广播任务要避免每个节点重复执行不可重复副作用。
• 防重叠：短任务可用租约/分布式锁加 fencing token 或数据库唯一任务实例；长任务支持心跳、超时接管、断点续跑和人工恢复。
• 框架对照：XXL-Job、Elastic-Job、Quartz 集群、Spring Scheduler/ShedLock 的能力不同；按目标版本核对注册发现、选主、失败重试、分片广播和运维 UI，不把框架自带触发器当成业务幂等保证。

5.2.6 分布式 ID 与业务流水号选型决策（表 56）

5.2.6.1 Snowflake 时钟回拨与 Leaf 号段双 Buffer

• Snowflake 时间回拨：发现当前时间小于上次时间时，不能继续无条件拼接时间戳。常见处理包括短暂等待小幅回拨、拒绝生成并告警、使用备用 worker/epoch 策略或切换号段方案；策略须保证同一 worker/时间段不复用序列空间。
• WorkerId 唯一性：实例重启、自动扩缩容、网络分区和租约失效可能导致两个进程使用相同 WorkerId；分配需要租约/持久化登记和 fencing/代际机制，而不只是启动时随机取值。
• Leaf 号段模式：数据库按批获取号段后本地递增；双 Buffer 可在使用当前号段时异步申请下一号段，降低请求路径延迟。要验证预取失败、切换边界、进程崩溃后的号段空洞、数据库主从故障和机器时间变化。
• 业务流水号：唯一、趋势递增、可排序、不可猜测与连续性是不同要求；面向用户的编号不应意外暴露交易量或敏感业务规模。

5.2.7 分布式状态机建模与异常补偿机制

• 显式状态机设计：针对订单、支付等业务必须明确定义有限状态机（FSM）。状态更新强制携带前置状态条件：

UPDATE orders SET status = 'PAID' WHERE order_id = :id AND status = 'UNPAID';

• 异常对账补偿：针对超时未决状态，后台异步巡检对账任务定期捞取未终态记录，主动向第三方渠道查询反哺，必要时转入人工审核工单池。

5.2.7.1 分布式状态机与补偿闭环

状态机应显式列出状态、合法事件、前置条件、状态迁移、超时规则、重试规则、补偿动作与人工介入条件。更新状态用条件 SQL 或版本号 CAS 保证并发下只发生合法迁移。对于“处理中”超时状态，后台对账需要查询权威外部状态，而不是直接把超时等同于失败；补偿失败要转入可观测的重试队列和人工工单，保留触发原因、请求/响应摘要、尝试次数及责任人。

5.2.8 异地多活单元化（Cell-based）架构与数据冲突裁决

单机房架构存在物理可用性上限。大型互联网金融与电商系统必须走向单元化多活（Cell-based Architecture）。核心考察点不在于部署多套系统，而在于流量路由闭环与跨地域数据防回环同步与冲突裁决。

表 60：单元化多活关键设计与冲突裁决机制

5.2.8.1 单元封闭率、跨机房数据仲裁与 CRDT 边界

• 单元封闭率：统计请求主路径中不跨单元的比例、跨单元调用次数和跨单元数据写入率；高封闭率能降低跨地域依赖，但无法替代全局一致性设计。
• 数据防回环：CDC 事件携带来源单元、事件 ID、版本/因果标记；目标写入应保留可检索的来源元数据，过滤回流事件并做去重。过滤规则要经故障演练验证，避免错误过滤合法变更。
• 脑裂与仲裁：区分控制平面选主与业务数据冲突。LWW 用时间戳胜者可能丢失并发更新且依赖时钟质量；CRDT 只适用于能满足其合并代数条件的数据类型，并非任意订单、余额、库存都可自动冲突合并。
• 资金/库存类数据：通常需要唯一权威写入、强约束或显式预留/补偿，不应以“多活 + LWW”作为资金正确性方案。

5.2.9 一致性哈希、Gossip 与 N/W/R 读写法定人数

上传 PDF 第 20 章（目录标注页 225–231）把 Paxos、ZAB、Raft、N/W/R、Gossip 和一致性哈希并列。当前报告已有共识算法谱系，但还应区分“决定一致的状态机日志”与“数据副本读写/节点成员传播”的问题。

表 100：共识、复制与分片三类问题的边界

5.2.10 高可用机制协同：限流、隔离、降级与恢复（表 113）

JavaGuide 的高可用专题将 SLA、限流、熔断、重试、幂等、冗余和故障演练放在同一套系统设计问题里。这里把常见机制整理成“入口保护—依赖保护—业务兜底—恢复验证”的工程闭环。来源：JavaGuide 高可用系统设计面试题。

• 面试时区分 SLA（对外服务承诺）、SLI（用于衡量的指标）和 SLO（目标值）；先说明服务级目标，再据此设计超时、重试和故障预算。
• 可用性不等于“部署多份”。还需要消除单点、容量验证、数据库/缓存/MQ 依赖保护、备份恢复演练、监控告警和可执行的止损预案。
• 恢复演练的验证指标包括故障检测时间、切换时间、恢复后数据差异、RPO/RTO 是否达标，以及恢复流量是否导致二次过载。

5.2.11 TCC 空回滚、悬挂与幂等：分支控制表落地范式

TCC 的 Try/Confirm/Cancel 是业务级协议，不能仅靠“Cancel 方法写成幂等”解决所有竞态。空回滚发生于 Try 未成功执行或请求超时未落库，但协调器已发来 Cancel；悬挂发生于 Cancel 先到并结束后，迟到的 Try 仍试图预留资源。持久化的分支状态与唯一约束可以将这些边界显式化。

-- 示意结构；字段、长度和索引需按事务协调器及业务数据库调整
CREATE TABLE tcc_branch_guard (
  xid        VARCHAR(128) NOT NULL,
  branch_id  VARCHAR(128) NOT NULL,
  state      VARCHAR(16)  NOT NULL,
  updated_at TIMESTAMP    NOT NULL DEFAULT CURRENT_TIMESTAMP
                          ON UPDATE CURRENT_TIMESTAMP,
  PRIMARY KEY (xid, branch_id)
);

-- 关键原则：状态迁移使用带旧状态条件的 UPDATE，
-- 并在同一本地事务中完成资源预留/释放与状态记录。

这是工程模式示意，不是可直接复制到所有 Seata 版本的完整实现。实际接入要确认分支注册/回调时序、事务 ID 唯一性、异常补偿和历史记录清理策略。

5.2.12 Seata AT 脏写、全局锁绕过与补偿修复闭环

Seata AT 在受代理的数据源操作中记录 undo_log，并进行全局锁相关检查。若某个外部写入路径绕过 Seata 代理/全局锁直接修改同一行，AT 回滚时可能发现当前镜像与回滚所需镜像不一致，导致回滚失败或全局事务长期阻塞。这类故障不能通过随意删锁或删 undo_log 解决。

Seata 版本、数据库类型和具体模式会影响回滚细节。排障时以目标版本官方文档、事务表状态和实际日志为准；业务补偿应优先保持可审计，而不是依赖手工清理元数据。

5.2.13 Cell-based 单元化中的全局共享数据与单写策略

单元化将按用户、租户或业务路由键可分片的数据尽量封闭在一个 Cell 内，以缩小故障爆炸半径。但商品元数据、全局权限配置、账户目录等无法自然按业务键隔离的共享数据，会引入跨单元复制与仲裁问题。架构上必须明确数据的权威写单元、复制方向、版本语义与故障切主协议。

多活不是“每个机房都可以写同一份数据”。关键是逐类定义写权、冲突语义、单元封闭率和故障时的业务降级方式。CRDT 只适用于其数学合并规则与业务语义匹配的数据类型。

5.2.14 CQRS / Event Sourcing：投影延迟、读己之写与重放对账

CQRS 将命令写模型与查询读模型分离，Event Sourcing 进一步把事件序列作为业务状态演进的事实来源。读模型投影通常异步生成，因此必然存在 Projection Lag；“命令已成功”不代表所有查询视图已经看到新状态。架构要为读己之写、重放、事件版本演进和投影修复定义显式协议。

“Exactly-once”通常是系统局部或处理语义，不会自动跨越数据库、事件代理、外部 HTTP 和邮件等副作用。端到端可靠性仍依赖幂等键、Outbox/Inbox、状态机、重放和对账。

5.3 架构演进与设计题场景栈

• 四段式答题框架：
  1. 需求澄清：明确 QPS、读写比、数据规模、可用性与延迟 SLA。
  2. 容量估算：信封背面计算（如：1000 万日增 \(\times\) 500B \(\approx\) 5GB/天，推算存储与峰值 QPS）。
  3. 架构与数据流：画出链路、分层模型、存储选型。
  4. 瓶颈、容灾与演进：讨论降级、熔断、多活与演进路径。

5.3.1 绞杀者模式的落地四问

1. 双写一致性：新老表写入如何防丢？（CDC 增量捕获比应用双写更安全）。
2. 数据所有权：过渡期明确单向数据源头。
3. 流量灰度切分：按租户/用户维度从小比例向 100% 渐进切换，随时具备一键回滚开关。
4. 旧系统退役清单：设立明确的下线指标与 Checklist，避免两套系统长期双轨消耗成本。

5.3.1.1 单体到微服务的绞杀者迁移执行单

1. 按业务能力确定边界与单一数据所有者，先建立 API/事件契约与观测基线。
2. 优先把读路径切到新服务或建立 CDC 镜像，在影子流量下对比结果；敏感写路径不要无控制地双写。
3. 灰度以租户/用户/业务键分流，明确每阶段成功率、差异率、延迟和回滚阈值；准备一键回退流量与数据修复方案。
4. 数据割接后执行对账、补偿和旧链路冻结；在指标达标且观察窗结束后才移除旧代码/表。

5.3.2 API 设计与版本管理（表 52）

• RESTful 设计原则：资源使用名词复数（/api/v1/orders）；正确使用 HTTP 谓词；状态码语义精准；全局统一响应体 {code, message, data, traceId}。
• 版本管理对比：URI 路径版本（简单直观、推荐）、Header 版本（灵活性高、调试稍复杂）。

5.3.2.1 API/数据库兼容演进：Expand–Migrate–Contract

• Expand：先新增可选字段、兼容列或新接口，老客户端仍能运行；保证默认值和写入者行为明确。
• Migrate：部署兼容版本，回填数据，双读/单写或按阶段切换；监控新旧字段差异与消费者版本。
• Contract：确认所有旧消费者已迁移、回滚窗口关闭且数据校验通过后，才删除旧字段/接口。
• 兼容检查：不仅比较 JSON 字段是否存在，还要检查语义、默认值、分页/排序稳定性、错误码、幂等键与重试行为；对破坏性变更设置弃用通知和迁移窗口。

5.3.3 系统设计场景题案例库：订单、秒杀、短链与大数据导出（表 114）

JavaGuide 的系统设计专题强调先澄清需求和质量目标，再围绕数据模型、核心链路、失败处理与验证方案设计；高性能专题也使用订单系统作为综合案例。这里补充一组可复用的面试案例框架。系统设计与场景题 · 高性能系统。

统一答题流程：需求澄清 → 规模与容量估算 → 数据模型/状态机 → 核心读写链路 → 并发与一致性 → 过载及故障处理 → 监控、压测、灰度和回滚。不要为了显得复杂而默认引入 Redis、MQ、ES、分库分表或微服务；组件应由瓶颈和业务约束驱动。

5.4 架构决策记录（ADR）与技术治理

• 架构决策记录（ADR）要素：上下文背景、技术约束、被否决的备选方案、最终决策理由、引入的潜在风险与妥协、后续效果验证路径。
• 技术债治理：建立技术债健康度看板，将版本升级、框架解耦、慢 SQL 治理等非功能性工作纳入产品迭代排期。15%~20% 可作为部分团队的初始讨论值，而非通用硬指标；应结合线上风险、合规要求、交付周期和技术债利息定期调整资源比例。

6. 云原生、DevOps、大数据与 AI 栈

6.1 云原生与可观测性栈

表 20：云原生栈复习条目

6.1.1 Kubernetes 高级特性与生产排障

• OOMKilled 排查与堆外对齐公式： Exit Code 137 表示容器被 Linux 内核 cgroup OOM-Killer 发送 SIGKILL 强杀。Pod 内存配额对齐公式：

$\(\text{Container Limit} \ge \text{MaxHeap(-Xmx)} + \text{Metaspace} + \text{DirectMemory} + (\text{ThreadCount} \times 1\text{MB}) + \text{JIT CodeCache} + \text{安全留白}(20\%)\)$

• ActiveProcessorCount 陷阱：JVM 在容器内必须正确感知 CPU limit，显式设置 -XX:ActiveProcessorCount=N，否则将按宿主机核数分配 GC 线程与 ForkJoinPool，引发灾难性线程上下文切换与 CPU throttling。
• eBPF 与 Agent 分工：Java Agent 负责业务层方法级耗时剖析；eBPF 负责内核态 TCP 重传、网络丢包与调度延迟诊断，两者互补。

6.1.1.1 Kubernetes 故障证据链：OOMKilled、CrashLoopBackOff 与网络策略

• OOMKilled / Exit 137：137 通常表示被 SIGKILL 终止，不能仅凭退出码断定是 cgroup OOM；检查 Pod lastState、Events、容器/节点内存、cgroup memory.events、内核日志与 JVM heap/Native/Direct/线程栈指标。
• CrashLoopBackOff：先看 kubectl describe pod、上一次容器日志 kubectl logs --previous、探针失败与退出码，再区分应用启动失败、配置/密钥、依赖不可用、OOM 或 liveness 误杀。
• Service / CNI：核对 EndpointSlice/Ready 状态、kube-proxy 的 iptables/IPVS 模式或集群实际数据面实现、NetworkPolicy、CNI 路由、MTU、DNS 和节点 conntrack。iptables vs IPVS 并非所有现代集群的唯一比较；eBPF 数据面也可能存在。
• NetworkPolicy：只有在所用 CNI 支持并启用策略执行时才生效；检查 ingress/egress 两个方向及 DNS、健康检查和跨 namespace 访问。

6.1.2 Docker/容器内部机制：Namespaces、cgroups、镜像层与网络

上传 PDF 第 30 章（目录标注页 279–283）包含 SaaS/PaaS/IaaS、Docker、Namespaces、cgroups、网络隔离、UnionFS/存储驱动和 OpenStack。报告已有 Kubernetes 生产排障，本节补齐容器底层概念，重点关注 Java 服务为什么会在容器内发生 CPU/内存与宿主机认知不一致。

表 101：容器基础设施与 Java 服务运行边界

6.1.2.1 cgroups、CPU 限额与容器安全落地

Namespaces 提供进程、挂载、网络等隔离视图；cgroups 限制与统计 CPU、内存和 I/O。容器不是独立内核，资源限制、权限、Capabilities、seccomp、AppArmor/SELinux 和宿主机共享内核共同决定安全边界。

• CPU limit 导致 throttling 时，即使宿主机总体 CPU 看起来有空闲，容器也可能受到配额限制；结合 cpu.stat、throttled periods 与应用 P99 看。
• 内存限制需要包含 heap、Metaspace、线程栈、Direct Buffer、JNI/native、页缓存等；仅设置 -Xmx 不足以保证容器不被 OOMKill。
• 生产镜像优先非 root、只读根文件系统、最小 Capability、固定/扫描依赖、可信来源和及时补丁；写目录显式挂载临时卷。

6.1.3 日志门面、日志实现与 ELK/集中式日志治理

上传 PDF 第 10 章（目录标注页 169–170）罗列 SLF4J、Log4j、Logback 与 ELK。现代复习需要区分 API 门面、具体日志实现、采集/索引平台，并把日志作为可观测性证据链而不是单纯文本输出。

表 102：日志生态与生产治理

6.1.3.1 异步日志队列、MDC 与 OpenTelemetry 统一观测

• 日志门面：SLF4J 定义 API，Logback/Log4j2 等提供实现；排查依赖冲突时检查重复 binding/provider，避免桥接环造成循环依赖。
• 异步日志：队列满时策略可能是阻塞、丢弃或回退到同步写；要根据日志等级/类别明确策略，观测队列深度、丢弃计数、磁盘延迟和滚动失败。
• 关联上下文：MDC/traceId 需要在执行线程、异步任务与消息消费边界传播并在 finally 清理，避免线程池复用导致上下文污染；不要记录密码、Token、密钥或整段敏感请求体。
• OpenTelemetry：统一 traces/metrics/logs 的语义与上下文关联；控制高基数标签、采样率与保留期，避免可观测成本和指标基数失控。

6.2 CI/CD、GitOps 与现代发布工程

表 46：GitOps 深入与现代发布模式对比

• 扩展—迁移—收缩（Expand-Contract）发布模式： 解决发布回滚中“代码可回滚，但已执行的破坏性数据库变更不可回滚”的问题：
  1. Expand（扩展）：新增列或表，但旧列保持原样，应用发布新版本兼顾双写；
  2. Migrate（迁移）：历史数据后台批量回填；
  3. Contract（收缩）：确认旧版本完全下线无依赖后，另起迭代删除废弃列。

6.2.1 GitOps、金丝雀发布与自动回滚闭环

GitOps 以版本控制中的声明式期望状态为变更入口；控制器持续对账并执行部署。CI 负责构建、测试、供应链验证和制品签名，CD/GitOps 负责将已批准的制品按环境逐步交付，二者边界需要清晰。

• 发布策略：蓝绿关注两套环境切换；金丝雀按比例/标签逐步放量；滚动发布控制新旧副本替换节奏。策略选择由兼容性、状态迁移、会话和数据层约束决定。
• 自动分析：定义错误率、P95/P99、资源使用、业务转化、队列积压等指标阈值和最短观察窗；避免流量太少或业务周期不同造成误判。
• 回滚约束：应用镜像可回滚不代表数据库可回滚。Schema 变更使用 Expand–Contract，消息格式向后兼容；对不可逆数据变化准备向前修复脚本与快照。
• Git 分支：Trunk-Based 可减少长期分支集成成本；GitFlow 适合某些版本发布节奏，但会增加分支同步负担。不能只凭流行度决定，需匹配团队交付频率。

6.3 大数据栈

表 21：大数据栈复习条目

6.3.1 Hadoop：HDFS、MapReduce 与 YARN 的职责划分

上传 PDF 第 25、28 章（目录标注页 259–262、275–277）介绍 HDFS、MapReduce 和 YARN。需要特别纠正一个常见的年代混淆：JobTracker/TaskTracker 属于 Hadoop 1.x 的经典架构；在 Hadoop 2.x 及后续 YARN 架构中，资源管理拆分为 ResourceManager、NodeManager 与每个应用的 ApplicationMaster。

表 103：Hadoop 组件与现代架构边界

6.3.1.1 HDFS 检查点、MapReduce 与 YARN 调度链

• HDFS：NameNode 管理文件系统元数据，DataNode 存储 Block；FSImage 保存元数据快照、EditLog 记录后续修改，Checkpoint 合并两者以控制恢复时的重放长度。Checkpoint 不是简单等同于 NameNode 高可用。
• 块与副本：副本放置、Rack Awareness、DataNode 心跳/块报告和重新复制共同影响容错；需区分单个 Block 丢失与整个节点/机架故障。
• MapReduce：Map 输出按分区排序并经 Shuffle/Reduce 聚合；数据倾斜、spill、合并和网络读写可能成为瓶颈。
• YARN：ResourceManager 负责资源调度，NodeManager 管理节点容器，ApplicationMaster 管理单个应用执行；Container 表示资源分配，不等同于 Docker 容器。

6.3.2 Spark：RDD、DAG、Stage、Task 与 Shuffle

上传 PDF 第 26 章（目录标注页 263–268）重点介绍 Spark 组件、运行流程与 RDD。补充时以可用于面试和排障的计算模型为中心，并区分早期 DStream API 与当前更常见的 Structured Streaming。

表 104：Spark 计算模型与性能诊断

6.3.2.1 Spark 数据倾斜、Shuffle 与状态诊断

• 窄依赖可在同一 Stage 内流水化；宽依赖通常需要 Shuffle，产生网络传输、排序/聚合、磁盘 spill 和序列化开销。
• 定位倾斜先看各 Task 输入行数、运行时长、Shuffle Read/Write、spill、GC 与 executor lost；一个长尾 Task 经常比增加 Executor 数更重要。
• 缓解方法包括 key salting、局部聚合、倾斜 join 优化、合理分区、广播小表与 AQE（能力需按 Spark 版本/SQL 执行模式确认）。
• RDD cache/persist 与 checkpoint 作用不同：缓存可减少重复计算；checkpoint 截断 lineage 并持久化恢复边界，代价是额外存储与物化过程。

6.3.3 Storm、Spark Streaming 与 Flink：流处理模型和选型

上传 PDF 第 27 章（目录标注页 269–274）整理 Storm 的 Nimbus、Supervisor、Worker、Spout/Bolt 与 Stream Grouping；报告已有 Flink 与 Spark 概览。本节将历史流处理模型放在同一张表中，避免把不同引擎的“实时”定义混为一谈。

表 105：流处理引擎的模型对照

6.3.3.1 Flink Checkpoint、状态后端与端到端一致性

• Checkpoint：Flink 在 Source/算子状态中建立一致性快照；Barrier 与算子状态协调，具体对齐/非对齐模式取决于配置与版本。
• Exactly-once 边界：Checkpoint 保证状态恢复语义，不自动保证任意外部 Sink 的 exactly-once。外部系统需事务提交、幂等写、两阶段提交或可恢复提交协议。
• 状态后端：内存/文件/嵌入式 RocksDB 等实现的延迟、内存、磁盘与恢复性能不同；调优需看状态大小、访问模式、增量 checkpoint、写放大和恢复时间。
• 事件时间：Watermark 表示系统对事件时间进度的估计；延迟事件、allowed lateness、窗口清理与状态 TTL 会影响结果正确性与资源占用。

6.4 Java AI 栈与企业级落地工程化

表 22：Java AI 栈复习条目

6.4.1 Spring AI 的三层抽象与 Advisor 执行顺序（表 32）

6.4.2 企业级大模型 API 接入治理与成本控制

• 设置连接超时与首包读取超时；流式传输（SSE）结合客户端断开信号主动 cancel 上游模型请求。
• 输入输出设置 max_tokens 强上限；结构化输出校验（JSON Schema），输出非法时走规则引擎降级，绝不盲目重试。

6.4.2.1 SSE 背压、配额预算与模型路由策略

• 客户端断开时传播 cancellation，关闭上游流并释放连接；设置首 Token 超时、总超时、空闲流超时和最大输出 Token，不将每次流式请求当成无限长连接。
• 对供应商按并发、RPM/TPM、模型上下文长度和成本做限额；以 tenant/user/model 维度控制配额，避免单租户耗尽共享预算。
• 模型路由要使用经过评测的能力/成本/延迟矩阵，并处理不支持的参数、JSON 模式差异、内容策略和工具调用格式；降级模型应有质量门槛。
• 重试仅限可安全重试的失败，并对已发出部分输出的流式响应谨慎处理；重试前必须确认不会重复执行工具副作用。

6.4.3 RAG 检索增强系统架构与数据治理

• 采用父子文档切块（Parent-Document Retriever）；混合检索（BM25 关键词 + 向量 Dense）；后置 Reranker 模型重排。
• 权限安全预过滤（Pre-filtering）：必须在向量检索阶段前置过滤权限，严禁全量召回后再到内存过滤，防止模型上下文被越权注入未授权数据。

6.4.3.1 RAG 文档版本、权限过滤与评测边界

• 数据流水线需记录原文来源、版本、租户、权限、时间戳、解析器/分块配置和 Embedding 模型版本；变更后按版本增量重建向量并可回滚。
• 权限过滤尽量在检索前/检索阶段执行，模型上下文中只应包含当前调用主体有权访问的片段；检索后仍要执行授权检查，不能依赖 Prompt 告诉模型“不要泄露”。
• 同时评估检索 Recall@k、nDCG、上下文 Precision、答案正确性/忠实度、拒答质量、延迟与 Token 成本；LLM-as-judge 需要人工标注样本校准，不能当作绝对真值。
• 对抗测试覆盖越权召回、文档内 Prompt Injection、过期文档、引用不存在、检索空结果与恶意超长输入。

6.4.4 Agent 工具调用与安全边界防范

• 工具白名单 + 参数强制 Bean Validation，严禁模型输出直接拼装为 SQL 或 Shell；
• 用户输入与系统指令严格隔离，高危操作（转账、删除）必须引入人工确认机制（Human-in-the-loop）。

6.4.4.1 Agent 工具调用的权限、沙箱与副作用治理

• 工具 schema 负责结构约束，服务端仍需验证用户身份、租户、对象级权限和业务不变量；模型生成的参数不得被视为可信输入。
• 将只读查询和有副作用的写操作分离，按最小权限授权；删除、付款、发布、外发数据等高风险动作采用人工确认或二次授权。
• 工具执行使用超时、资源限制、命令/URL 白名单、网络出口控制、审计 ID 和幂等键；Shell/SQL 不直接拼接模型字符串。
• Prompt Injection 防护是分层的：检索来源标识、指令与数据分离、工具权限、输出校验、沙箱和人工审批不可由单一 Prompt 规则替代。

6.4.5 AI 应用评测指标与质量回归闭环

建立专属固定基准评测集，围绕事实正确性、上下文相关性、无幻觉率（Faithfulness）、答案完整性四大维度自动化回归。

6.4.5.1 AI 应用评测集、回归与可复现性

建立固定基准集与真实失败样本集，记录输入、检索上下文、Prompt/工具版本、模型供应商与参数、输出、人工标签和评测器版本。每次更改分块、Embedding、Reranker、Prompt、工具定义或模型路由后进行回归，报告质量、延迟、失败率及成本。安全测试集需覆盖越权、提示注入、工具滥用、PII 泄露和不安全输出。评测分数必须结合人工抽检、业务指标和置信区间解读；不能仅凭一项“Faithfulness”分数声称质量达标。

6.4.6 模型上下文协议（MCP）架构规范

截至 2026-10-27，MCP（Model Context Protocol，模型上下文协议）的当前公开规范版本为 2026-07-28。该版本强调无状态协议核心和按请求携带元数据的自描述请求，移除旧版协议级 initialize/initialized 握手与 Mcp-Session-Id；协议版本、客户端身份和客户端能力通过请求元数据携带，客户端如需预先查询服务端能力，可调用 server/discover，该发现调用并非每次请求的强制前置步骤。变更通知改用客户端按类型选择订阅的 subscriptions/listen 流机制，Tasks 位于可选扩展中。客户端与 SDK 的实际支持情况仍需按协议版本/兼容矩阵核对，不能把旧版会话模型写成所有实现的固定前提。

表 61：MCP 协议架构与通信机制

6.4.6.1 MCP 能力发现、授权与审计边界

• 区分 Host 的策略与会话编排、Client 的协议调用和 Server 暴露的工具/资源/提示能力；协议能力发现并不等于获准调用所有工具。
• 服务端每次工具执行都要重新验证权限、租户、参数和业务状态；工具列表/描述不能作为授权机制。
• 传输层认证、授权范围、工具级审计、超时、幂等、速率限制、输出大小限制和错误脱敏需要由系统实施。对执行命令、写库、发消息等副作用工具，必须提供明确审批和回滚设计。
• 协议版本和 SDK 功能演进快；实现前应锁定兼容版本并核对对应官方规范，不把某一日期的协议细节当成永久不变。

6.4.7 向量语义缓存（Semantic Caching）降本提速架构

传统 String Key 缓存只能命中规范化后完全相同的键；问题改写、同义表达可能降低命中率，但不能据此说它对大模型调用“几乎失效”。语义缓存（Semantic Cache）通过向量相似度等方式复用语义接近的请求，实际收益取决于重复问题比例、相似度阈值、Embedding 与向量检索成本、模型价格及误命中风险，不应预设固定的 50%~70% 降本比例。

用户提问
  → 文本规范化/权限上下文提取
  → Embedding 向量化
  → 按 tenant_id / 数据权限前置过滤后检索向量缓存
  → 依据离线标注集、误命中风险与在线反馈校准的阈值判断
      ├── 命中：返回历史应答（仍有 Embedding、向量检索与网络开销）
      └── 未命中：调用大模型 API → 校验结果 → 异步写入缓存

说明：相似度阈值是示意策略，不是固定标准；命中率、延迟与降本效果必须按真实问题分布实测。

适用边界： 对实时余额、订单状态、权限敏感与强时效数据跳过语义缓存。多租户检索必须在向量查询阶段前置 tenant_id/权限过滤；Prompt 指令不能替代授权。

• 核心治理边界：对于高时效性业务（如查询实时账户余额）必须跳过语义缓存；对多租户数据必须在向量检索中前置强制过滤 tenant_id，防止越权读取他人的问答缓存。

6.4.8 经典机器学习算法地图：Java 工程师需要掌握到什么程度

上传 PDF 第 29 章（目录标注页 278）列出决策树、随机森林、逻辑回归、SVM、朴素贝叶斯、KNN、K-Means、AdaBoost、神经网络与马尔可夫模型。对于以企业应用为主的 Java 工程师，这部分通常属于 P2：理解任务类型、数据需求和结果评估，比手写训练算法更重要，除非目标岗位明确要求算法研发。

表 106：经典模型家族的任务与边界

6.4.9 Prompt Caching、Structured Outputs 与有状态 Graph Workflow

生产级 AI 应用除了模型调用本身，还要控制可重复输入的成本、输出契约与多步工作流状态。三者分别解决“重复前缀是否可复用”“模型结果能否按契约被下游安全消费”“多步工具执行如何可控恢复”的问题，不应混为一类缓存或一个 Agent 循环。

AI 的成本优化必须以真实账单与评测集为证据。Prompt Cache 命中不代表语义正确；结构化输出不代表业务正确；状态图能提高流程可控性，但不替代幂等、权限校验和补偿设计。

6.5 SRE、全链路压测与生产事故闭环

表 35：监控指标设计与告警策略

6.5.1 性能调优方法论四步法（表 54）

1. 建立基线（Baseline） ：量化压测下的 QPS、TPS、P50/P99 延迟及系统资源饱和度指标。
2. 全链路剖析（Profile） ：利用 SkyWalking、Arthas、JFR、iostat 定位瓶颈，拒绝盲目猜测。
3. 优化实施（Optimize）   ：算法改善、锁细化、批量化、读写分离、参数收敛。
4. 验证回归（Verify）     ：对比优化前后指标，确保 P99 改善且系统无内存或连接泄漏。

6.5.2 Linux 生产环境资源排查矩阵与工具链（表 57）

6.5.3 生产事故应急响应与复盘准则

• 事故处理原则：先止血后根因（降级、切流、熔断、重启回滚优先）；
• 事故复盘：24~72 小时内组织复盘，产出系统性改进项（Action Items），落实负责人与完成期限。

6.5.3.1 生产事故复盘：时间线、根因与可验证行动项

1. 先止血：明确影响用户、影响功能和业务损失；同步当前状态、下一次更新时间和负责人。
2. 时间线：统一时区与时间源，串联发布、告警、流量、依赖、资源与变更记录；区分触发事件、放大因素和未能阻断故障的控制缺口。
3. 根因分析：不要把“人操作失误”作为终点，继续追问为什么流程允许错误动作、为何监控没提前暴露、为何演练/权限/回滚不能防住。
4. 行动项：每项要有负责人、截止日期、验证指标与复查时间；按风险优先级处理架构、测试、告警和手册，不把所有问题都变成“增加监控”。

6.5.4 Linux 操作系统经典面试题与排障

PDai 与《成神之路》的知识图谱都把 Linux 命令、进程/线程、虚拟内存和性能定位视为 Java 工程师的底层能力。本节与 6.5.2 的工具矩阵配合，补齐常见操作系统语义与生产误区。

表 88：Linux/操作系统基础与生产排障

6.6 混沌工程（表 47）

• 核心原则：建立稳态假设，在生产或预发环境主动注入故障验证系统弹性（如随机 Kill 实例、注入网络丢包延迟、时钟回拨），检验容灾自愈与熔断配置的有效性。工具采用 Chaos Mesh 或 Chaos Blade。

6.6.1 混沌工程：假设、爆炸半径与停止条件

• 先定义稳态假设和可观测指标，例如成功率、P99、错误预算消耗、复制延迟和恢复时间；演练开始前建立基线。
• 从预发/小流量/单实例开始，逐步扩大 blast radius；使用明确的自动中止条件和负责人，避免为了演练伤害真实业务。
• 故障注入覆盖实例宕机、网络延迟/丢包、依赖限流、磁盘/内存压力、时钟漂移等，但一次只改变有限变量以便归因。
• 通过演练验证检测时间、切换时间、数据一致性、恢复过程是否引起二次过载，以及 Runbook 是否真正可执行。

7. 安全合规、工程质量与跨领域补漏

7.1 构建、依赖与软件供应链治理（表 31）

• Maven 依赖仲裁三大规则：路径最近者优先 \(\to\) 第一声明者优先。排查使用 mvn dependency:tree -Dverbose，版本收敛采用 <dependencyManagement> 或引入标准 BOM。
• 软件供应链安全（SBOM）：CI 流水线强制集成 Trivy/OWASP Dependency-Check 扫描第三方依赖 CVE 漏洞；制品库禁止拉取公网不可信包，禁止 SNAPSHOT 版本上生产。

7.1.1 Git、构建工具、常用库与源码阅读

在已有 Maven 依赖仲裁与供应链治理基础上，补齐经典题库中的 Git 工作流、Maven/Gradle、JSON 库、Lombok/MapStruct 与编译产物排查。这些知识点在资深岗位中常作为工程习惯和线上问题定位的追问。

表 87：开发工具与常用库核心边界

7.1.1.1 SBOM、制品签名与依赖治理闭环

• 依赖锁定与版本收敛：使用 BOM/dependencyManagement、构建锁文件或固定插件版本；通过 dependency tree/SBOM 识别传递依赖和重复版本。
• 漏洞扫描不是全部供应链安全：还应验证来源、制品摘要、签名/证明、构建可复现性、仓库访问控制和发布审批；对例外项记录风险接受人和到期日。
• 应急升级要走兼容性测试、SBOM 差异、集成测试和灰度验证；不要仅因扫描工具报出 CVE 就忽略可达性/修复版本，也不要因“暂不可达”而无限期忽略。

7.2 应用高危漏洞深度防御（SSRF/注入/上传/反序列化）

• SSRF 深度防护体系：严禁仅过滤 localhost。防护必须包含：协议白名单（仅允许 HTTP/HTTPS）、目标 IP 白名单机制、解析 DNS 后校验是否落在回环地址、内网网段（RFC 1918）或云厂商元数据服务（169.254.169.254）、请求重定向二次校验、设置严格读取超时。
• 注入漏洞防御：SQL 全参数化预编译；文件上传严格限制后缀与 MIME-Type，并存储于独立隔离的对象存储（OSS）。

7.2.1 加密、哈希、签名与校验：密码学基础边界

上传 PDF 第 23 章（目录标注页 255–256）列出 AES、RSA、CRC 与 MD5。该列表反映的是经典概念入门，不等于现代安全建议；必须区分加密、完整性校验、消息认证、数字签名与密码存储。

表 107：常见密码学原语及其用途

7.2.2 Web 安全补漏：XXE、命令注入、路径遍历与浏览器安全（表 115）

原报告已覆盖 SSRF、SQL 注入、上传与反序列化。本节结合 JavaGuide Web 安全与认证授权主题，补齐几类常见遗漏；防护应分层执行，不能把输入过滤或 CORS 配置误当作完整授权机制。Web 安全面试题 · 认证与授权面试题。

认证授权补充：Session/Cookie 与 JWT 的状态管理有不同代价；JWT 的 Base64Url 编码不等于加密，签名也不防重放。OAuth 2.0 解决授权，OIDC 叠加身份层；授权码流程应按安全最佳实践使用 PKCE，并严格校验 redirect URI、state、issuer、audience、过期时间与签名算法。

7.3 细粒度权限控制与操作审计（RBAC/ABAC/对象级鉴权）

• 对象级权限校验（BOLA/IDOR 防御）：用户具有访问接口的角色，绝不代表他有权读取任意 orderId。数据访问层必须显式追加当前登录租户与用户维度的属主约束：

SELECT * FROM orders WHERE order_id = :orderId AND user_id = :currentUserId;

• 关键合规审计：对用户敏感数据访问、特权管理员操作全量记录不可篡改的安全审计日志。

7.3.1 数据行级鉴权与审计证据链

• 鉴权至少包含身份、功能权限、对象/数据范围、租户边界和当前业务状态；列表接口、导出、批量操作、异步任务和缓存路径都必须执行同一授权规则。
• 审计记录操作者、对象、动作、授权上下文、结果、traceId、时间与来源；按数据分级做脱敏并限制审计日志自身的读取权限。
• 不可篡改可以通过 append-only 权限、独立存储、哈希链/签名与外部归档组合实现；哈希链只增加篡改可检测性，仍需保护密钥和日志写入主体。

7.4 企业级测试分层与工程防线（表 58）

7.4.1 测试开发进阶：测试替身、属性测试、变异测试与 Flaky Test（表 116）

现有测试章节已有 JUnit 5、Mockito、Testcontainers、ArchUnit、Pact 和压测工具。本节补充面试中容易被忽略的测试策略：测试是否隔离、是否稳定、是否真的能发现缺陷，以及怎样让测试与发布门禁形成闭环。JavaGuide 首页将“测试开发”列为独立面试领域；本节是面向资深后端岗位的通用补充，而不是对无法访问的单篇测试子页作逐字转述。

测试门禁建议：提交阶段运行快速单元/架构测试；合并阶段运行集成与契约测试；发布前运行关键链路回归和性能基线；重大变更前安排压力、容量或故障演练。测试金字塔是成本和反馈速度的指导原则，不代表每个系统必须套用固定比例。

7.4.1.1 属性测试、变异测试与 Flaky Test 治理

• 测试替身：Stub 返回预设结果，Mock 验证交互，Fake 提供可运行的轻量实现；优先验证业务结果与边界，不把内部调用顺序全部锁死。
• 属性测试：定义对大量输入应成立的不变量（例如序列化往返、金额守恒、排序性质、幂等重复调用），由工具生成输入并缩减失败样本。
• 变异测试：故意改变条件/运算符/返回值，验证测试是否能发现真实逻辑破坏；变异存活可能意味着测试断言不足，但也可能是等价变异。
• Flaky Test：分类为时序竞态、共享状态、测试顺序依赖、时钟/随机数、外部网络和资源竞争；重试只能帮助识别，不应把重试通过当成修复。记录失败率、重试命中、耗时和责任人，隔离后设置修复 SLA。

7.5 高频遗漏知识点补充核对（本轮增补）

本报告已覆盖 Java/JVM、并发、Spring、微服务、消息、数据库、缓存、架构、云原生、安全、测试与 AI 等主干。以下内容不代表每个岗位都必须精通，而是对资深 Java 后端岗位常见盲区的补充核对。按目标岗位与生产环境选择深度，避免把技术清单误当成必须全部落地的技术选型。

7.5.1 API 契约、身份认证与授权

• API 契约：OpenAPI/Swagger、请求与响应模型、错误码规范、幂等键、分页约定、兼容性策略、弃用与迁移窗口；区分向后兼容和语义兼容。
• 认证与授权：Cookie/Session、JWT 的签名与过期、OAuth 2.0、OpenID Connect、服务间身份、刷新令牌轮换、密钥轮换、注销与令牌撤销；JWT 不是加密，也不能替代服务端授权。
• 授权模型：RBAC/ABAC 与租户、资源、操作三级校验；防止越权访问、IDOR/BOLA；批量接口、导出接口和异步任务同样需要授权校验。
• 限流与滥用防护：按用户、租户、接口和下游维度设置配额；区分限流、并发隔离、熔断与负载 shedding，明确 429/Retry-After 行为。

7.5.2 构建、交付与代码维护

• Maven/Gradle：依赖传递、依赖仲裁、BOM、插件生命周期、可重复构建、版本锁定、私服与离线构建；能通过 dependency tree 定位版本冲突。
• Git 工程：rebase/merge、冲突解决、cherry-pick、revert、bisect、tag 与发布分支；理解回滚提交与回滚数据库变更不是一回事。
• 代码质量：静态分析、格式化、覆盖率、复杂度、重复代码、架构测试、代码评审清单；测试覆盖率不能单独代表测试有效性。
• 制品与发布：制品不可变、镜像标签与摘要、SBOM、签名与来源证明、依赖漏洞扫描、配置与密钥分离、发布审批与审计记录。

7.5.3 数据库与数据工程的边界能力

• SQL 进阶：窗口函数、CTE、执行计划估算误差、统计信息、锁等待与死锁诊断、批量写入、在线 DDL、字符集与排序规则；能结合实际数据库版本解释差异。
• 数据库多样性：若目标公司使用 Oracle/PostgreSQL，补齐其事务、索引、执行计划、序列/自增、锁、JSON 能力和迁移工具差异；不要把 MySQL 的行为直接套用到其他数据库。
• 数据一致性：CDC、增量同步、全量校验、数据修复、重复与乱序事件处理、删除传播、对账任务和数据血缘；同步链路必须设计断点续传与可观测性。
• 对象存储与文件：预签名 URL、分片上传、断点续传、内容哈希、病毒扫描、文件元数据、生命周期策略、访问控制及大文件下载的带宽治理。

7.5.4 分布式系统的工程细节

• 时间与顺序：墙上时钟与单调时钟区别、时钟漂移、时区、时间戳精度、事件时间与处理时间；不要仅凭客户端时间戳判定全局顺序。
• 租约与 fencing token：分布式锁过期后旧持有者可能继续执行；对关键写入使用递增 fencing token 或由数据库条件更新等机制阻止过期持有者覆盖新结果。
• 一致性与读写路径：读己之写、单调读、最终一致性、缓存/副本延迟、故障切换后的陈旧数据；为关键业务定义可接受的一致性等级。
• 容量与背压：队列长度、最大并发、连接池、线程池、数据库连接和下游配额要联合估算；队列不是无限缓冲，积压必须有上限、告警与降级策略。
• 数据修复：对账、补偿、重放、死信处理、人工介入和审计轨迹要形成闭环；重放必须具备幂等与速率控制。

7.5.5 可观测性与生产运维

• 日志、指标、链路：统一 traceId/correlationId、结构化日志、指标标签基数治理、采样策略、敏感字段脱敏和跨服务上下文传播。
• 告警工程：基于用户影响与 SLO 的告警、告警分级、抑制与聚合、值班升级；避免只监控 CPU/内存而忽略错误率、延迟和饱和度。
• SLO/SLI/Error Budget：定义可量化的可用性与延迟目标，区分平均值与 P95/P99；用错误预算影响发布节奏与稳定性投入。
• 容量规划：压测模型、峰值与突发系数、冷热路径、资源利用率、扩容提前量和成本；压测数据应记录版本、数据规模、硬件、流量模型与瓶颈。

7.5.6 安全与合规的补充项

• 密码学基础：TLS、证书链、证书轮换、哈希与 HMAC、对称/非对称加密、随机数、密码存储与密钥管理；不自行设计密码算法。
• 常见 Web 风险：CSRF、XSS、CORS 误配、请求走私、路径穿越、开放重定向、SSRF、依赖供应链风险；CORS 不是服务端授权机制。
• 隐私与数据治理：数据分级、最小化采集、脱敏、保留期限、删除请求、审计、备份中的敏感数据和跨境/行业合规要求；具体义务以适用法律和公司政策为准。
• 密钥与配置：禁止把密码、Token、私钥写入代码仓库或日志；支持轮换、最小权限、短期凭证和泄露后的吊销流程。

7.5.7 资深岗位的系统设计与沟通交付

• 需求与非功能指标：先澄清业务边界、流量、数据规模、延迟、可用性、RPO/RTO、合规、预算与团队能力，再提出方案。
• 架构决策：明确备选方案、约束、风险、迁移成本、回滚策略与验证指标；用 ADR 记录决策及重新评估触发条件。
• 技术债治理：债务登记、风险分级、业务影响、偿还成本、负责人和验收标准；避免只用“重构更优雅”作为投入理由。
• 项目交付：拆分里程碑、跨团队依赖、上线准入、灰度指标、回滚演练、运行手册、交接与复盘；将个人贡献与团队成果区分清楚。

7.6 第二轮遗漏点与生产落地核对

本节是面向资深后端岗位的横向补漏，不要求把所有方案都引入项目。复习时应能解释适用条件、失败模式、观测指标、回滚办法，并用真实项目案例说明取舍。

7.6.1 服务治理与故障隔离

• 超时预算：为入口、业务服务、数据库、缓存和下游 RPC 分配总耗时预算；超时应向下游传播，避免每一层都设置独立且过长的超时。
• 隔离与降级：区分连接池隔离、线程池隔离、舱壁、限流、熔断与降级；明确熔断恢复探测、半开状态、降级数据时效和恢复策略。
• 优雅停机：先摘除流量，再停止接收新请求，等待在途请求和消息处理完成，最后关闭线程池、连接池与客户端；要处理容器终止宽限期和强杀边界。
• 配置与功能开关：区分静态配置、动态配置、密钥与 Feature Flag；配置变更需校验、审计、灰度、回滚，功能开关要有负责人和清理期限。

7.6.2 数据演进与后台任务

• 在线 Schema 变更：掌握 expand–migrate–contract：先兼容性扩展，再双读/双写或回填验证，最后移除旧字段；应用发布与数据库变更必须能错峰兼容。
• 批处理与回填：设计可暂停、可续跑、可限速、可幂等的批任务；记录游标/检查点，控制锁与数据库负载，支持失败重试、差异核对和人工纠偏。
• 数据对账与修复：区分在线事务正确性和离线对账兜底；为订单、支付、库存、账务等关键链路定义不变量、差异发现时限、修复权限与审计记录。
• 文件与对象存储：理解分片上传、断点续传、校验和、临时凭证、对象生命周期、病毒扫描、下载授权和删除一致性；不要把大文件直接塞入应用内存或数据库事务。

7.6.3 多租户与数据边界

• 租户隔离：比较独立实例/独立数据库/共享库共享表等模式，明确 tenant_id 的强制注入、唯一约束、缓存键、异步消息上下文与后台任务隔离。
• 对象级授权：不只验证“用户有某个角色”，还要验证其对当前租户、当前资源和当前操作的权限；防止通过猜测 ID 访问其他用户数据。
• 数据生命周期：定义数据分类、保留期限、归档、删除、导出、脱敏、审计与备份中的敏感数据处理；删除请求需考虑缓存、搜索索引、对象存储和下游副本。

7.6.4 容量、成本与发布治理

• 容量估算：从峰值 QPS、请求放大倍数、平均/尾延迟、并发数、单请求 CPU/内存、连接数和数据增长推算容量，并通过压测校准假设。
• 成本可观测性：除 CPU/内存外，跟踪数据库连接、缓存内存、消息积压、日志/链路采样、对象存储、跨区流量和 AI Token 等主要成本驱动因素。
• 发布兼容性：验证滚动发布期间新旧版本共存时的 API、消息格式、缓存结构和数据库 Schema 兼容性；明确灰度指标、自动停止条件、回滚限制与回滚后数据处理。
• 供应链完整性：将依赖锁定、制品不可变、构建来源、SBOM、漏洞扫描、制品签名与部署身份串成可审计链路；生产环境尽量只部署经过验证的构建产物。

7.6.5 架构选型与领域建模

• 模块化单体与微服务：能说明什么时候先用模块化单体、什么时候拆分服务；拆分依据应包括团队边界、独立扩缩容、发布频率、故障隔离和数据所有权，而非只看代码规模。
• 读写模型与查询边界：了解 CQRS 的收益与复杂度，识别跨聚合查询、报表、搜索索引和缓存是否应走独立读模型；不要为“使用 DDD”而机械引入 CQRS/Event Sourcing。
• 外部系统集成：为第三方 API 设计连接/读取超时、限流、幂等、签名验签、重放保护、错误分类、对账补偿和供应商故障降级。

8. 非技术栈要求（简要）

资深岗位通常对标工程师、架构师、技术专家或研发负责人。技术判断必须能转化为业务结果，同时具备清晰沟通、跨团队协作和交付闭环能力：

1. 商业洞察与 ROI： 用业务语言说明技术改造对成本、转化率、风险、交付周期或服务器资源的影响；区分可测量结果与估算假设。
2. 需求澄清与非功能指标： 在方案设计前确认业务边界、用户影响、峰值流量、延迟、可用性、数据保留、合规、预算与团队能力；将模糊目标转化为可验证的验收指标。
3. 技术沟通与跨团队推动： 用 ADR、设计评审、RFC、接口契约和风险清单达成共识；能够解释技术债与取舍，而非只推动个人偏好的技术方案。
4. 人才培养与团队梯队： 通过代码评审、导师机制、故障复盘与技术分享提升团队能力。70/20/10 等比例只能作为特定团队讨论资源投入的起点，不是普适管理公式。
5. 技术攻坚与事故沟通： 重大故障中先同步影响面、止血动作、责任人与下一次更新时间；事后形成可验证的改进项，避免只归因于个人失误。
6. 技术影响力与交付责任： 主导 ADR 落地、疑难故障闭环、技术路线图和技术债治理；用上线质量、SLO、成本与业务结果证明影响力。

9. 可执行复习清单

表 24：P0 栈打勾清单（26 项）