Java面试核心知识点

Java面试知识体系
  │
  ├── 基础内功
  │     ├── Java集合（HashMap / ConcurrentHashMap）
  │     ├── JVM（内存模型 / GC / 排查）
  │     ├── 并发编程
  │     │     ├── ThreadLocal ← 文档01
  │     │     ├── 线程池 ← 文档09
  │     │     ├── 锁机制
  │     │     └── CAS / AQS ← 文档06
  │     └── ...
  │
  ├── 框架生态
  │     ├── Spring IOC / AOP / 事务 ← 文档08
  │     │     └── @Transactional失效 ← 文档05
  │     ├── Spring Boot 自动装配
  │     └── Spring Cloud 微服务
  │
  ├── 数据与中间件
  │     ├── MySQL
  │     │     ├── 索引 / 事务 / SQL优化
  │     │     ├── 慢SQL排查 ← 文档03
  │     │     └── 调优五维体系 ← 文档04
  │     ├── Redis
  │     │     ├── 缓存三大问题（穿透/击穿/雪崩）
  │     │     └── 缓存一致性 ← 文档02
  │     └── MQ（异步 / 削峰 / 解耦）
  │
  ├── 分布式系统
  │     ├── 分布式锁
  │     ├── 分布式事务 ← 文档07
  │     └── SaaS多租户
  │
  └── 业务领域
        ├── 跨境电商ERP
        └── 第三方接口开发

ThreadLocal
  ├── 本质：线程私有存储，每个线程一份副本
  │
  ├── 底层结构
  │     ├── Thread 对象中持有 ThreadLocalMap
  │     ├── Entry extends WeakReference<ThreadLocal<?>>  ← key是弱引用
  │     └── Entry.value 是强引用                          ← value是强引用
  │
  ├── 核心问题
  │     ├── 问题1：内存泄露
  │     │     根因：key被GC回收 → value强引用链仍在 → 无法释放
  │     │     触发条件：线程池中线程长期存活
  │     │
  │     ├── 问题2：线程复用数据串读
  │     │     根因：线程池复用线程 → 未remove → 下一个请求读到上一个请求的上下文
  │     │     场景：用户A的请求 → 线程1处理 → 未清理 → 用户B的请求 → 线程1处理 → 读到A的数据
  │     │
  │     └── 问题3：上下文传递失效
  │           InheritableThreadLocal → 仅适用于new Thread()，线程池下失效
  │
  ├── 解决方案
  │     ├── 内存泄露 → remove() + 自定义跟踪/切面兜底
  │     ├── 数据串读 → remove()（必须！但不够！）
  │     └── 上下文传递
  │           ├── TransmittableThreadLocal（TTL）← 线程池场景首选
  │           │     原理：装饰器模式，任务执行前快照、执行后恢复
  │           └── Reactor Context ← 响应式编程场景
  │
  └── 生产落地
        ├── 自定义 ThreadLocal 跟踪 remove 调用
        ├── TTL 工具做清理切面
        └── 规范：try-finally 中必须 remove

线程池核心线程数配置
  │
  ├── ❌ 错误回答：直接背公式
  │     CPU密集=N+1，IO密集=2N → 只讲公式不谈落地 → 面试翻车
  │
  ├── ✅ 正确思路：公式只是起点，落地靠四步
  │     ① 公式估算初始值
  │     ② 评估下游资源上限（DB连接池/Redis连接/第三方限流）
  │     ③ 压测验证（CPU利用率/队列积压/RT/拒绝数）
  │     ④ 持续监控调优
  │
  ├── 两套估算公式（理论参考）
  │     ├── CPU密集：N+1（N=CPU核心数）
  │     │     纯计算/加密/解析，极少阻塞
  │     │     +1预留应对短暂阻塞
  │     │
  │     └── IO密集：N × (1 + IO等待时间/CPU计算时间)
  │           经验值：2N（仅起步参考）
  │           DB查询/RPC/文件读写，大量时间阻塞等待
  │
  ├── 线上四大踩坑
  │     ├── 1. 无限放大最大线程数 → 争抢有限连接 → 上下文切换雪崩
  │     ├── 2. 使用无界队列 → 任务无限堆积 → OOM
  │     ├── 3. 所有业务共用线程池 → 慢任务阻塞关键业务
  │     └── 4. AbortPolicy直接丢任务 → 业务数据丢失
  │
  ├── JDK线程池执行顺序（重要！）
  │     核心线程满 → 任务入队列 → 队列满 → 才创建非核心线程
  │     ⚠️ IO密集业务：CPU空闲但任务在排队，非核心线程迟迟不创建
  │
  └── 进阶：动态线程池
       运行时调整核心线程/最大线程/队列长度
       配合监控告警，应对大促/下游抖动

核心线程数 ≈ CPU核心数 + 1

精准公式：线程数 = CPU核心数 × (1 + 平均IO等待时间 / CPU计算时间)
经验值：2N（起步参考）

步骤1：公式估算初始值
  ↓
步骤2：评估下游资源上限  ← 最关键的一步！
  ↓
步骤3：压测验证
  ↓
步骤4：持续监控调优

提交任务
  │
  ├── 1. 核心线程未满？→ 创建核心线程执行
  │
  ├── 2. 核心线程已满？→ 任务放入队列
  │
  ├── 3. 队列已满？→ 创建非核心线程
  │
  └── 4. 非核心线程也满了？→ 执行拒绝策略

// ❌ 错误：最大线程设500，但数据库连接池只有20
new ThreadPoolExecutor(8, 500, 60, TimeUnit.SECONDS, new LinkedBlockingQueue<>(100));
// 结果：500线程抢20个连接 → 480线程阻塞 → CPU上下文切换雪崩

// ❌ 错误：无界队列
new ThreadPoolExecutor(8, 50, 60, TimeUnit.SECONDS, new LinkedBlockingQueue<>());
// 结果：流量突增 → 任务无限堆积 → 内存撑爆 → OOM

// ❌ 错误：慢任务和快任务共用一个池
executor.submit(() -> syncAmazonOrders());   // 慢：调Amazon API，3秒
executor.submit(() -> sendNotification());   // 快：发通知，10ms
// 慢任务占满线程 → 快任务排队等 → 通知延迟3秒！

// ❌ 错误：AbortPolicy直接丢弃任务
new ThreadPoolExecutor.AbortPolicy()
​
// ✅ 推荐：CallerRunsPolicy——队列满了让提交者自己执行
new ThreadPoolExecutor.CallerRunsPolicy()
// 提交任务的线程自己跑 → 自动降速 → 保护系统不崩溃

Java锁体系
  │
  ├── 两套体系（不要混淆！）
  │     ├── synchronized → JVM底层C++实现（对象头mark-word + Monitor）
  │     └── JUC Lock系列 → Java代码实现，全部基于AQS
  │
  ├── AQS（AbstractQueuedSynchronizer）—— JUC锁的底层基石
  │     ├── 核心三件东西
  │     │     ├── 1. state（int同步状态变量）—— 灵魂，不同锁state含义不同
  │     │     ├── 2. CLH双向阻塞队列（同步队列）—— 排队等锁
  │     │     └── 3. Condition条件队列 —— await/signal
  │     │
  │     ├── 模板方法模式
  │     │     ├── AQS提供模板：acquire / release（排队+阻塞逻辑）
  │     │     └── 子类实现钩子：tryAcquire / tryRelease（修改state逻辑）
  │     │
  │     └── 两种模式
  │           ├── 独占模式：只有一个线程能获取（ReentrantLock写锁）
  │           └── 共享模式：多个线程可同时获取（读锁/CountDownLatch/Semaphore）
  │
  ├── 各锁如何基于AQS实现
  │     ├── ReentrantLock：state=重入次数，独占模式
  │     ├── ReentrantReadWriteLock：state高位=读锁计数，低位=写锁计数
  │     ├── CountDownLatch：state=计数器，共享模式，减到0唤醒
  │     └── Semaphore：state=许可数量，共享模式
  │
  └── 核心认知：AQS本身不是锁，只是框架。锁是AQS的子类。

       CLH双向链表队列
  ┌───┐   ┌───┐   ┌───┐   ┌───┐
  │头  │←→│Node│←→│Node│←→│Node│
  │dummy│  │线程A│  │线程B│  │线程C│
  └───┘   └───┘   └───┘   └───┘
   已获锁    等待      等待     等待
            ↑前驱释放锁后唤醒这个

同步队列（等锁）          Condition队列（等条件）
┌───┐  ┌───┐           ┌───┐  ┌───┐
│头  │←→│B  │           │D  │→│E  │
└───┘  └───┘           └───┘  └───┘
​
线程A持有锁，调用condition.await()
  → A释放锁 → A从同步队列移到Condition队列
  → 唤醒同步队列下一个线程B
​
其他线程调用condition.signal()
  → D从Condition队列移回同步队列 → D重新排队抢锁

AQS（总部模板）                    子类（各店特色）
┌─────────────────────┐          ┌─────────────────────┐
│ acquire() {          │          │ tryAcquire() {       │
│   if (!tryAcquire()) │ ──调用──→│   // 自己实现抢锁逻辑 │
│     入队阻塞;         │          │   // 修改state        │
│ }                    │          │ }                    │
│                      │          │                      │
│ release() {          │          │ tryRelease() {       │
│   if (tryRelease())  │ ──调用──→│   // 自己实现释放逻辑 │
│     唤醒后继节点;      │          │   // 修改state        │
│ }                    │          │ }                    │
└─────────────────────┘          └─────────────────────┘
  排队、阻塞、唤醒逻辑              抢锁、释放逻辑
  （AQS统一搞定）                  （每个锁自己定义）

Spring面试三大模块（连环追问）
  │
  ├── 模块1：IoC容器
  │     ├── IoC vs DI（思想 vs 实现）
  │     ├── BeanFactory vs ApplicationContext（懒加载 vs 预加载+扩展）
  │     ├── Bean生命周期（5大阶段）
  │     └── 循环依赖（三级缓存）
  │           ├── 一级：singletonObjects（完整Bean）
  │           ├── 二级：earlySingletonObjects（半成品Bean）
  │           └── 三级：singletonFactories（Bean工厂，支持AOP代理）
  │           ⚠️ 仅对单例+setter注入生效，构造器注入无法解决
  │
  ├── 模块2：AOP面向切面
  │     ├── 两种代理方式
  │     │     ├── JDK动态代理（有接口，基于接口）
  │     │     └── CGLIB代理（无接口，继承生成子类）
  │     │     Spring5后默认优先CGLIB
  │     └── AOP是事务的底层 → 绕过代理=事务失效
  │
  └── 模块3：Spring事务
        ├── 底层原理：AOP动态代理
        ├── 传播行为（7种）
        ├── 隔离级别（沿用数据库标准）
        └── 失效场景（详见文档05）

1. 实例化（Instantiation）
   → HR发offer，人来报到了（new出对象）

2. 属性填充（PopulateBean）
   → 分配工位、配电脑、认识同事（注入依赖@Autowired）

3. 初始化（Initialization）
   → 入职培训流程：
     ① BeanPostProcessor前置处理 → 培训前准备
     ② @PostConstruct → 入职宣誓
     ③ InitializingBean.afterPropertiesSet() → 签合同
     ④ 自定义init-method → 领工牌
     ⑤ BeanPostProcessor后置处理 → 培训后发工牌
     ⭐ AOP代理在第⑤步生成！

4. 使用中（In Use）
   → 正式上岗，放在容器里供其他Bean使用

5. 销毁（Destruction）
   → 离职流程：
     ① @PreDestroy → 交接工作
     ② DisposableBean.destroy() → 归还设备
     ③ 自定义destroy-method → 正式离职

@Service
public class A {
    @Autowired
    private B b;  // A依赖B
}

@Service
public class B {
    @Autowired
    private A a;  // B依赖A
}
// A创建→需要B→B创建→需要A→A还没创建完→死循环！

三级缓存：
┌──────────────────────────────────────────────────────┐
│ 一级缓存 singletonObjects                             │
│   存放：完整初始化完成的Bean（毕业的员工）               │
├──────────────────────────────────────────────────────┤
│ 二级缓存 earlySingletonObjects                        │
│   存放：实例化完成但未填充属性的半成品Bean（刚报到没配电脑）│
├──────────────────────────────────────────────────────┤
│ 三级缓存 singletonFactories                           │
│   存放：Bean工厂对象（能生成Bean的"模具"）              │
│   ⭐ 核心作用：支持AOP代理场景                          │
└──────────────────────────────────────────────────────┘

1. 创建A：
   ① 实例化A（new A()，半成品）
   ② 将A的工厂放入三级缓存（提前暴露！）
   ③ 填充A的属性 → 发现需要B

2. 创建B：
   ① 实例化B（new B()，半成品）
   ② 将B的工厂放入三级缓存
   ③ 填充B的属性 → 发现需要A
   ④ 从三级缓存获取A的工厂 → 调用工厂生成A
      ⭐ 如果A需要AOP代理 → 工厂返回代理对象
      ⭐ 如果A不需要代理 → 工厂返回原始对象
   ⑤ 将A放入二级缓存（半成品）
   ⑥ B的属性填充完成 → B初始化完成 → B放入一级缓存

3. 回到A：
   ④ A的属性B已就绪 → A填充完成
   ⑤ A初始化完成 → A放入一级缓存
   ⑥ 清除A在二级缓存的记录

@Transactional 失效
  │
  ├── 底层原理：Spring事务基于AOP动态代理
  │     只有通过代理对象调用 → 事务逻辑才执行
  │     绕过代理对象调用 → 事务直接失效
  │     所有7种失效场景 → 本质都是"绕开AOP代理"或"规则配置错误"
  │
  ├── 七种失效场景
  │     ├── 1. 方法不是public → AOP不代理非public方法
  │     ├── 2. 同类内部调用（this调用）→ this是原始对象，不走代理
  │     ├── 3. 异常被try-catch吞掉 → Spring感知不到异常，不回滚
  │     ├── 4. 异常类型不对 → 默认只回滚RuntimeException，checked Exception不回滚
  │     ├── 5. 类没被Spring管理 → new出来的对象，不生成AOP代理
  │     ├── 6. 传播行为配置错误 → SUPPORTS/NOT_SUPPORTED/NEVER不开启事务
  │     └── 7. 数据库不支持事务 → MyISAM引擎，底层无法回滚
  │
  └── 额外注意：长事务不是失效，是性能故障
       事务内写RPC/HTTP调用 → 行锁长时间持有 → 锁等待

非public  内部调  异常吞  类型错
没托管    传播错  引擎差

@Service
public class OrderService {
    @Transactional
    private void createOrder() {  // ❌ private！事务完全无效
        orderMapper.insert(order);
    }
}

@Service
public class OrderService {
    public void createOrder() {
        this.deductInventory();  // ❌ this是原始对象，不走代理！
    }

    @Transactional
    public void deductInventory() { ... }
}

// 方案1：注入自己（推荐）
@Service
public class OrderService {
    @Autowired @Lazy
    private OrderService self;

    public void createOrder() {
        self.deductInventory();  // ✅ 通过代理对象调用
    }
}

// 方案2：拆分到其他Service
@Service
public class OrderService {
    @Autowired
    private InventoryService inventoryService;

    public void createOrder() {
        inventoryService.deduct();  // ✅ 不同类，走代理
    }
}

@Transactional
public void createOrder() {
    try {
        orderMapper.insert(order);
        inventoryMapper.deduct(order);
    } catch (Exception e) {
        log.error("下单失败", e);  // ❌ 异常被吞了！Spring感知不到
    }
}

// 方案1：catch后手动标记回滚
@Transactional
public void createOrder() {
    try {
        orderMapper.insert(order);
        inventoryMapper.deduct(order);
    } catch (Exception e) {
        log.error("下单失败", e);
        TransactionAspectSupport.currentTransactionStatus().setRollbackOnly();
    }
}

@Transactional
public void createOrder() throws Exception {
    orderMapper.insert(order);
    throw new Exception("业务异常");  // ❌ checked Exception，默认不回滚！
}

@Transactional(rollbackFor = Exception.class)  // ✅ 所有异常都回滚
public void createOrder() throws Exception { ... }

// ❌ 没有@Service/@Component注解
public class OrderService {
    @Transactional
    public void createOrder() { ... }
}

// 调用处
OrderService service = new OrderService();  // ❌ new出来的，不走Spring容器
service.createOrder();  // 事务完全无效

-- ❌ MyISAM引擎：不支持事务
CREATE TABLE `order` (...) ENGINE=MyISAM;

-- ✅ InnoDB引擎：支持事务
CREATE TABLE `order` (...) ENGINE=InnoDB;

慢SQL排查
  │
  ├── 总原则：先分现象，再拿证据，最后优化
  │     ├── 是一直慢，还是偶尔抖动？
  │     ├── 是单条SQL慢，还是整个数据库卡？
  │     └── 不凭感觉猜，用数据说话
  │
  ├── ❌ 三个典型错误
  │     ├── 错误1：看到慢就加索引 → 乱建索引伤写入，问题不一定解决
  │     ├── 错误2：explain走索引就认为没问题 → 走索引但大量回表，依旧慢
  │     └── 错误3：只看SQL不看Java代码 → @Transactional包裹RPC导致长事务锁等待
  │
  ├── 排查流程（5步）
  │     ├── ① 应用层定位线索（Druid / SkyWalking）
  │     ├── ② 数据库层看慢查询日志（3个关键指标）
  │     ├── ③ explain执行计划分析（4个重点字段）
  │     ├── ④ 分三类根因定位
  │     │     ├── 类别1：SQL本身执行慢（Lock_time低，扫描行数大）
  │     │     ├── 类别2：锁等待导致慢（Lock_time高，explain正常）
  │     │     └── 类别3：偶发抖抖（资源层面问题）
  │     └── ⑤ 优化后验证
  │
  └── 三类根因速查表
        | 信号 | Lock_time | 扫描行数 | explain | 根因 |
        |------|-----------|---------|---------|------|
        | 类别1 | 低 | 大 | type差/Extra差 | SQL本身慢 |
        | 类别2 | 高 | 正常 | 正常 | 锁等待 |
        | 类别3 | 波动 | 波动 | 正常 | 资源抖动 |

1. WHERE LEFT(name, 3) = '张'    ← 列上套函数，索引失效
2. WHERE phone = 13800138000     ← 字符串列传数字，隐式转换，索引失效
3. WHERE name LIKE '%三'         ← %开头，索引失效
4. 联合索引(a,b,c)，WHERE b=1   ← 跳过最左列a，索引失效
5. WHERE a > 1 AND b = 2        ← 联合索引中a用了范围，b用不上索引

-- ❌ 慢：扫描10万行，丢弃前99990行
SELECT * FROM order ORDER BY id LIMIT 100000, 10;

-- ✅ 快：游标分页，直接从上一页最大id开始
SELECT * FROM order WHERE id > 上一页最大id ORDER BY id LIMIT 10;

// ❌ 长事务：RPC在事务内
@Transactional
public void placeOrder(Order order) {
    orderMapper.insert(order);        // SQL很快，0.5ms
    httpClient.callPaymentService();   // RPC调用，可能3秒超时！
    // 事务一直开着，行锁一直持有！
}

// ✅ 缩小事务边界：RPC放事务外
public void processOrder() {
    PaymentResult result = paymentService.pay();  // 事务外，不持锁

    doInTransaction(() -> {
        orderMapper.updateStatus(result);  // 0.5ms
        inventoryMapper.deduct();          // 0.5ms
    });
    // 事务1ms就提交，行锁瞬间释放！
}

MySQL调优五维体系
  │
  ├── 核心认知：索引只是调优很小一部分
  │     线上大量性能问题不是缺索引
  │     而是表设计、事务、配置、业务使用方式带来的
  │
  ├── 第1层：SQL语句层
  │     ├── 覆盖索引，减少回表
  │     ├── 游标分页，替代深分页
  │     ├── 减少join表数量
  │     ├── 避免索引失效
  │     ├── 优化order by / group by
  │     └── 大事务拆小，分批delete/update
  │
  ├── 第2层：表结构设计层
  │     ├── 字段类型合理
  │     ├── 尽量NOT NULL
  │     ├── 自增主键
  │     ├── 大表分库分表、冷热分离
  │     └── 适当反范式，冗余字段减少join
  │
  ├── 第3层：锁与事务层（线上故障高发点）
  │     ├── 缩小事务边界
  │     ├── 避免长事务
  │     ├── 隔离级别选择（大部分业务用RC）
  │     ├── 乐观锁优先于悲观锁
  │     └── 排查锁等待/死锁
  │
  ├── 第4层：MySQL配置参数层
  │     ├── innodb_buffer_pool_size（服务器内存50%-70%）
  │     ├── innodb_log_file_size（redo日志）
  │     ├── max_connections（结合连接池）
  │     ├── 慢查询日志开启
  │     └── sort_buffer_size / join_buffer_size
  │
  └── 第5层：业务架构层（更高阶）
        ├── 读写分离
        ├── 引入Redis缓存热点查询
        ├── 大表分库分表
        ├── 冷热数据归档
        └── 计算从数据库剥离

自增主键：1 → 2 → 3 → 4 → 5（顺序追加，不挪动）
随机主键：3 → 1 → 5 → 2 → 4（乱序插入，可能页分裂）

-- 范式设计：每次查订单都要join用户表
SELECT o.id, o.amount, u.name FROM order o JOIN user u ON o.user_id = u.id;

-- 反范式：订单表冗余存用户名
SELECT id, amount, user_name FROM order;  -- 不用join了！

-- 悲观锁：先锁再改（阻塞其他人）
SELECT * FROM inventory WHERE id = 1 FOR UPDATE;
UPDATE inventory SET stock = stock - 1 WHERE id = 1;

-- 乐观锁：先改再检查冲突（不阻塞）
UPDATE inventory SET stock = stock - 1, version = version + 1
WHERE id = 1 AND version = 旧版本号;
-- 影响行数=0说明冲突了，重试

缓存一致性
  │
  ├── 核心矛盾
  │     缓存（Redis）和数据库（MySQL）是两个独立的存储
  │     无法在一个事务里同时更新 → 任何时刻都可能不一致
  │
  ├── 先更新数据库 vs 先更新缓存？
  │     ├── 先更新缓存，再更新数据库 → 缓存更新成功但DB失败 → 数据丢失 ❌
  │     ├── 先更新DB，再更新缓存 → 并发写时缓存可能是旧值 ❌
  │     └── 先更新DB，再删缓存 ← 业界主流选择 ✅
  │           但删缓存也有窗口期问题 → 延时双删方案诞生
  │
  ├── 方案演进
  │     ├── 方案1：延时双删（常规）
  │     │     删缓存 → 更新DB → sleep(N) → 再删缓存
  │     │     问题1：sleep阻塞主链路，吞吐暴跌
  │     │     问题2：sleep时间无法精确，仍可能脏数据
  │     │
  │     ├── 方案2：Canal + MQ 异步二次删（推荐）
  │     │     同步路径：删缓存 → 更新DB → 直接返回（零阻塞）
  │     │     异步路径：Canal监听binlog → MQ投递 → Consumer二次删缓存
  │     │     优势：主链路零阻塞 + MQ重试保障一致性
  │     │
  │     └── 方案3：线程池延迟队列（轻量替代）
  │           更新DB → 提交延迟删缓存任务到线程池 → 直接返回
  │           优势：代码成本低，不阻塞业务线程
  │           劣势：进程重启会丢任务，可靠性不如MQ
  │
  └── 架构权衡核心
       复杂度 ←→ 可靠保障
       方案3最简单但最不可靠
       方案2最可靠但架构最复杂
       根据业务容忍度选择

删缓存 → 更新DB → sleep(500ms) → 再删缓存

时刻1：写请求删缓存
时刻2：读请求发现缓存空，去DB读（此时DB还是旧值！因为写请求还没更新DB）
时刻3：读请求把旧值写入缓存
时刻4：写请求更新DB
→ 缓存是旧值，DB是新值，不一致！所以需要延时后再删一次。

同步路径（业务主链路，零阻塞）：
  删缓存 → 更新DB → 直接返回 ✅（50ms搞定）

异步路径（后台自动执行）：
  MySQL binlog变更
    → Canal监听到变更
    → Canal投递消息到MQ
    → MQ Consumer消费消息
    → 执行二次删缓存
    → 如果失败，MQ自动重试 ✅

更新DB → 提交延迟任务到线程池（延迟N秒后删缓存）→ 直接返回

// ScheduledExecutorService
scheduler.schedule(() -> {
    redis.del(key);
}, 500, TimeUnit.MILLISECONDS);

微服务数据一致性
  │
  ├── 核心问题：本地事务管不了跨服务
  │     单体：一个数据库 → @Transactional管全局 ✅
  │     微服务：多个独立数据库 → 本地事务只管自己库 ❌
  │     结果：部分成功部分失败 → 脏数据
  │
  ├── 典型场景：下单流程
  │     扣优惠券 ✅ → 扣积分 ✅ → 创建订单 ❌
  │     优惠券和积分扣了，订单没生成 → 用户损失
  │
  ├── 四种方案对比
  │     ├── 1. TCC（Try-Confirm-Cancel）
  │     │     强一致 · 侵入大 · 每个接口写三套逻辑
  │     │     适用：资金类、一致性极高
  │     │
  │     ├── 2. 可靠消息最终一致性（RocketMQ事务消息）
  │     │     侵入小 · 最终一致 · 只支持正向提交
  │     │     适用：通知类、新增操作
  │     │
  │     ├── 3. 最大努力通知
  │     │     不断重试通知 · 只适合通知类
  │     │     适用：支付结果通知等
  │     │
  │     └── 4. SAGA模式（本地消息表+状态机+正向/补偿接口）← 业务常用
  │           最终一致 · 每个服务提供正向+逆向补偿接口
  │           补偿必须幂等 · 补偿失败要重试
  │           适用：需要回滚已完成操作的电商场景
  │
  └── 选型原则：先分析业务，再选方案

用户下单：
  1. 优惠券服务：扣减优惠券 → 成功 ✅（已提交，不可自动回滚）
  2. 积分服务：扣减积分 → 成功 ✅（已提交，不可自动回滚）
  3. 订单服务：创建订单 → 失败 ❌（抛异常）

结果：优惠券没了，积分没了，订单也没了——用户白亏！

正常流程（正向）：
  扣优惠券 → 扣积分 → 创建订单 → 全部成功 ✅

异常流程（补偿回滚）：
  扣优惠券 ✅ → 扣积分 ✅ → 创建订单 ❌
                                    ↓
  补偿：退回积分 ← 退回优惠券
  （从失败点往前，依次补偿）

需要跨服务数据一致性？
  │
  ├── 需要回滚已完成操作？
  │     ├── 是 → 需要强一致？
  │     │     ├── 是 → TCC（资金类）
  │     │     └── 否 → SAGA（电商常用）⭐
  │     └── 否 → 只需通知下游做新增？
  │           ├── 是 → RocketMQ事务消息
  │           └── 否 → 最大努力通知

设计模式业务落地（Spring框架下）
  │
  ├── 核心认知：设计模式不是背UML图，是解决"代码腐化"问题
  │     代码腐化的信号：if-else膨胀、改一处动多处、新增功能要改老代码
  │     Spring IoC让设计模式落地更简单——自动装配替代手动创建
  │
  ├── 四大模式 + 解决的问题
  │     ├── 1. 策略模式 → 消除if-else分支（支付类型选择）
  │     │     传统：if(payType==ALIPAY)...else if(payType==WECHAT)...
  │     │     改造：Map<Enum, Strategy> + Spring自动装配
  │     │
  │     ├── 2. 防腐层 → 隔离外部接口变更（微服务远程调用）
  │     │     传统：调用方直接依赖远程接口 → 接口变更→调用方全改
  │     │     改造：适配器封装远程调用 → 变更只改适配器
  │     │
  │     ├── 3. 责任链模式 → 流程编排与扩展（商品保存流程）
  │     │     传统：硬编码调用各环节 → 新增环节要改主流程
  │     │     改造：Handler链表 + @Order排序 + Spring自动装配
  │     │
  │     └── 4. 模板方法模式 → 通用流程抽象（支付公共逻辑）
  │           传统：每个支付类重复写参数校验、日志等公共逻辑
  │           改造：抽象类封装模板方法 + 子类只实现差异化逻辑

// ❌ 传统：if-else地狱
public void pay(PaymentRequest request) {
    if (request.getPayType() == PayType.ALIPAY) {
        alipayService.pay(request);
    } else if (request.getPayType() == PayType.WECHAT) {
        wechatPayService.pay(request);
    }
    // 新增Apple Pay？又要加else if，改这个方法！
}

// 1. 定义策略接口
public interface PaymentStrategy {
    PayType getPayType();
    void pay(PaymentRequest request);
}

// 2. 各支付方式实现策略接口
@Service
public class AlipayStrategy implements PaymentStrategy {
    @Override
    public PayType getPayType() { return PayType.ALIPAY; }
    @Override
    public void pay(PaymentRequest request) { ... }
}

// 3. Spring自动装配：将所有策略实现注入Map
@Component
public class PaymentStrategyFactory implements ApplicationContextAware {
    private Map<PayType, PaymentStrategy> strategyMap;

    @Override
    public void setApplicationContext(ApplicationContext ctx) {
        Map<String, PaymentStrategy> beans = ctx.getBeansOfType(PaymentStrategy.class);
        strategyMap = beans.values().stream()
            .collect(Collectors.toMap(
                PaymentStrategy::getPayType,
                Function.identity()
            ));
    }

    public PaymentStrategy getStrategy(PayType payType) {
        return strategyMap.get(payType);
    }
}

// 4. 使用：一行代码，没有if-else！
@Service
public class PaymentService {
    @Autowired
    private PaymentStrategyFactory factory;

    public void pay(PaymentRequest request) {
        factory.getStrategy(request.getPayType()).pay(request);
        // ✅ 新增Apple Pay？只需加ApplePayStrategy类+枚举值，这里不用改！
    }
}

// ❌ 传统：直接调用远程接口
@Service
public class OrderService {
    @Autowired
    private OrderRemoteClient orderClient;

    public OrderDTO getOrder(Long orderId) {
        OrderVO vo = orderClient.getOrder(orderId);
        if (vo == null) throw new BizException("订单不存在");
        return convert(vo);  // 转换逻辑散落各处
    }
}
// 问题：OrderVO字段变了 → 所有调用方都要改convert方法！

// 1. 定义防腐层（适配器）
@Component
public class OrderServiceAdapter {
    @Autowired
    private OrderRemoteClient orderClient;

    public OrderDTO getOrder(Long orderId) {
        if (orderId == null) throw new BizException("订单ID不能为空");

        OrderVO vo = orderClient.getOrder(orderId);
        if (vo == null) throw new BizException("订单不存在");

        log.info("查询订单: {}, 结果: {}", orderId, vo.getStatus());

        return convert(vo);  // 远程接口变更时，只修改这里
    }

    private OrderDTO convert(OrderVO vo) {
        OrderDTO dto = new OrderDTO();
        dto.setOrderId(vo.getId());   // 远程接口把id改成了orderId？只改这里！
        dto.setStatus(vo.getState()); // 远程接口把status改成了state？只改这里！
        return dto;
    }
}

// 2. 调用方只依赖适配器
@Service
public class PaymentService {
    @Autowired
    private OrderServiceAdapter orderAdapter;

    public void pay(Long orderId) {
        OrderDTO order = orderAdapter.getOrder(orderId);  // 稳定的接口
    }
}

// ❌ 传统：硬编码调用各环节
public void saveProduct(Product product) {
    product.setDefaultInfo();
    validateProduct(product);
    productMapper.insert(product);
    notifyService.send(product);
    logService.log(product);
    // 新增环节？要改这个方法！
}

// 1. 定义Handler接口
public interface IHandler<T> {
    void handle(T t);
    void setNext(IHandler<T> next);
}

// 2. 抽象基类
public abstract class AbstractHandler<T> implements IHandler<T>, Ordered {
    private IHandler<T> next;

    @Override
    public void handle(T t) {
        doHandle(t);
        if (next != null) next.handle(t);
    }

    protected abstract void doHandle(T t);
}

// 3. 各环节实现类，通过@Order控制顺序
@Component
@Order(1)
public class ProductInfoHandler extends AbstractHandler<Product> {
    @Override
    protected void doHandle(Product product) {
        product.setDefaultInfo();
    }
}

@Component
@Order(2)
public class ProductValidateHandler extends AbstractHandler<Product> {
    @Override
    protected void doHandle(Product product) {
        if (product.getName() == null) throw new BizException("商品名不能为空");
    }
}

// 4. 责任链工厂：Spring自动装配 + 按Order排序 + 组装链表
@Component
public class HandlerChainFactory implements ApplicationContextAware {
    private IHandler<Product> chainHead;

    @Override
    public void setApplicationContext(ApplicationContext ctx) {
        List<AbstractHandler<Product>> handlers = ctx.getBeansOfType(AbstractHandler.class)
            .values().stream()
            .sorted(Comparator.comparingInt(AbstractHandler::getOrder))
            .collect(Collectors.toList());

        for (int i = 0; i < handlers.size() - 1; i++) {
            handlers.get(i).setNext(handlers.get(i + 1));
        }
        chainHead = handlers.get(0);
    }

    public IHandler<Product> getChain() { return chainHead; }
}

// 5. 使用：一行代码，整个链路自动执行
@Service
public class ProductService {
    @Autowired
    private HandlerChainFactory factory;

    public void saveProduct(Product product) {
        factory.getChain().handle(product);
        // ✅ 新增环节？只加Handler类+@Order注解，这里不用改！
    }
}

// 1. 定义抽象模板类
public abstract class AbstractPaymentTemplate {
    // 模板方法：定义固定流程（final防止子类重写）
    public final void pay(PaymentRequest request) {
        validate(request);        // 第1步：参数校验（公共逻辑）
        doPay(request);           // 第2步：具体支付（差异逻辑，子类实现）
        logPayment(request);      // 第3步：记日志（公共逻辑）
        notify(request);          // 第4步：发通知（公共逻辑）
    }

    private void validate(PaymentRequest request) {
        if (request.getAmount() == null || request.getAmount() <= 0) {
            throw new BizException("金额不合法");
        }
    }

    private void logPayment(PaymentRequest request) {
        log.info("支付完成: orderId={}, amount={}", request.getOrderId(), request.getAmount());
    }

    private void notify(PaymentRequest request) {
        notifyService.send(request.getOrderId());
    }

    // 差异逻辑：声明为抽象方法，子类必须实现
    protected abstract void doPay(PaymentRequest request);
}

// 2. 具体支付类：只实现差异逻辑
@Service
public class AlipayTemplate extends AbstractPaymentTemplate {
    @Override
    protected void doPay(PaymentRequest request) {
        alipayClient.pay(request);  // 只写调支付宝API的逻辑，其他不用管！
    }
}

策略模式 + 模板方法 = 完美组合
  ┌─────────────────────────────────────┐
  │  PaymentService                     │
  │    ↓ 策略模式：选哪个模板            │
  │  templateMap.get(payType).pay()     │
  │    ↓ 模板方法：执行固定流程          │
  │  validate → doPay → log → notify   │
  └─────────────────────────────────────┘

防腐层 = 外部接口的"保险丝"
  ┌──────────┐    ┌──────────┐    ┌──────────┐
  │ 调用方    │ →  │ 防腐层    │ →  │ 远程接口  │
  │ 稳定不变  │    │ 变更只改这│    │ 可能变化  │
  └──────────┘    └──────────┘    └──────────┘

责任链 = 流程的"接力赛"
  Handler1 → Handler2 → Handler3 → Handler4
  @Order(1)   @Order(2)   @Order(3)   @Order(4)
  新增环节？加一个Handler就行

IoC是什么？ → DI和IoC区别？ → Bean生命周期？ → 循环依赖怎么解决？
→ 三级缓存每级存什么？ → 三级缓存为什么支持AOP？ → AOP两种代理？
→ @Transactional底层原理？ → 事务失效场景？ → 传播行为？

一条SQL慢怎么排查？ → explain四个字段怎么看？ → 回表和覆盖索引区别？
→ 索引失效有哪些情况？ → 深分页怎么优化？ → 长事务为什么会导致锁等待？
→ 除了加索引还会啥？ → 五维调优体系？

ThreadLocal有什么问题？ → 内存泄露根因？ → 数据串读怎么发生的？
→ InheritableThreadLocal为什么线程池下失效？ → TTL怎么解决的？
→ 线程池核心线程数怎么配置？ → 执行顺序是什么？ → 四大踩坑？
→ AQS三件套是什么？ → 各锁怎么基于AQS实现？

本地事务为什么管不了跨服务？ → 四种方案怎么选？ → SAGA和TCC区别？
→ 补偿接口为什么必须幂等？ → 事务消息为什么不能回滚？