Reference

JVM 总览

JVM 是 Java 程序的运行环境，负责把字节码加载到内存中，通过解释执行或 JIT 编译运行，同时管理内存、线程、垃圾回收和运行时安全。

核心组成

内存模型

运行时内存结构

堆内存分代

• 新生代：大多数对象朝生夕死，通常分为 Eden、Survivor From、Survivor To。
• 老年代：长期存活对象、大对象或经历多次 Minor GC 后晋升的对象。
• 元空间：JDK 8 后替代永久代，使用本地内存，主要存储类元数据。

Java 内存模型 JMM

JMM 不是 JVM 运行时内存区域，而是 Java 并发语义规范，定义线程如何通过主内存和工作内存交互，解决可见性、有序性和原子性问题。

• 原子性：基本读写通常具备原子性，复合操作如 i++ 不具备原子性。
• 可见性：一个线程修改共享变量后，其他线程能否及时看到。volatile、锁、final 可提供可见性保障。
• 有序性：编译器和 CPU 可能重排序，JMM 通过 happens-before 规则约束可观察结果。

垃圾回收与调优

对象是否存活

• 引用计数法：实现简单，但无法解决循环引用，JVM 主流 GC 不采用它作为核心判断方式。
• 可达性分析：从 GC Roots 出发，能被引用链到达的对象是存活对象，否则可回收。

常见 GC Roots

• 虚拟机栈中引用的对象，例如局部变量。
• 方法区中类静态属性引用的对象。
• 方法区中常量引用的对象。
• 本地方法栈中 JNI 引用的对象。
• 被同步锁持有的对象。

垃圾回收算法

常见垃圾回收器

• Serial：单线程，简单稳定，适合客户端或小内存场景。
• Parallel：吞吐量优先，适合批处理、计算任务。
• CMS：低停顿老年代回收器，存在内存碎片问题，已逐步淘汰。
• G1：面向服务端的低停顿收集器，把堆划分为多个 Region，可预测停顿时间。
• ZGC / Shenandoah：面向超低停顿和大堆场景，停顿时间通常非常短。

调优思路

1. 先明确目标：降低停顿、提升吞吐、减少 OOM，还是稳定响应时间。
2. 收集证据：开启 GC 日志，结合监控、堆转储、线程栈分析。
3. 判断问题类型：内存泄漏、对象创建过快、晋升失败、元空间不足、Full GC 频繁。
4. 再调参数：堆大小、年轻代比例、GC 器选择、停顿目标、元空间上限。
5. 压测验证：调优必须用真实流量模型或压测结果闭环。

常用参数

-Xms2g -Xmx2g
-XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m
-XX:+UseG1GC
-XX:MaxGCPauseMillis=200
-Xlog:gc*:file=gc.log:time,uptime,level,tags

类加载机制

类加载过程

1. 加载：通过类的全限定名获取二进制字节流，转成方法区运行时数据结构，并在堆中生成 Class 对象。
2. 验证：确保字节码符合 JVM 规范，不危害虚拟机安全。
3. 准备：为类变量分配内存并设置默认初始值。
4. 解析：把常量池中的符号引用转换为直接引用。
5. 初始化：执行类构造器 <clinit>()，给静态变量赋代码中定义的值，执行静态代码块。
6. 使用：程序正常访问类和对象。
7. 卸载：类加载器可回收、类无实例、Class 对象无引用时，类才可能被卸载。

双亲委派模型

类加载器收到加载请求后，先委托父加载器尝试加载，父加载器无法加载时，子加载器才自己加载。

• Bootstrap ClassLoader：加载 Java 核心类库。
• Extension / Platform ClassLoader：加载扩展类库，JDK 9 后称 Platform ClassLoader。
• Application ClassLoader：加载应用 classpath 下的类。
• Custom ClassLoader：用户自定义类加载器，常见于热部署、插件化、隔离加载。

双亲委派的好处

• 避免核心类被重复加载。
• 保护 Java 核心 API，防止用户自定义 java.lang.String 等类替换核心类。
• 保证类加载的一致性和安全性。

什么时候会打破双亲委派

• JDBC、JNDI、SPI 等需要父加载器反向使用子加载器加载的实现类。
• Tomcat 等容器需要隔离不同 Web 应用的类。
• OSGi、插件化、热部署场景需要更灵活的类加载策略。

面试回答模板

问题：请你讲一下 JVM 内存结构

问题：线上频繁 Full GC 怎么排查

问题：双亲委派模型是什么，为什么需要它

常见追问

• JMM 和 JVM 内存结构有什么区别？JMM 是并发语义规范，关注可见性、有序性、原子性；JVM 内存结构是运行时数据区划分。
• 为什么新生代适合复制算法？因为新生代对象大多很快死亡，存活对象少，复制成本低且能快速清理整块区域。
• G1 为什么适合低停顿？G1 把堆拆成多个 Region，优先回收收益高的 Region，并可通过停顿目标控制回收节奏。
• 类什么时候初始化？主动使用类时初始化，例如创建实例、访问静态变量、调用静态方法、反射调用、初始化子类前初始化父类。

多线程并发总览

并发编程要解决三类问题：如何创建和管理线程、如何保证共享数据安全、如何提升吞吐并控制资源消耗。生产环境通常用线程池而不是裸建线程，用锁或 CAS 保证一致性，用 JUC 工具类简化协作。

线程状态

• NEW → RUNNABLE → RUNNING / BLOCKED / WAITING / TIMED_WAITING → TERMINATED
• sleep() 不释放锁；wait() 释放锁并进入等待队列。
• yield() 让出 CPU，不保证立刻切换；join() 等待目标线程结束。

线程池

为什么用线程池

• 降低频繁创建/销毁线程的开销。
• 控制并发度，避免线程过多导致上下文切换和 OOM。
• 统一管理任务提交、执行、拒绝和监控。

ThreadPoolExecutor 七大参数

任务提交流程

1. 当前线程数 < corePoolSize → 创建核心线程执行。
2. 否则尝试入队；队列未满则排队。
3. 队列满且线程数 < maximumPoolSize → 创建非核心线程。
4. 否则执行拒绝策略。

常见线程池（Executors 工厂方法）

• newFixedThreadPool：固定大小 + 无界队列，任务堆积时可能 OOM。
• newCachedThreadPool：可扩容 + SynchronousQueue，高并发下线程数可能暴涨。
• newSingleThreadExecutor：单线程顺序执行。
• newScheduledThreadPool：定时/周期任务。

ForkJoinPool

分治任务专用，工作窃取（work-stealing）减少空闲；适合 CPU 密集型、可拆分的大任务，与 Stream 并行流底层相关。

锁机制

synchronized

• 可修饰实例方法、静态方法、代码块；自动加锁解锁，不可中断、不可设置超时。
• JDK 6 后锁升级：无锁 → 偏向锁 → 轻量级锁 → 重量级锁（减少不必要的 OS 互斥）。
• 保证原子性、可见性、有序性（通过 monitor 与内存屏障）。

ReentrantLock

• 基于 AQS 实现，可重入；支持 lockInterruptibly()、tryLock(timeout)。
• 可选公平锁（按申请顺序）或非公平锁（吞吐更高，默认）。
• 需配合 Condition 实现多条件等待，类似多个 wait/notify 队列。

读写锁 ReadWriteLock

读多写少场景：读锁共享、写锁独占，提升读并发。StampedLock 支持乐观读，适合读远多于写。

volatile

• 保证可见性、禁止部分重排序；不保证复合操作原子性（如 i++）。
• 典型场景：状态标志位、双重检查锁中的实例引用发布。

锁对比

死锁四要素与避免

• 互斥、占有且等待、不可抢占、循环等待。
• 避免：固定加锁顺序、tryLock 超时、缩小锁粒度、使用无锁结构。

CAS 与 AQS

CAS（Compare-And-Swap）

比较内存中的值与期望值，相等则更新为新值，是 CPU 原子指令实现的无锁乐观更新。

• 优点：无阻塞、适合低竞争下的高性能计数、栈/队列头尾更新。
• ABA 问题：值从 A→B→A，CAS 仍成功；可用 AtomicStampedReference 带版本号解决。
• 自旋开销：竞争激烈时 CAS 反复失败，CPU 空转，此时锁可能更合适。

常用原子类

• AtomicInteger / AtomicLong：基本类型原子操作。
• AtomicReference：引用原子替换。
• LongAdder：高并发计数，分段累加，比 AtomicLong 竞争小时更快。

AQS（AbstractQueuedSynchronizer）

JUC 锁与同步器的基础框架：state 表示同步状态，CLH 队列管理阻塞线程。

• ReentrantLock、Semaphore、CountDownLatch、ReentrantReadWriteLock 等均基于 AQS。
• 独占模式 vs 共享模式；tryAcquire / tryRelease 由子类实现。

并发面试回答模板

问题：线程池参数怎么设

问题：synchronized 和 ReentrantLock 区别

常见追问

• ThreadLocal 内存泄漏？线程池复用线程时，若未 remove，Entry 的 key 弱引用被回收后 value 仍可能被强引用持有。
• CAS 一定比锁快吗？不一定，高竞争下自旋浪费 CPU，应选锁或 LongAdder 等分段结构。

Lambda 表达式

函数式接口（仅一个抽象方法）的简洁实现，配合方法引用简化代码。

语法要点

• (参数) -> 表达式 或 (参数) -> { 语句; }
• 类型可推断时可省略参数类型；单参数可省略括号。
• 方法引用：类::静态方法、实例::方法、类::实例方法、构造器::new

// 函数式接口
@FunctionalInterface
interface Calculator {
    int calc(int a, int b);
}

Calculator add = (a, b) -> a + b;
List<String> names = Arrays.asList("Tom", "Jerry");
names.forEach(System.out::println);

内置函数式接口

接口默认方法与静态方法

Java 8 允许接口有 default 和 static 方法，便于 API 演进而不破坏实现类。

Stream API

对集合进行声明式、可链式、可并行的数据处理流水线，不存储元素，不修改源（除非明确可变操作）。

操作分类

• 中间操作（惰性）：filter、map、flatMap、distinct、sorted、peek、limit、skip
• 终端操作（触发执行）：forEach、collect、reduce、count、anyMatch、findFirst、min/max

List<User> result = users.stream()
    .filter(u -> u.getAge() >= 18)
    .sorted(Comparator.comparing(User::getName))
    .map(User::getName)
    .distinct()
    .collect(Collectors.toList());

// 分组与统计
Map<String, Long> byDept = users.stream()
    .collect(Collectors.groupingBy(User::getDept, Collectors.counting()));

并行流 parallelStream

• 底层 ForkJoinPool.commonPool()，适合 CPU 密集型、无共享可变状态的任务。
• 避免：IO 密集、小数据量、依赖顺序、涉及 synchronized 或非线程安全集合。

CompletableFuture

Java 8 增强的异步编程模型，支持组合、链式回调和异常处理，弥补 Future 只能阻塞 get 的不足。

常用 API

• supplyAsync / runAsync：异步有返回值 / 无返回值
• thenApply / thenAccept / thenRun：串行依赖上一步结果
• thenCombine / allOf / anyOf：多任务组合
• exceptionally / handle：异常恢复
• orTimeout / completeOnTimeout（Java 9+）：超时控制

CompletableFuture<String> future = CompletableFuture
    .supplyAsync(() -> fetchOrder(), executor)
    .thenApply(order -> enrich(order))
    .exceptionally(ex -> { log.error("fail", ex); return "DEFAULT"; });

// 等待多个任务
CompletableFuture.allOf(f1, f2, f3).join();

与 Future / 回调对比

JDK 17 特性（LTS）

JDK 17 是长期支持版本，生产升级常选 11 → 17。以下为面试高频点。

语言与 API

• 密封类 Sealed Classes：限制谁可以继承/实现，配合模式匹配更清晰建模。
• 模式匹配 instanceof：判断类型同时绑定变量，减少强转样板代码。
• Records：不可变数据载体，自动生成构造器、equals、hashCode、toString。
• 文本块 Text Blocks：多行字符串 """ ... """，保留格式。
• Switch 表达式增强：-> 语法、yield、模式匹配 switch（预览演进中）。

public sealed interface Shape permits Circle, Rect {}
public record Point(int x, int y) {}

if (obj instanceof String s) {
    System.out.println(s.toUpperCase());
}

JVM 与库

• 默认封装更强（强封装 JDK 内部 API），反射访问需 --add-opens。
• 移除 AOT/JIT 实验特性、Applet API、Security Manager 逐步废弃。
• Foreign Function & Memory API（孵化/预览阶段演进）、Vector API 持续迭代。
• macOS/AArch64 等平台支持成熟，ZGC、G1 等 GC 持续优化。

JDK 21 特性（LTS）

JDK 21 是继 17 之后的 LTS，虚拟线程与若干预览特性进入主流面试题。

虚拟线程 Virtual Threads（Project Loom）

• 轻量级线程，由 JVM 调度，适合高并发 IO 密集型（大量阻塞等待）。
• Thread.startVirtualThread(runnable) 或 Executors.newVirtualThreadPerTaskExecutor()
• 不要池化虚拟线程；避免在虚拟线程中执行长时间 CPU 计算或 pin 住载体线程（如 synchronized 内阻塞，JDK 版本持续优化中）。

try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
    IntStream.range(0, 10_000).forEach(i ->
        executor.submit(() -> fetchFromRemote(i)));
}

语言与其它重要特性

• Record Patterns：解构 record，与 switch 模式匹配配合。
• Pattern Matching for switch：正式版，类型模式 + null 处理更完整。
• Sequenced Collections：统一首尾访问 API（getFirst、getLast、reversed）。
• String Templates（预览）：更安全、可扩展的字符串插值。
• Generational ZGC：分代 ZGC 降低开销，改善吞吐与停顿。
• Key Encapsulation Mechanism API：后量子密码相关标准 API。

17 → 21 选型简述

现代 Java 面试回答模板

问题：Stream 和 for 循环怎么选

问题：CompletableFuture 如何避免线程池耗尽

问题：虚拟线程适合什么场景

常见追问

• Lambda 捕获的变量为什么必须是 effectively final？避免并发语义下闭包内外状态不一致，简化实现。
• Record 和 Lombok @Data 区别？Record 是语言级不可变语义，语义更清晰；Lombok 是编译期生成样板代码的普通类。
• JDK 17 和 21 为什么都标 LTS？Oracle 每两年一个 LTS，17 和 21 都是长期支持节点，企业可按生态成熟度选择。

集合框架体系总览

java.util 集合框架以接口为核心，常用实现类在底层用数组、链表、哈希表或红黑树组织数据。选型时看：是否有序、是否允许重复/null、读写比例、是否并发。

继承关系（面试常画）

• Iterable → Collection → List / Set / Queue
• Map 独立接口，不继承 Collection；entrySet() 可当作 Set 视图操作

选型速查

List 底层实现

ArrayList

• 底层 Object[] elementData，默认初始容量 10（首次 add 时才真正分配）。
• 扩容：容量不足时 grow()，新容量约为 old + (old >> 1)，即约 1.5 倍，再 Arrays.copyOf 拷贝。
• 随机访问 get(i) O(1)；尾部 add 均摊 O(1)；中间插入/删除需数组搬移 O(n)。
• 非线程安全；fail-fast：迭代中结构修改抛 ConcurrentModificationException（modCount 检测）。

LinkedList

• 双向链表，节点含 item、prev、next；同时实现 Deque，可作栈/队列。
• 头尾插入删除 O(1)；按索引访问需遍历 O(n)。
• 内存开销大于 ArrayList（每个元素额外两个引用）。

Vector / Stack

• Vector 方法 synchronized，线程安全但粒度粗、性能差，已被淘汰思路。
• 需要线程安全 List 用 Collections.synchronizedList 或并发集合，而非 Vector。

Set 底层实现

Set 不允许重复元素，HashSet、LinkedHashSet 内部本质是 HashMap（或 LinkedHashMap），元素存在 key 上，value 是固定占位对象 PRESENT。

HashSet

• 依赖 hashCode() 定位桶，equals() 判断相等；只重写 equals 不重写 hashCode 会破坏契约。
• 无序、允许一个 null（JDK 8+ HashMap 树化后仍支持 null key 的单 null 限制在 HashMap 层）。

LinkedHashSet

• 在 HashSet 基础上维护双向链表记录插入顺序（或访问顺序，构造参数 accessOrder）。
• 略增内存，适合需要稳定遍历顺序的去重场景。

TreeSet

• 底层 TreeMap，红黑树保证有序，增删查 O(log n)。
• 元素需实现 Comparable 或构造时传入 Comparator；不允许 null（比较时会 NPE）。

Map 底层实现

HashMap（JDK 8+）

• 结构：数组（桶）+ 链表；链表长度 ≥ 8 且数组长度 ≥ 64 时链表转红黑树；节点 ≤ 6 时树退化为链表。
• 默认负载因子 0.75：平衡空间与时间，过大则链表/树变长，过小则频繁扩容。
• 容量为 2 的幂：索引 (n - 1) & hash，等价取模且更快。
• hash 扰动：高 16 位与低 16 位异或，减少低位相同导致的冲突。
• put 流程：算索引 → 桶空则放头节点 → 否则比 key（先比 hash 再 equals）→ 冲突则尾插/树插 → 超阈值则 resize。
• resize：容量翻倍，节点要么在原索引，要么在「原索引 + 旧容量」（利用 e.hash & oldCap 分流，JDK 8 优化）。
• 非线程安全；多线程 put 可能死循环（JDK 7 头插扩容）或数据丢失，JDK 8 改为尾插但仍不安全。

// 扰动与寻址（概念）
hash = (key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16);
index = (table.length - 1) & hash;

LinkedHashMap

• 继承 HashMap，额外维护双向链表：after 指针串联顺序。
• accessOrder=false：插入顺序；true：访问顺序，可用于 LRU 缓存（配合 removeEldestEntry）。

TreeMap

• 红黑树按 key 排序；Comparator 或 Comparable 决定顺序。
• 有序、O(log n)，不适合 hash 均匀分布的高吞吐纯查找（HashMap 均摊 O(1) 更优）。

Hashtable

• 方法级 synchronized，不允许 null key/value；遗留类，用 ConcurrentHashMap 替代。

HashMap vs Hashtable vs ConcurrentHashMap

并发集合

ConcurrentHashMap（JDK 8+）

• 取消 Segment 分段锁（JDK 7），改为对每个桶头节点 synchronized + CAS 插入空桶。
• size 用 baseCount + CounterCell[] 分散计数，减少竞争。
• 扩容支持多线程协助转移（ForwardingNode），复杂度高于 HashMap 单线程 resize。
• get 一般无锁（volatile 读可见性）；迭代弱一致性，不抛 CME。

CopyOnWriteArrayList / CopyOnWriteArraySet

• 写时复制：修改时复制新数组再替换引用，读无锁、写成本高。
• 适合读多写极少（白名单、监听器列表）；写频繁或数据量大时内存与复制开销大。

其它

• ConcurrentLinkedQueue：CAS 无界非阻塞队列。
• BlockingQueue 家族：ArrayBlockingQueue（有界数组+一把锁）、LinkedBlockingQueue（可选有界链表）、PriorityBlockingQueue、DelayQueue、SynchronousQueue 等，用于线程池与生产者消费者。

集合面试回答模板

问题：HashMap 底层原理，为什么用红黑树

问题：HashMap 线程不安全体现在哪

问题：ArrayList 和 LinkedList 区别

常见追问

• hashCode 和 equals 契约？相等对象 hash 必须相同；hash 相同对象可不等，故还要 equals。
• 为什么容量是 2 的幂？位运算取模、扩容时 rehash 可优化（JDK 8 高低位分流）。
• Comparable 和 Comparator？前者内置于类，自然排序；后者外部策略，可多种排序规则。
• fail-fast 和 fail-safe？前者迭代中检测 modCount 快速失败；后者（如 COW、CHM 迭代器）弱一致，不保证看到最新且一般不抛 CME。
• 如何用 LinkedHashMap 做 LRU？构造 accessOrder=true，重写 removeEldestEntry 在超过容量时删除最久未访问条目。

SOLID 设计原则

面向对象设计的五条基本原则，目标是降低耦合、提高可维护性与可扩展性。

面试记忆与示例

• S：订单服务只处理订单逻辑，邮件通知拆到 NotificationService。
• O：促销规则用策略接口扩展，而不是在结算里不断加 if (双11)。
• L：正方形不应继承长方形（改一边会破坏另一边语义）；子类不能加强前置、削弱后置条件。
• I：把 Worker 拆成 Workable 与 Eatable，机器人不必实现 eat()。
• D：Service 依赖 UserRepository 接口，由 Spring 注入 UserRepositoryImpl。

创建型模式

关注对象的创建过程，将「如何 new」与业务逻辑解耦。

单例 Singleton

• 保证全局唯一实例：配置中心、连接池管理器、Spring 单例 Bean（容器级）。
• 写法：饿汉、懒汉、静态内部类、枚举（推荐，防反射与序列化破坏）。
• 注意：多 ClassLoader、集群环境下「单例」语义不同；过度使用难测试。

工厂方法 Factory Method

• 定义创建对象的接口，由子类决定实例化哪个具体类。
• 示例：LoggerFactory.getLogger() 按配置返回不同 Logger 实现。

抽象工厂 Abstract Factory

• 创建一族相关/依赖的产品（UI 主题：Button + TextField 成套）。
• 与工厂方法：抽象工厂是「多产品族」，工厂方法是「单产品多实现」。

建造者 Builder

• 分步构建复杂对象，链式调用，参数可选多。
• 示例：Lombok @Builder、StringBuilder、HTTP Request 构建、MyBatis SqlSessionFactoryBuilder。

原型 Prototype

• 通过克隆已有对象创建新对象，避免重复昂贵初始化。
• Java：Cloneable 浅拷贝；深拷贝需手动或序列化。Spring prototype scope 类似思想。

结构型模式

关注类与对象的组合，形成更大结构并保持灵活。

适配器 Adapter

• 将不兼容接口转为客户端期望的接口。
• 类适配器（继承）vs 对象适配器（组合，更常用）。
• 示例：InputStreamReader 把字节流适配为字符流；对接第三方 SDK。

装饰器 Decorator

• 动态给对象添加职责，比继承更灵活，可层层包装。
• 示例：BufferedInputStream 包装 FileInputStream；Collections.synchronizedList。
• 与代理：装饰器侧重「增强功能」，代理侧重「控制访问」。

代理 Proxy

• 为对象提供代理以控制访问、延迟加载、权限、日志、事务。
• 静态代理：手写代理类；JDK 动态代理：基于接口；CGLIB：子类继承，可代理类。
• Spring AOP、MyBatis Mapper、RPC 客户端均为典型应用。

外观 Facade

• 为子系统提供统一简化入口，降低调用复杂度。
• 示例：SLF4J 门面、封装多个微服务调用的聚合 Service。

其它（了解）

• 桥接 Bridge：抽象与实现分离，如消息发送（邮件/短信）× 平台（Windows/Mac）。
• 组合 Composite：树形结构统一对待叶子与容器，如菜单/文件夹。
• 享元 Flyweight：共享细粒度对象，如字符串常量池、棋类游戏棋子状态共享。

行为型模式

关注对象之间的通信、职责分配与算法封装。

策略 Strategy

• 封装一族算法，使它们可互换；消除条件分支。
• 示例：Comparator、支付渠道（微信/支付宝）、路由规则、促销计算。

模板方法 Template Method

• 父类定义算法骨架，子类重写某些步骤（钩子方法）。
• 示例：AbstractList、Servlet service()、JUnit 测试生命周期、Spring JdbcTemplate。

观察者 Observer

• 一对多依赖：主题状态变化时通知所有观察者。
• Java：Observable（已过时）；Spring 事件 ApplicationEvent、MQ 发布订阅、Listener。

责任链 Chain of Responsibility

• 请求沿处理者链传递，直到有人处理。
• 示例：Servlet Filter 链、Netty Pipeline、审批流、日志级别链。

状态 State

• 对象内部状态改变时改变其行为，用类代替大段 switch。
• 示例：订单状态机（待支付→已支付→已发货）、TCP 连接状态。

命令 Command

• 将请求封装为对象，支持撤销、排队、日志。
• 示例：Runnable、事务命令、GUI 宏命令。

常用模式速查表

设计面试回答模板

问题：说说你理解的 SOLID

问题：代理模式在 Spring 里怎么体现

问题：策略模式和 if-else 怎么选

常见追问

• 单例模式线程安全写法？推荐静态内部类或枚举；双重检查锁需 volatile 防指令重排。
• 装饰器和代理区别？意图不同：装饰器扩展功能、可叠加；代理控制访问、常代表真实对象。
• 工厂方法和抽象工厂区别？前者创建一个产品的一种实现；后者创建多个相关产品的一组实现。
• 设计模式是否越多越好？否，过度设计增加复杂度；在变化点使用合适模式即可。

Spring Boot / Cloud 体系总览

Spring Boot 简化单体/微服务应用的启动与配置（自动配置、Starter、内嵌容器）。Spring Cloud 在 Boot 之上提供分布式能力：注册发现、配置中心、负载均衡、熔断限流、网关、链路追踪等。

常见组件对照（面试版）

自动配置原理

启动流程（精简）

1. @SpringBootApplication = @Configuration + @EnableAutoConfiguration + @ComponentScan
2. 运行 SpringApplication.run() → 创建 ApplicationContext（Servlet 环境多为 AnnotationConfigServletWebServerApplicationContext）
3. 加载 application.yml/properties、环境 Profile、Bean 定义
4. 执行各类 *AutoConfiguration，按条件注册 Bean
5. 内嵌 Tomcat/Jetty/Undertow 启动 Web 容器

@EnableAutoConfiguration 做了什么

• 通过 @Import(AutoConfigurationImportSelector.class) 读取 META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports（Boot 2.7+ / 3.x；旧版为 spring.factories）
• 候选配置类经 @ConditionalOnXxx 过滤后生效

常用条件注解

Starter 机制

• Starter = 依赖聚合 + 自动配置模块，如 spring-boot-starter-web、spring-boot-starter-data-redis
• 自定义 Starter：autoconfigure 模块 + AutoConfiguration.imports + 配置属性类 @ConfigurationProperties

@Configuration
@ConditionalOnClass(RedisTemplate.class)
@EnableConfigurationProperties(RedisProperties.class)
public class MyRedisAutoConfiguration {
    @Bean
    @ConditionalOnMissingBean
    public RedisTemplate<String, Object> redisTemplate(...) { ... }
}

循环依赖

什么是循环依赖

Bean A 依赖 B，B 又依赖 A（或更长环 A→B→C→A）。Spring 通过三级缓存解决单例 + 字段/Setter 注入场景下的循环依赖。

三级缓存（Singleton）

解决流程（A 依赖 B，B 依赖 A）

1. 创建 A：实例化后放入三级缓存，继续属性注入发现需要 B
2. 创建 B：实例化后放入三级缓存，注入 A 时从三级拿到 A 的早期引用（可能是代理）
3. B 完成初始化，进入一级缓存
4. A 拿到 B，完成初始化，进入一级缓存

无法解决的情况

• 构造器注入循环依赖：实例化前就要 B，无法提前暴露半成品 → 启动失败
• prototype 作用域：每次 new，不参与单例三级缓存
• 多例 + 单例混合环、非 Spring 管理的 new 对象

实践建议

• 优先重构：拆服务、事件驱动、@Lazy 延迟注入（治标）
• 避免构造器环；必要时改用 Setter/字段注入并明确文档
• Spring Boot 2.6+ 默认禁止部分循环依赖行为可配置：spring.main.allow-circular-references=true（不推荐长期依赖）

服务治理

微服务治理关注：服务如何被发现、如何可靠调用、如何限流熔断、如何统一配置与可观测。

注册与发现

• 服务启动时向注册中心（Nacos/Eureka）注册 IP、端口、元数据、健康状态
• 消费者从注册中心拉取/订阅服务列表，结合负载均衡选择实例
• Nacos 同时支持 CP（Raft 持久实例）与 AP（临时实例）模式；Eureka 偏 AP（自我保护）

配置中心

• 配置与代码分离，支持动态刷新（@RefreshScope + Spring Cloud Context）
• 多环境 Namespace/Group、灰度发布、加密配置（Jasypt）

负载均衡与调用

• @LoadBalanced RestTemplate 或 WebClient + LoadBalancer 拦截
• OpenFeign：声明式 HTTP 客户端，集成 LB、熔断、请求压缩；底层常为 HttpClient / OkHttp
• 负载策略：轮询、随机、权重（Nacos 权重）、同 zone 优先等

熔断、限流、降级

• Sentinel：QPS/并发线程数限流、熔断（慢调用比例、异常比例、异常数）、热点参数、系统自适应保护
• 熔断状态：关闭 → 打开（快速失败）→ 半开（探测恢复）
• 降级：返回默认值、缓存、友好提示，保证核心链路可用

其它治理能力

• 分布式事务：Seata（AT/TCC/Saga）、最终一致性（消息表、可靠消息）
• 链路追踪：TraceId 透传，分析慢调用与依赖拓扑
• 服务契约：API 文档（OpenAPI）、版本兼容、消费者驱动契约（可选）

Spring Cloud Gateway

基于 Spring WebFlux + Netty 的响应式 API 网关，统一入口：路由、过滤、限流、鉴权、跨域、灰度。

核心概念

• Route：路由 ID + 目标 URI + Predicate 集合 + Filter 集合
• Predicate：断言匹配请求（Path、Method、Header、Cookie、时间窗口等）
• Filter：Gateway Filter（路由级）与 Global Filter（全局），可改请求/响应

请求链路（简化）

1. 客户端 → Gateway
2. Global Filter 链（如负载均衡、限流、鉴权）
3. 匹配 Route → 执行 Gateway Filter
4. 通过 LoadBalancer 选择下游服务实例 → 转发
5. 响应回传，可统一加 Header、日志、熔断

spring:
  cloud:
    gateway:
      routes:
        - id: order-service
          uri: lb://order-service
          predicates:
            - Path=/api/order/**
          filters:
            - StripPrefix=1
            - name: RequestRateLimiter
              args:
                redis-rate-limiter.replenishRate: 10
                redis-rate-limiter.burstCapacity: 20

Gateway vs Zuul

典型能力实现

• 统一鉴权：Global Filter 校验 JWT，下游信任网关或二次校验
• 灰度发布：根据 Header/用户标签路由到金丝雀实例（结合 Nacos 元数据）
• 限流：RequestRateLimiter + Redis；或与 Sentinel Gateway 适配器集成
• 跨域：Cors WebFilter 或 Gateway 全局 CORS 配置

Spring 面试回答模板

问题：Spring Boot 自动配置原理

问题：Spring 如何解决循环依赖

问题：Gateway 在架构中的作用

常见追问

• @Bean 和 @Component 区别？@Component 是类路径扫描的通用组件；@Bean 是在 @Configuration 里用方法显式注册，适合第三方类。
• Feign 和 RestTemplate？Feign 声明式、可集成熔断与契约；RestTemplate 更底层，需手写 URL 与 LB。
• Nacos 和 Eureka？Nacos 兼具注册与配置；Eureka 仅注册发现，2.x 停更后新项目多选 Nacos/Consul。
• 为什么 Gateway 用 WebFlux？少量线程处理大量 IO 等待，适合网关转发；注意阻塞调用需调度到 boundedElastic 避免阻塞事件循环。

Redis 总览

Redis 是基于内存的 KV 数据库，单线程执行命令（6.0+ 多线程主要处理网络 IO），支持丰富数据结构、持久化、主从复制、哨兵与 Cluster。常用于缓存、会话、排行榜、分布式锁、消息队列等。

为什么快

• 内存读写 + 高效数据结构
• 单线程避免锁竞争（命令仍原子）
• IO 多路复用（epoll）处理大量连接
• 纯内存操作，持久化异步进行

数据结构

五大基础类型

高级 / 扩展类型

• Bitmap：位操作，签到、活跃用户统计（BITCOUNT 需注意大数据耗时）
• HyperLogLog：基数估算（UV），省内存，有误差
• GEO：地理位置，底层 ZSet，附近的人
• Stream：消息流，消费者组，类似轻量 MQ（持久化、ACK、Pending）
• Pub/Sub：发布订阅，不持久化，订阅方离线会丢消息

键与过期

• 过期策略：定期删除 + 惰性删除（访问时检查是否过期）
• 内存淘汰（maxmemory-policy）：noeviction、allkeys-lru、volatile-lru、allkeys-lfu 等
• 生产建议：缓存必须设 TTL；热点 key 注意过期时间打散

持久化

集群与高可用

三种部署形态

Cluster 核心机制

• key → CRC16(key) % 16384 → slot → 负责该 slot 的 master 节点
• MOVED：slot 不在当前节点，客户端应更新槽位映射并重试
• ASK：迁移中的临时重定向
• Hash Tag：{userId}:profile 与 {userId}:order 同 slot，保证事务/Multi 可用
• 最少 3 主 3 从（官方建议），主宕机从节点晋升

复制与一致性

• 主从异步复制：主成功写后返回客户端，再同步从库 → 主宕机可能丢少量已写未同步数据
• wait 命令：可等待 N 个从库确认（慎用，影响延迟）
• 脑裂：网络分区导致多主，需合理配置 min-slaves-to-write 等（版本与方案各异）

缓存问题与解决方案

三大经典问题

缓存与数据库一致性

• Cache Aside（常用）：读先缓存未命中再 DB 并回写；写先更新 DB 再删缓存（推荐删而非立刻更新，避免并发写乱序）
• 延迟双删：删缓存 → 写 DB → 延迟再删一次，降低脏读窗口
• 强一致场景：分布式锁、 Canal/MQ 订阅 binlog 异步删缓存、读主库
• 接受最终一致性时，短 TTL + 主动失效是性价比最高的方案

热点 Key（Hot Key）

• 本地缓存（Caffeine）挡一层；key 拆分（分片到多个 Redis key）
• 读写分离、多副本；大促前预热；监控 QPS 异常 key

大 Key（Big Key）

• 危害：阻塞单线程、迁移慢、内存不均、网卡打满
• 治理：redis-cli --bigkeys、拆分 Hash/List、压缩、异步 UNLINK 删除

分布式锁（常考）

• 基础：SET key uuid NX EX 30，解锁用 Lua 校验 uuid 再 DEL，防误删他人锁
• 问题：主从切换可能导致锁丢失 → Redisson 看门狗续期、Redlock（有争议，生产需评估）
• 强一致锁可考虑 ZooKeeper / etcd；Redis 锁适合允许极低概率重复的业务

// 互斥回源（击穿）伪代码
String v = redis.get(key);
if (v == null) {
    if (redis.setnx(lockKey, "1", "EX", 10)) {
        try {
            v = db.load(key);
            redis.setex(key, ttl, v);
        } finally {
            redis.del(lockKey);
        }
    } else {
        Thread.sleep(50);
        return get(key); // 重试或短暂降级
    }
}

Redis 面试回答模板

问题：Redis 为什么单线程还快

问题：缓存穿透、击穿、雪崩区别与解决

问题：Redis Cluster 如何分片

常见追问

• String 底层 SDS 好处？O(1) 取长度、二进制安全、减少扩容频率。
• ZSet 为什么用跳表？实现简单，范围查询 O(log n)，并发下比红黑树更易实现。
• 先删缓存还是先写库？先写库再删缓存更常见；先删缓存再写库并发下易出现脏缓存。
• Redis 和 Memcached？Redis 多数据结构、持久化、主从集群；Memcached 简单纯缓存、多线程。

消息队列总览

消息队列解耦、异步、削峰填谷。选型常看：吞吐、延迟、顺序、事务消息、运维生态、与现有技术栈契合度。

核心概念对照

RocketMQ vs Kafka 对比

架构差异（简图理解）

• RocketMQ：Producer → Broker（Master/Slave）← NameServer 路由；Consumer 拉取或长轮询 Push 效果
• Kafka：Producer → Broker（Leader/Follower ISR）← Controller/KRaft；Consumer 拉取（poll），消费位点提交

消息可靠性

可靠性 = 消息不丢、不重复（或重复可接受）、可追踪。需从生产 → 存储 → 消费全链路设计。

生产者不丢

• acks=0：不等待确认，可能丢
• acks=1：Leader 写入即返回，Leader 宕机未同步可能丢
• acks=all/-1：ISR 副本都确认，最可靠（需 min.insync.replicas 配合）

Broker 不丢

• RocketMQ：同步刷盘 / 异步刷盘；同步复制 / 异步复制；Master-Slave 故障切换
• Kafka：Partition 多副本 + ISR；replication.factor；unclean.leader.election 关闭可降低丢数据风险
• 磁盘 RAID、监控磁盘使用率与副本滞后（Lag）

消费者不丢

• 先执行业务再提交 offset（或 RocketMQ CONSUME_SUCCESS 后再确认）
• 消费失败：重试队列 + 死信队列（DLQ）人工介入
• 自动提交 offset 可能在处理中途崩溃导致「以为已消费」→ 手动提交更可控

RocketMQ 事务消息流程

1. 发送 Half 消息（对消费者不可见）
2. 执行本地事务
3. Commit → 消息可见；Rollback → 丢弃
4. Broker 回查本地事务状态（超时或未决时）

至少一次 / 至多一次 / 精确一次

幂等设计

MQ 普遍提供 至少一次（At Least Once） 投递，网络重试、Rebalance、消费超时会导致重复消费，业务必须幂等。

幂等层次

• 生产幂等：Kafka enable.idempotence（PID + Sequence）；业务侧用业务 ID 去重表
• 消费幂等：核心，靠唯一键、状态机、数据库唯一约束

常见消费幂等方案

设计要点

• 消息体携带全局唯一 messageId 或 bizId，与业务主键对齐
• 幂等记录与业务写放在同一本地事务，避免「记了幂等但业务失败」
• 消费逻辑本身要可重入：外部调用（支付、发短信）也需幂等或先查状态
• 重试次数与退避策略，最终进 DLQ，防止毒消息无限循环

// 幂等表伪代码
@Transactional
void onMessage(Message msg) {
    if (idempotentRepo.exists(msg.getMessageId())) {
        return; // 已处理
    }
    idempotentRepo.insert(msg.getMessageId()); // 唯一索引防并发
    orderService.createOrder(msg.getBody());
}

MQ 面试回答模板

问题：RocketMQ 和 Kafka 怎么选

问题：如何保证消息不丢

问题：如何处理重复消费

常见追问

• 消息堆积怎么办？扩容 Consumer、增加 Partition/Queue、优化消费逻辑、临时降级非核心消费、排查慢 SQL。
• 顺序消息如何实现？同一 Sharding Key 进同一 Queue/Partition；消费单线程或分区锁。
• 死信队列作用？重试耗尽后隔离毒消息，人工修复或丢弃，保护主队列。
• Rebalance 影响？消费暂停、重复消费风险上升，应控制单次拉取量、优雅下线。

CAP / BASE 理论

CAP（分布式系统三选二）

• C（Consistency）一致性：所有节点同一时刻读到相同数据
• A（Availability）可用性：每个请求都能得到非错误响应（不保证最新）
• P（Partition tolerance）分区容错：网络分区时系统仍能继续工作

分布式环境下网络分区不可避免，因此实际在 CP 与 AP 之间权衡：

BASE（互联网大规模实践）

• BA（Basically Available）基本可用：降级、限流、故障转移，核心功能可用
• S（Soft state）软状态：允许中间状态存在一段时间
• E（Eventually consistent）最终一致性：经过一段时间后达到一致

秒杀活动设计总览

秒杀（Seckill / Flash Sale）是在极短时间、极高并发下，对有限库存商品发起抢购。核心矛盾是： 读多写少、流量远超常态、库存绝不能超卖、用户体验还要可接受。

业务特征

• 流量尖峰：平时 QPS 几十，开场瞬间可到几万～几十万
• 写热点：大量请求争抢同一 SKU 的少量库存
• 失败是常态：库存 1000、请求 10 万，90%+ 用户应快速得到「已抢光」
• 一致性要求高：超卖会引发生产事故；重复下单需幂等

设计总原则

1. 流量层层递减：能挡在 DB 外的绝不进 DB（CDN → 网关 → 缓存 → MQ → DB）
2. 库存扣减原子化：Redis Lua / 条件 UPDATE，禁止「先查后改」
3. 异步削峰：秒杀成功只代表「获得购买资格」，订单异步创建
4. 核心链路隔离：秒杀接口独立集群，与非核心功能舱壁隔离
5. 可降级：评论、推荐、详情富文本等可关；下单链路保活

典型链路（一句话）

用户点击秒杀 → 网关限流 → Redis 校验资格并原子扣库存 → 发 MQ → 异步创建订单 → DB 最终扣减并幂等落库 → 用户轮询/推送「抢购结果」。

流量分层与架构

分层职责

活动页 vs 秒杀接口分离

• 活动页：高读、可缓存，甚至提前生成静态 HTML + 本地倒计时
• 秒杀接口：高写、短路径、少依赖，POST /seckill/{activityId} 独立域名或路径便于限流
• 避免秒杀请求经过重 Filter 链、复杂鉴权 RPC、大 JSON 序列化

「排队 / 令牌」模式（可选）

超大规模场景可在 Redis 预减前增加排队层：

1. 请求进入 → 发放排队 Token（限流窗口内 N 个）
2. 持 Token 才能调真正秒杀接口
3. 无 Token 直接返回「排队中 / 活动太火爆」

本质是用漏桶把突发流量整形后再进 Redis，保护 Lua 脚本与 MQ 不被打满。

架构示意

用户 ──► CDN(静态页) ──► Gateway(限流/验证码)
              │
              └──► Seckill Service ──► Redis(Lua 扣库存)
                        │ 成功
                        └──► MQ ──► Order Consumer ──► MySQL(扣库存+建单)
                        │ 失败
                        └──► 快速返回「已抢光」

库存与防超卖

防超卖是秒杀的底线。多层防御，Redis 挡量，DB 做最终裁决。

Redis 预减库存（Lua 原子）

-- KEYS[1]=stock  ARGV[1]=userId
local stock = tonumber(redis.call('GET', KEYS[1]))
if stock == nil or stock <= 0 then
  return 0  -- 无库存
end
redis.call('DECR', KEYS[1])
redis.call('SADD', 'seckill:users:'..KEYS[2], ARGV[1])  -- 一人一单
return 1

• Lua 在 Redis 单线程执行，判断 + 扣减 + 记录用户 原子完成
• 活动开始前将 DB 库存同步到 Redis；活动中以 Redis 为准快速失败
• 活动结束后以 DB 对账，校准 Redis 与真实库存

数据库最终扣减

UPDATE seckill_stock
SET stock = stock - 1
WHERE activity_id = ? AND sku_id = ? AND stock > 0;
-- 影响行数 = 0 → 超卖防护生效，回滚 Redis 或标记补偿

• 禁止：SELECT stock 再 UPDATE stock = stock-1（并发下必超卖）
• 可用乐观锁 version 字段，但高冲突下性能差，秒杀更常用条件 UPDATE

一人一单 / 防重复

库存预热与一致性

• 预热：活动开始前把库存、价格、规则写入 Redis，避免开场击穿 DB
• 锁定：活动进行中 DB 库存行可标记为「秒杀锁定」，避免与普通订单混扣
• 校准：定时任务对比 Redis 剩余与 DB；MQ 消费失败时 Redis 回滚或人工对账
• 超卖兜底：DB 扣减失败 → 发补偿消息 / 取消 Redis 占位 / 通知用户「抢购失败」

异步下单与一致性

同步链路只做「资格判定 + 扣 Redis 库存 + 投递 MQ」，订单创建、支付、库存落库全部异步。

为什么用 MQ

• 把峰值写压力从 HTTP 线程转移到 Consumer，Consumer 按 DB 能力消费
• HTTP 快速返回「排队处理中 / 抢购成功待确认」，避免长连接拖死 Tomcat 线程
• 失败可重试、死信隔离，不丢单

消息体设计

{
  "messageId": "uuid",           // 全局幂等
  "activityId": 1001,
  "userId": 2002,
  "skuId": 3003,
  "seckillTime": 1710000000,
  "token": "redis扣减凭证"       // 可选，用于对账
}

消费端流程

1. 幂等检查：messageId 或 userId+activityId 是否已处理
2. DB 条件扣库存（最终防线）
3. 创建订单（待支付），写入秒杀记录表
4. ACK 消息；失败重试，超限进 DLQ

用户如何知道结果

与支付链路

• 秒杀订单通常短支付窗口（如 15 分钟），超时自动关单并回滚库存
• 关单逻辑：DB 加回库存 + Redis 可选同步 + 删除用户限购标记（若允许再次抢）
• 支付成功走正常履约；取消/超时走补偿 Saga

分布式事务选型（秒杀场景）

一般不引入 2PC/TCC，采用可靠消息 + 最终一致 + 幂等 + 对账：

• Redis 扣减与 MQ 发送：本地事务表或 RocketMQ 事务消息保证「扣了必发 / 发了可对账」
• Consumer 失败：重试 + DLQ + 人工/脚本补偿
• 定时对账：Redis 计数 vs 已支付订单 vs DB 库存

风控、缓存与容错

恶意流量防护

• 登录 + 实名：秒杀前必须登录，减少匿名刷接口
• 验证码 / 滑块：开场前或点击秒杀时触发，挡脚本
• 限流维度：IP、用户 ID、设备指纹、接口级 QPS
• 黑名单：异常 IP/账号实时封禁（Redis Set）
• 链接签名：秒杀 URL 带时效 token，防直接刷 API

缓存问题

降级与隔离

• 秒杀期间关闭：商品推荐、评价列表、非必要 RPC
• Sentinel / Hystrix：秒杀服务独立线程池，下游超时快速失败
• 熔断：支付/库存服务异常时停止新秒杀入口，保护已有订单
• 静态降级页：「活动太火爆，请稍后再试」

监控与压测

• 核心指标：秒杀 QPS、Redis 扣减成功率、MQ 堆积、订单创建 RT、超卖告警（DB 扣减失败率）
• 全链路压测：模拟 10～100 倍峰值，验证限流阈值与 Consumer 消费能力
• 预案：扩容 Consumer、降级开关、活动延期/熔断入口

秒杀面试回答模板

问题：如何设计一个秒杀系统？

问题：Redis 预减成功，DB 扣减失败怎么办？

问题：为什么秒杀要用 MQ，不能直接同步下单？

问题：如何防止超卖和一人多单？

常见追问

• 库存存在 Redis 丢了怎么办？以 DB 为准重建；活动开始前预热；Redis 集群持久化与高可用；关键活动可 Redis + 本地缓存双写。
• 热点 key 问题？单 key 打满单分片；库存拆分多个 sub-stock；或请求排队令牌削峰。
• 和一般高并发下单区别？秒杀库存极少、失败率极高、可接受异步确认；电商常态下单更强调同步体验和复杂促销规则。
• 秒杀需要分布式锁吗？扣库存优先 Lua/条件 SQL，锁粒度大、RT 高；锁更适合定时任务或补偿任务互斥。

分布式事务

跨服务、跨库、跨 MQ 的一致性。强一致成本高，互联网多采用最终一致性。

方案对比

选型建议

• 短链路、强一致要求：Seata AT / TCC（量不大时）
• 订单+库存+支付：Saga 补偿或可靠消息 + 幂等
• 原则：能避免分布式事务就避免（合并服务、单库）；必须用时优先异步最终一致

分布式锁

在分布式环境下互斥执行：库存扣减、定时任务单实例、防重复提交。

实现对比

正确使用要点

• 锁 value 用 UUID，解锁 Lua 脚本校验「只删自己的锁」
• 过期时间 > 业务最大耗时，或看门狗自动续期
• 锁粒度尽量小；能不用锁则用 DB 乐观锁 / 原子 SQL
• Redlock 有争议，金融强一致场景慎选 Redis 锁

限流

保护系统不被突发流量压垮，保证核心链路可用。可在网关、应用、Redis 多层实施。

常见算法

实现层级

• 网关：Spring Cloud Gateway RequestRateLimiter、Nginx limit_req
• 框架：Sentinel 按资源名 QPS/线程数、热点参数限流
• 分布式：Redis + Lua 全局限流；按用户/IP/接口维度

与降级区别

• 限流：超过阈值直接拒绝或排队，保护系统
• 降级：关闭非核心功能，返回兜底数据，保证主流程

熔断与降级

防止故障依赖拖垮整个系统（雪崩）。熔断快速失败；降级提供备选方案。

熔断器状态机（Hystrix / Sentinel / Resilience4j）

1. Closed：正常调用，统计错误率/慢调用比例
2. Open：超过阈值则熔断，直接失败或走 fallback，经过休眠时间后进入半开
3. Half-Open：放行少量探测请求，成功则关闭熔断，失败则继续打开

触发条件（常见）

• 错误比例 > 50%（滑动窗口内）
• 慢调用比例 > 阈值（RT 超过设定 ms）
• 异常数、并发线程数超限（Sentinel）

实践组合

高可用面试回答模板

问题：如何设计一个秒杀系统

问题：CAP 怎么理解，和 BASE 关系

问题：分布式事务怎么做

问题：限流和熔断区别

常见追问

• 雪崩效应？依赖故障 → 线程阻塞 → 资源耗尽 → 级联失败；用超时、熔断、隔离、限流打破链条。
• TCC 空回滚？Try 未执行却收到 Cancel，需识别并直接成功；悬挂是 Cancel 先于 Try，需防重。
• 令牌桶 vs 漏桶？令牌桶允许突发；漏桶输出恒定，更适合平滑写下游。

SQL 调优总览

调优目标：更快返回（降低 RT）或更少资源（CPU/IO/扫描行数/Shuffle 量）。先定位瓶颈，再改 SQL、索引或架构。

通用排查步骤

1. 看慢查询日志 / APM / 执行计划（EXPLAIN / EXPLAIN ANALYZE）
2. 确认是否全表扫描、错误索引、回表过多、Join 顺序差
3. 检查数据量、统计信息是否过期（ANALYZE TABLE）
4. 改写 SQL、加/改索引、拆查询、预聚合、缓存
5. 压测验证，对比 rows examined、执行时间、成本

MySQL EXPLAIN 关键列

索引基本原则

• 最左前缀：联合索引 (a,b,c) 可用于 a、ab、abc 条件
• 区分度高的列放前面；避免对索引列函数/隐式类型转换（WHERE YEAR(dt)=2024 坏，范围改区间好）
• 覆盖索引减少回表；写多读少表慎加索引

谓词下推（Predicate Pushdown）

将 WHERE、HAVING 等过滤条件尽可能下推到数据源附近先执行，减少向上层传递的数据量，降低网络、内存与 CPU 成本。

关系型数据库（MySQL / PostgreSQL）

• 优化器自动下推：能走索引的条件在存储引擎层过滤
• 子查询改写：将过滤写在子查询内部，避免先全量再过滤
• 视图/派生表：外层 WHERE 可能合并进内层（MySQL 5.7+ 条件下推优化）

-- 不推荐：外层才过滤
SELECT * FROM (
  SELECT * FROM orders WHERE status IN (1,2,3)
) t WHERE t.created_at >= '2024-01-01';

-- 推荐：条件下推至最内层
SELECT id, amount, created_at
FROM orders
WHERE status IN (1,2,3)
  AND created_at >= '2024-01-01'
  AND user_id = ?;

数仓 / 大数据（Hive、Spark SQL、Presto）

• 分区裁剪：WHERE 带分区列（dt='2024-05-01'）只读对应目录
• 列裁剪：只 SELECT 需要的列，减少 ORC/Parquet 读取
• 谓词下推至存储：文件级跳过 Stripe/Row Group（谓词 + 列存统计信息 min/max）
• 避免在最外层才过滤几亿行明细；ETL 尽早 Filter

无法在 SQL 层下推时注意

• 对计算列过滤：WHERE UPPER(name)='ABC' → 考虑生成列 + 索引或冗余列
• 跨库 Join：先在各库内过滤再联邦 Join，减少中间结果
• ORM 生成 SQL 丢失条件：检查 N+1、全表 load 再内存 filter

Join 优化

Join 类型与代价

MySQL Join 算法（NLJ / BNL / Hash）

• Nested Loop Join：驱动表逐行嵌套被驱动表；被驱动表需有索引（eq_ref/ref）
• Block Nested Loop：无索引时缓存驱动表块，仍较慢
• Hash Join（8.0.18+）：等值连接大表无合适索引时，内存建哈希表

优化要点

1. 小表驱动大表（传统 NLJ）：减少外层循环次数；8.0 优化器常自动选驱动表
2. 被驱动表 Join 列建索引：避免对被驱动表全表扫描
3. 先过滤再 Join：各表 WHERE 后再 Join，缩小中间结果（谓词下推）
4. 避免 Join 列类型/字符集不一致：导致无法走索引
5. 控制 Join 表数量：超 3～4 张考虑宽表、物化中间表或业务拆分
6. 数仓大表 Join：Map Join（广播小表）、Bucket Join（分桶对齐）、Skew Join 处理数据倾斜

-- LEFT JOIN 条件位置
-- 过滤右表且不要保留右表无匹配：条件放 WHERE
SELECT a.* FROM users a
LEFT JOIN orders b ON a.id = b.user_id
WHERE b.created_at >= '2024-01-01';  -- 无订单用户会被滤掉，语义等同 INNER

-- 保留左表全部：右表过滤放 ON
SELECT a.* FROM users a
LEFT JOIN orders b ON a.id = b.user_id AND b.created_at >= '2024-01-01';

子查询 vs Join

• IN (SELECT ...) 有时可改 EXISTS 或 Join，便于走索引
• 避免相关子查询逐行执行；改 Join 或窗口函数（MySQL 8.0）

报表查询提效与降本

报表多为读多写少、聚合重、时间范围大，目标：少扫明细、少重复计算、可缓存。

架构层手段

SQL 层降本

• 分区表：按日/月分区，查询必带分区键，避免扫描全部分区
• 只查必要列：禁止 SELECT * 扫宽表
• 分页优化：深分页 LIMIT 100000,20 慢 → 用上次最大 ID 游标：WHERE id > ? ORDER BY id LIMIT 20
• 聚合下推：在数仓层 GROUP BY，应用层不再拉明细聚合
• 近似计算：UV 用 HyperLogLog、采样统计降低精确度换速度
• 冷热分离：历史数据归档到对象存储 + 外表查询

降低计算成本（云/集群）

• 减少全表 COUNT(*)：用统计表或估算（SHOW TABLE STATUS）
• 合并重复报表任务：同一汇总表多报表复用
• 调度错峰：T+1 凌晨批处理，避免与高峰 OLTP 抢资源
• Spark/Hive：控制 Shuffle 分区数、广播小维表、过滤前置、缓存复用中间 Dataset
• 监控：扫描字节数、Spill 磁盘、任务时长，设资源配额

反模式（报表常见）

• 在线库直接跑大范围 JOIN + GROUP BY + 排序
• 实时库做复杂多维下钻无索引维度
• 每次请求全量重算，无增量更新

SQL 面试回答模板

问题：慢 SQL 怎么排查和优化

问题：什么是谓词下推

问题：Join 很慢怎么优化

问题：报表查询如何不影响线上又降成本

常见追问

• 覆盖索引？索引包含查询所需全部列，避免回表。
• 索引失效场景？对列运算、不等于、前导模糊 %abc、OR 未全覆盖、类型转换。
• filesort 一定慢？内存 sort buffer 够用可接受；数据量大考虑索引有序或降序需求改设计。
• COUNT(1) vs COUNT(*)？InnoDB 下优化器处理相近，性能差异可忽略，看语义即可。

数据库选型总览

先分清 workload：OLTP（高并发短事务、强一致）vs OLAP（大批量扫描、聚合分析）vs HTAP（两者都要，有取舍）。

OLTP vs OLAP

MySQL / PostgreSQL / ClickHouse / Hologres 对比

各库核心特点（面试记忆）

场景与典型架构

选型建议

Lambda / 湖仓数据流（常见）

1. 业务库 MySQL → Binlog → Flink/Canal
2. 实时层写入 Hologres 或 Kafka → ClickHouse
3. 离线层 MaxCompute/Hive T+1 汇总，再回灌 Hologres 做融合查询
4. BI / 报表 / API 查询走 OLAP，保护 OLTP

ClickHouse vs Hologres（常对比）

MySQL vs PostgreSQL（常对比）

• MySQL：简单易用、主从普及、互联网案例多；复杂 SQL、CTE 历史较弱（8.0 已改善）
• PG：标准 SQL、窗口函数、CTE、扩展生态；同样规格下复杂查询往往更稳
• 选型：团队熟悉度 + 云厂商支持 + 是否需要 PG 特有扩展

数据库面试回答模板

问题：MySQL 和 ClickHouse 怎么分工

问题：Hologres 和 ClickHouse 区别

问题：为什么报表不用 MySQL 直接查

常见追问

• ClickHouse 为何快？列存、压缩、向量化执行、少随机 IO、MPP。
• PG 的 MVCC？每行多版本，读不阻塞写，需 VACUUM 回收死元组。
• HTAP 是什么？一套系统同时扛 OLTP+OLAP，如 TiDB、Hologres 部分场景；一般要接受架构或性能权衡。
• CDC 是什么？捕获数据库变更日志同步到数仓，保证分析侧近实时。

HTTP 协议总览

HTTP（HyperText Transfer Protocol）是应用层协议，基于 TCP（HTTP/3 基于 QUIC/UDP），采用请求-响应模型，默认无状态（状态靠 Cookie/Session/Token 维护）。

报文结构

请求：
请求行   GET /api/user HTTP/1.1
首部行   Host: example.com
         Content-Type: application/json
空行
消息体   {"id":1}

响应：
状态行   HTTP/1.1 200 OK
首部行   Content-Type: application/json
         Content-Length: 15
空行
消息体   {"name":"Tom"}

一次完整交互（简化）

1. DNS 解析域名 → IP
2. TCP 三次握手建立连接（HTTPS 再 TLS 握手）
3. 客户端发送 HTTP 请求
4. 服务端处理并返回响应
5. 连接关闭（HTTP/1.0）或复用（Keep-Alive / HTTP/2 多路复用）

核心特性

• 无状态：服务器不保存客户端上下文，利于水平扩展
• 灵活可扩展：首部可扩展；REST 用 URI + 方法表达资源
• 明文/加密：HTTP 明文；HTTPS = HTTP + TLS

方法与状态码

常用方法（REST 语义）

* PATCH 幂等性视实现而定，面试可说「通常不保证」。

常见状态码

HTTP 版本演进

队头阻塞（HOL Blocking）

• HTTP/1.1：同一连接多个请求排队等待响应
• HTTP/2：应用层多路复用，但 TCP 丢包会阻塞整个连接所有 Stream
• HTTP/3：QUIC 在传输层按 Stream 独立重传，减轻 HOL

连接管理

• Connection: keep-alive（1.1 默认持久）
• 浏览器对同一域名并发连接数有限（HTTP/1.1 常 6 个），故雪碧图、域名分片；HTTP/2 单连接多路复用缓解

首部与缓存

常见请求首部

• Host：虚拟主机必选（1.1）
• User-Agent、Accept、Accept-Encoding: gzip
• Authorization: Bearer <token> / Basic 认证
• Cookie：携带会话
• Content-Type / Content-Length
• If-None-Match、If-Modified-Since：协商缓存验证

常见响应首部

• Set-Cookie：HttpOnly、Secure、SameSite 防 XSS/CSRF
• Cache-Control：缓存策略核心
• ETag / Last-Modified：协商缓存标识
• Location：重定向 URL

缓存机制

优先级：Cache-Control > Expires；ETag 比时间戳更准。

Content-Type 常考

• application/json：REST API
• application/x-www-form-urlencoded：表单默认
• multipart/form-data：文件上传
• text/html、application/octet-stream

CORS（跨域）

• 浏览器同源策略：协议+域名+端口相同
• 简单请求：直接发，响应带 Access-Control-Allow-Origin
• 预检请求：OPTIONS 先发，带 Access-Control-Request-Method 等

HTTPS 与 TLS

HTTPS = HTTP + TLS（SSL 已淘汰），提供机密性、完整性、身份认证。

TLS 握手（1.2 简化）

1. Client Hello：支持的 TLS 版本、加密套件、随机数
2. Server Hello：选定参数、证书（含公钥）、随机数
3. 客户端验证证书（CA 链、域名、有效期）
4. 双方用非对称加密协商出对称会话密钥（premaster secret）
5. 后续 HTTP 数据用对称加密（AES 等）传输

TLS 1.3 改进

• 握手往返更少（1-RTT，甚至 0-RTT 恢复会话）
• 禁用弱加密套件，更安全更快

相关概念

• 对称加密：加解密同一密钥，速度快，传数据用
• 非对称加密：公钥加密、私钥解密，握手用
• 证书：CA 对公钥+主体签名，防中间人
• HSTS：强制浏览器 HTTPS 访问，防降级攻击

HTTP 面试回答模板

问题：HTTP 和 HTTPS 区别

问题：GET 和 POST 区别

问题：HTTP/1.1 和 HTTP/2 区别

问题：强缓存和协商缓存

常见追问

• TCP 三次握手？SYN → SYN+ACK → ACK，确认双方收发能力。
• Cookie 和 Session？Cookie 存客户端；Session 存服务端，Cookie 带 SessionId。
• JWT 和 Session？JWT 无状态、服务端不存；需注意过期与吊销。
• 502 和 504？502 上游无效响应；504 上游超时。

请求全链路总览

用户在浏览器点击按钮或输入 URL，到后端返回 JSON/HTML，再渲染到屏幕——中间经过浏览器、DNS、TCP/TLS、CDN、Nginx/Gateway、应用服务器、框架、业务代码、数据库/缓存/MQ等多层。面试要求能按层讲清每一跳在做什么、耗时在哪、故障点在哪。

分层模型（自顶向下）

一次 API 请求的时间线（典型 HTTPS）

0ms    用户点击 → JS 事件处理
1ms    浏览器查 DNS 缓存 / 发起 DNS 查询
20ms   TCP 三次握手（或复用 Keep-Alive 连接跳过）
40ms   TLS 1.3 握手（或 Session Ticket 复用跳过）
45ms   浏览器发送 HTTP 请求（Header + Body）
50ms   CDN 未命中 → 回源 Nginx
55ms   Nginx 转发 → Gateway → 业务 Pod
60ms   Spring Filter 链 → Controller → Service
65ms   Redis 命中 / MySQL 查询 5ms
70ms   组装 JSON 响应
100ms  响应到达浏览器 → JSON.parse → 更新 DOM
120ms  用户看到结果

浏览器侧生命周期

1. 用户触发

• 地址栏输入 URL：Navigation 开始，可能触发 HSTS 强制 HTTPS
• 点击链接触发：默认 GET；<form submit> 可能 POST
• JS 主动请求：fetch() / axios / XMLHttpRequest

2. 同源策略与 CORS

• 前端页面 https://a.com 请求 https://b.com/api 为跨域
• 简单请求：直接发，响应需带 Access-Control-Allow-Origin
• 非简单请求（自定义 Header、PUT/DELETE、JSON Content-Type 等）：浏览器先发 OPTIONS 预检
• 预检通过后才会发真正的业务请求 → 实际多一次 RTT

3. Cookie 与凭证

• 同域请求默认带 Cookie；跨域需 fetch(..., { credentials: 'include' }) 且服务端 CORS 允许
• HttpOnly Cookie 防 XSS 窃取；Secure 仅 HTTPS；SameSite 防 CSRF
• JWT 常放 Authorization: Bearer Header，由 JS 或 BFF 写入

4. 浏览器缓存（发请求前）

5. 组装 HTTP 请求

POST /api/order HTTP/1.1
Host: api.example.com
Content-Type: application/json
Authorization: Bearer eyJhbG...
Cookie: sessionId=abc; token=xyz
Accept: application/json
Content-Length: 42

{"skuId":1001,"count":1}

• 浏览器/network 栈负责：URL 解析、Header 拼接、Body 编码、Cookie 自动附加
• HTTP/2：多路复用，同一 TCP 连接上并行多个 Stream
• HTTP/3：基于 QUIC(UDP)，减少握手与队头阻塞

网络传输层

1. DNS 解析

1. 浏览器 DNS 缓存 → 操作系统缓存 → /etc/hosts
2. 本地 DNS 递归查询 → 根 → 顶级域 → 权威 DNS
3. 得到 IP（A 记录）或 CNAME 再递归

优化：DNS 预解析 <link rel="dns-prefetch">、合理 TTL、HTTPDNS（App 场景）。

2. TCP 三次握手

Client ──SYN(seq=x)──────────────► Server
Client ◄──SYN+ACK(seq=y,ack=x+1)── Server
Client ──ACK(ack=y+1)───────────► Server
→ 连接建立，可传 HTTP

• Keep-Alive：同一连接复用，避免每次请求都三次握手
• 队头阻塞：HTTP/1.1 同一连接上请求需排队等响应（HTTP/2 多路复用缓解应用层，TCP 层仍可能阻塞）

3. TLS 握手（HTTPS）

TLS 1.3 典型 1-RTT 握手（首次 2-RTT），之后 Session Ticket / Session ID 可0-RTT 复用（有重放风险需评估）。

• 协商 cipher suite、交换密钥、验证服务器证书链（CA → 中间 CA → 站点证书）
• 证书校验：域名匹配、有效期、吊销列表（OCSP）
• 之后 HTTP 报文在 TLS 记录层加密传输

4. HTTP 请求到达服务器

操作系统内核 TCP 缓冲区收包 → 监听端口进程（Nginx :443 / Tomcat :8080）read → 解析 HTTP 报文。

5. 连接关闭

• HTTP/1.1 默认 Keep-Alive，空闲超时后 TCP 四次挥手
• HTTP/2 长连接 + 多 Stream；GOAWAY 帧优雅关闭

CDN 与接入层（Nginx）

CDN 路径

1. DNS 解析到 CDN 边缘节点 IP（CNAME 到 CDN 域名）
2. 边缘节点查缓存：静态资源（JS/CSS/图片）命中则直接 200 返回
3. 未命中：回源到源站 Nginx/OSS
4. 动态 API 通常不缓存或极短 TTL，CDN 只做传输加速

Nginx 反向代理（请求进入后端前）

server {
  listen 443 ssl;
  server_name api.example.com;

  ssl_certificate     /path/fullchain.pem;
  ssl_certificate_key /path/privkey.pem;

  location /api/ {
    limit_req zone=api burst=20 nodelay;   # 限流
    proxy_pass http://gateway_upstream;   # 转发上游
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
  }
}

Nginx 处理步骤

1. SSL 终结：对外 HTTPS，对内 often HTTP（内网可信）或继续 HTTPS
2. 解析请求行与 Header
3. location 匹配：静态文件直接 root/alias；API 走 proxy_pass
4. 负载均衡：轮询、加权、ip_hash、least_conn 选 upstream 一台
5. 附加 Header 转发给后端，便于日志与风控
6. 等待上游响应，可 gzip 压缩后返回客户端

WAF / 安全（可选）

• SQL 注入、XSS 特征拦截；CC 攻击频率限制
• 在 Nginx 前或云 WAF 层完成

API 网关与负载均衡

SLB / L4 负载均衡

• 工作在传输层，按 IP+端口转发到后端 Nginx 或 Pod
• 健康检查剔除故障节点

Spring Cloud Gateway（L7）

1. 请求到达 Gateway（WebFlux 事件循环）
2. Global Filter 链：日志 TraceId、JWT 鉴权、限流、黑名单
3. Route 匹配：Path=/api/order/** → lb://order-service
4. Gateway Filter：StripPrefix、AddRequestHeader、RequestRateLimiter
5. LoadBalancer：从 Nacos/Eureka 取实例列表，选一台发 HTTP
6. 收下游响应，经 Filter 后返回 Nginx → 客户端

Client → Nginx → Gateway → [Auth Filter] → [Route Match]
  → LoadBalancer 选实例 10.0.1.5:8080
  → HTTP 转发到 order-service Pod
  ← 响应沿原路返回

网关常见职责

Spring Boot 后端处理

以 Tomcat + Spring MVC 为例（Servlet 栈）；WebFlux 为事件驱动模型，链路概念类似但无线程一请求一绑定。

Tomcat 接收请求

1. Acceptor 线程 accept 新连接 → Poller 监听可读
2. Worker 线程从 socket read HTTP 报文
3. 封装为 HttpServletRequest / HttpServletResponse
4. 交给 Servlet 容器处理链

Filter 链（Servlet Filter）

Request → CharacterEncodingFilter
       → CorsFilter
       → SpringSecurityFilterChain（认证/授权）
       → TraceFilter（链路追踪）
       → DispatcherServlet

• Filter 可短路：未登录返回 401，不再进 Controller
• 顺序由 @Order 或 RegistrationBean 决定

DispatcherServlet 核心流程

1. HandlerMapping：根据 URL + Method 找 Handler（Controller 方法），如 @GetMapping("/api/user/{id}")
2. HandlerAdapter：调用 Controller，解析 @PathVariable、@RequestBody、@RequestParam
3. Controller：参数校验（@Valid）→ 调 Service
4. Service：业务逻辑、事务（@Transactional）、调 Mapper/Feign
5. 返回：对象 → HttpMessageConverter（Jackson）→ JSON 写回 Response

AOP 与事务

• @Transactional 通过 AOP 代理：方法前开事务，异常回滚，提交后释放连接
• 切面顺序：Security → Transaction → 业务，面试常问「事务失效」场景（自调用、非 public、异常被吞）

异常处理

• @ControllerAdvice + @ExceptionHandler 统一返回 {code, message}
• 未捕获异常 → 500；参数错误 → 400

数据层与中间件

连接池（HikariCP）

1. Service 需要 DB 连接 → 从池 borrow
2. 执行 SQL → ResultSet 映射为 Java 对象（MyBatis / JPA）
3. 归还连接到池（勿在 finally 泄漏）

池耗尽 → 请求阻塞等待 → RT 飙升 → 线程池打满 → 雪崩。

MySQL 一次查询

1. 解析 SQL → 优化器选索引 → 存储引擎 InnoDB
2. Buffer Pool 命中页则内存读，否则磁盘 IO
3. 加行锁（UPDATE）/ 间隙锁（范围）→ 返回结果
4. binlog 记录变更（主从复制、CDC）

Redis 一次访问

• Lettuce/Jedis 发命令 → Redis 单线程执行 → 返回
• 缓存旁路：先 Redis miss → 查 DB → 写 Redis
• RT 通常 1ms 级，远快于 DB

Feign 调用下游微服务

1. Feign 接口 → LoadBalancer 选实例 → HTTP 发下游
2. 超时、重试（幂等才重试）、熔断（Sentinel/Resilience4j）
3. 全链路 TraceId 通过 Header 传递（Sleuth/Micrometer）

异步 MQ（若涉及）

同步链路只负责「发消息成功」；Consumer 另线程消费，与 HTTP 请求生命周期分离，但面试常作为「下单后异步通知」的延伸。

响应回程与浏览器渲染

服务端组装响应

HTTP/1.1 200 OK
Content-Type: application/json; charset=UTF-8
Content-Encoding: gzip
Set-Cookie: sessionId=...; HttpOnly; Secure
X-Trace-Id: abc123

{"code":0,"data":{"orderId":10001}}

1. Controller 返回值 → Jackson 序列化
2. Filter 可改 Header（CORS、Security）
3. Nginx gzip 压缩 body
4. TCP 分包发送 → 客户端 ACK

浏览器处理响应

1. 解析状态码：2xx 成功；401 跳登录；5xx 提示错误
2. 读 Header：Set-Cookie 更新 Cookie；Content-Type 决定解析方式
3. gzip/br 解压 body
4. JSON API：response.json() → JS 更新 state → 虚拟 DOM diff → 重绘
5. HTML 导航：解析 HTML → 构建 DOM → 加载 CSS/JS → 执行脚本 → 渲染树 → 绘制

Performance API 可观测

• performance.getEntriesByType('navigation')：DNS、TCP、TTFB、DOMContentLoaded
• TTFB（首字节时间）：网络 + 服务端处理
• 服务端日志：Gateway access log + 应用 Trace span 分解耗时

微服务场景扩展链路

单体一次请求只进一个 JVM；微服务可能串行/并行多次 RPC。

Browser
  → Nginx → Gateway
      → order-service（写订单）
          → Feign → product-service（查库存）
          → Feign → user-service（查用户）
          → Redis（扣库存 Lua）
          → RocketMQ（发消息）
      ← 聚合结果 JSON
  ← 返回浏览器

MQ Consumer（异步，另一生命周期）
  → inventory-service 确认扣减
  → payment-service 发起支付

分布式追踪

• Gateway 生成 TraceId → 各服务 Log/Span 关联
• Jaeger / Zipkin / SkyWalking 展示调用瀑布图
• 定位慢在哪个 Feign、哪条 SQL

与单体对比

全链路面试回答模板

问题：描述一次 HTTP 请求从浏览器到后端的完整过程

问题：HTTPS 比 HTTP 多做了什么

问题：请求慢怎么排查

问题：Nginx 和 Gateway 分别做什么

常见追问

• OPTIONS 预检什么时候发？跨域且非简单请求时，先于 POST/PUT 等发 OPTIONS。
• 502 和 504？502 上游返回非法响应或连接被拒；504 网关等上游超时。
• Tomcat 线程模型？Acceptor + Poller + Worker；Worker 阻塞 IO 时线程占满则拒绝新请求。
• 为什么 Gateway 用 WebFlux？非阻塞 IO，少量线程扛高并发转发；阻塞调用需隔离线程池。
• Cookie 什么时候带上？同域自动带；跨域需 credentials + CORS 允许；Domain/Path 决定范围。

SSO 总览

单点登录（Single Sign-On，SSO）：用户在一个统一认证中心（IdP / Auth Server）完成一次登录后，访问同一信任域内的多个应用（SP / 业务系统）时无需重复输入账号密码。

核心目标不是「少输一次密码」，而是认证逻辑集中化：账号体系、密码策略、MFA、审计、会话吊销、权限模型在一处治理，业务系统只关心「这个请求代表谁、有什么权限」。

SSO 解决什么问题

• 用户体验：多系统一次登录，减少重复认证
• 安全治理：统一 MFA、密码策略、登录风控、会话超时
• 运维成本：账号开通/离职回收一处处理，避免各系统各自维护用户表
• 架构解耦：业务系统不存密码，只验证 Token / Ticket

与相关概念的区别

核心概念

角色模型

凭证形态对比

信任域（Trust Domain）

SSO 生效前提是 SP 信任 IdP 签发的凭证。信任建立方式：

• 共享密钥 / 公钥（JWT 验签、SAML 证书）
• 预注册的 ClientId + Redirect URI 白名单
• 网关统一验 Token，内网服务信任网关传递的用户上下文

协议选型

选型建议（2020s 常见实践）

OIDC vs SAML（面试高频）

典型流程

1. OIDC 授权码模式（Web SSO 主流）

1. 用户访问 SP（业务系统），未登录 → 302 到 IdP /authorize
2. 用户在 IdP 登录（或已有 SSO Cookie，直接跳过）
3. IdP 302 回 SP 的 redirect_uri，携带一次性 code
4. SP 后端用 code + client_secret（或 PKCE 的 verifier）向 IdP /token 换 Token
5. SP 得到 id_token（身份）+ access_token（访问 API）+ 可选 refresh_token
6. SP 建立本地 Session 或把 Token 写入 HttpOnly Cookie，后续请求带 Session / Bearer Token

用户 ──► SP ──302──► IdP /authorize?client_id=&redirect_uri=&scope=openid
用户 ◄── IdP 登录页（或 SSO Cookie 免登）
用户 ◄── SP /callback?code=xxx
SP  ──POST──► IdP /token  （后端，不经过浏览器传 secret）
SP  ◄── id_token + access_token
SP  建立会话，访问受保护资源

2. CAS 单点登录（简化）

1. 用户访问 SP-A，无本地 Session → 重定向到 CAS /login?service=SP-A
2. CAS 校验凭证，写入 TGT（存在 CAS 域 Cookie）
3. CAS 签发一次性 ST（Service Ticket），重定向回 SP-A
4. SP-A 后端拿 ST 调 CAS /serviceValidate 校验，得到用户名
5. 用户再访问 SP-B，同样重定向 CAS；因 TGT 仍在，免输密码，直接发 ST 给 SP-B

3. 网关统一鉴权（微服务常见）

• 浏览器只与 API Gateway 和 IdP 交互
• Gateway Global Filter 校验 JWT（签名、过期、audience、scope）
• 校验通过后向下游注入 Header（如 X-User-Id、X-Roles）或透传原始 Token
• 内网服务策略：全信任网关 / 二次验签 / 仅内网 mTLS

4. 单点登出（SLO）

SSO 登录容易，登出更难：IdP 会话、各 SP 本地 Session、Refresh Token 可能并存。

• IdP 发起：IdP 登出后通知各 SP 的 logout URL（Front-Channel iframe / Back-Channel POST）
• SP 发起：SP 清本地 Session 后重定向 IdP /logout
• Token 方案：短 Access Token + Refresh 轮换；登出时吊销 Refresh / 加入黑名单

架构设计

推荐分层

多系统账号映射

• 统一账号：全系统同一 userId（最理想）
• 联邦映射：IdP 的 sub 与各系统 local_user 表关联
• JIT Provisioning：首次 SSO 登录自动在 SP 建用户
• SCIM：IdP 向各 SP 同步用户生命周期（入职/离职）

跨域与子域 Cookie

• 同主域：.example.com 共享 Cookie 可实现「伪 SSO」
• 跨主域：必须走标准协议（OIDC/SAML/CAS），不能单靠 Cookie
• 生产环境：Secure、HttpOnly、SameSite=Lax/Strict，防 CSRF 与 Token 泄露

与 Spring 生态集成（思路）

# 业务服务作为 Resource Server
spring.security.oauth2.resourceserver.jwt.issuer-uri=https://idp.example.com/realms/corp

# Gateway 统一鉴权 + 路由
spring.cloud.gateway.routes[0].filters=TokenRelay, StripPrefix=1

# BFF 用 OAuth2 Login 接 OIDC，浏览器只拿 Session Cookie

安全与治理

必做项

• HTTPS 全链路，Redirect URI 严格白名单
• 授权码模式，Public Client 配 PKCE；禁止 Implicit 模式存 Token 到 URL
• state 防 CSRF；nonce 防 ID Token 重放
• Access Token 短过期（5–15 min），Refresh Token 轮换 + 吊销表
• 敏感操作二次验证（MFA、step-up auth）
• 登录审计：IP、设备、失败次数、异地风控

JWT 在 SSO 中的注意点

• JWT 默认无法服务端主动失效，登出/改密需配合短 TTL、黑名单、版本号（token version）
• 不要把敏感信息放 JWT payload（可解码）
• 验签：RS256（IdP 私钥签，SP 公钥验）优于 HS256 共享密钥
• 校验 iss、aud、exp、nbf，防跨租户 Token 误用

常见坑

SSO 面试回答模板

问题：什么是单点登录？怎么设计？

问题：OAuth2、OIDC、SSO 什么关系？

问题：JWT 和 Session 做 SSO 怎么选？

问题：如何实现单点登出？

常见追问

• PKCE 是什么？Proof Key for Code Exchange，Public Client 用 code_verifier 换 code，防授权码被截获后滥用。
• ID Token 和 Access Token？ID Token 表身份（给 Client）；Access Token 访问 Resource Server API。
• 同域 Cookie 算 SSO 吗？同主域共享 Session Cookie 可算轻量 SSO，但不跨域、难对接第三方，生产仍推荐 IdP 协议。
• Gateway 鉴权后下游还要验吗？看信任边界：零信任下 Resource Server 仍验 JWT；纯内网可信任网关 Header 但要防绕过。