如何处理异常#

1. try-catch/多catch分支捕获（先捕获子类，再捕获父类）

2. throws（声明抛出）

   public static void readFile(String path) throws IOException, FileNotFoundException {

3. throw（手动抛出异常）

   throw new ArithmeticException("除数不能为0");

4. try-with-resources（自动关闭资源）⭐

   传统写法：try{}catch(){}finally{}

   try-with-resources：

   1
   // 单个资源
   2
   try (BufferedReader reader = new BufferedReader(new FileReader("test.txt"))) {
   3
       String line = reader.readLine();
   4
       System.out.println(line);
   5
   } catch (IOException e) {
   6
       e.printStackTrace();
   7
   }
   8
   
   9
   // 多个资源
   10
   try (
   11
       FileInputStream fis = new FileInputStream("input.txt");
   12
       FileOutputStream fos = new FileOutputStream("output.txt")
   13
   ) {
   14
       fos.write(fis.readAllBytes());
   15
   } catch (IOException e) {
   16
       e.printStackTrace();
   17
   }

   展开收起

反射#

• 反射能获取 private 字段吗

  反射可以通过getDeclaredField()获取包括private的全部字段，但需要添加field.setAccessible(true)

举例常用异常类型#

RuntimeException

• NullPointerException（空指针异常）
• ArrayIndexOutOfBoundsException（数组越界异常）
• ArithmeticException（算术异常）
• ClassCastException（类型转换异常）
• NumberFormatException（数字格式异常）
• IllegalArgumentException（非法参数异常）
• OutOfMemoryError（内存溢出错误）

Spring循环依赖及解决#

注解方式解决

@Resource和@Autowired#

事务#

三级缓存

事务失效的场景，如何处理

并发#

• 并发和并行

  • 并发，同一时间段多个线程交替执行；单核CPU支持
  • 并行，同一时刻多个线程执行；单核CPU不支持

• 多线程一定是并行吗

  不一定。多线程只是提供了多个执行流，但是否并行取决于 CPU 核心数、线程调度、任务类型等因素。比如在单核 CPU 上，多个线程只能并发交替执行；在多核 CPU 上，多个线程才可能真正并行执行。

join和left join#

SQL优化#

1. 减少不必要的select 字段，避免使用select *
2. 避免大量表join连接，较多的情况下适当根据业务进行拆分
3. 合理创建索引

索引#

• 单张表索引不超过5个

单列索引

联合索引

1
-- 联合索引：多个字段组成一个索引
2
CREATE INDEX idx_city_age_name ON users(city, age, name);
3
-- 对应的 B+Tree 结构（先按 city 排序，city 相同按 age 排序，age 相同按 name 排序）

最左前缀原则（核心）⭐⭐⭐

左侧最优先，必须自左向右有匹配到

1
Text
2
联合索引 (city, age, name) 的匹配规则：
3

4
查询条件                          是否走索引    使用了哪些列
5
─────────────────────────────────────────────────────────────
6
WHERE city = '北京'               ✅           city
7
WHERE city = '北京' AND age=25    ✅           city, age
8
WHERE city = '北京' AND age=25    ✅           city, age, name（全部）
9
  AND name = '张三'
10

11
WHERE age = 25                   ❌            跳过了city，索引失效
12
WHERE name = '张三'              ❌            跳过了city和age，索引失效
13
WHERE age = 25 AND name = '张三'  ❌            跳过了city，索引失效

1
-- ❌ 大部分情况不走索引
2
SELECT * FROM test_index WHERE age != 25;
3
SELECT * FROM test_index WHERE age NOT IN (20, 25, 30);
4
-- 但也有例外：如果 MySQL 优化器评估走索引更优时仍可能使用

1
-- 视数据分布而定
2
-- 如果 NULL 值占比很小，可能走索引
3
-- 如果大部分都是 NULL，优化器会选择全表扫描
4
SELECT*FROM test_indexWHEREnameISNULL;
5
SELECT*FROM test_indexWHEREnameIS NOT NULL;

union和union all#

数据量大优化方案#

1. 查询优化

• 禁止SELECT *，只查询需要的字段
• 避免在WHERE中对列进行函数转换（如WHERE date(create_time)='2024-01-01'），改用范围查询
• 用IN代替OR（IN值不超过500个）
• 避免ORDER BY RAND()，建议在程序中生成随机值

2. 写入优化

• 批量写操作（超100万行）要分批多次进行，避免大事务锁表
• 使用pt-online-schema-change工具修改大表结构，避免锁表
• 禁止在线上做数据库压力测试

3. 子查询与JOIN

• 避免复杂子查询，优化为JOIN操作
• JOIN关联表不超过5个，避免内存溢出

1. 分批次写入，意味着可以避免大事务锁表，但需要对失败数据特殊处理，保证后续失败的数据重试写入，保证全部成功
2. 事务包裹，意味着事务一致性，要么成功要么失败，但可能会出现锁表

• 结论分析：

  1
  两种策略的本质是：一致性 vs 性能 的权衡
  2
  
  3
  策略一：分批次写入（每批独立事务）
  4
  ├── 本质：牺牲原子性，换取短事务、短锁持有
  5
  ├── 优点：锁持有时间短，不会阻塞其他操作
  6
  ├── 代价：失败后需要重试 + 幂等保证，才能最终全部成功
  7
  └── 适用：大数据量、允许最终一致性的场景
  8
  
  9
  策略二：事务包裹（一个大事务）
  10
  ├── 本质：牺牲性能，换取强一致性
  11
  ├── 优点：要么全部成功，要么全部回滚，数据绝对一致
  12
  ├── 代价：长事务长时间持有行锁，高并发下可能导致大量阻塞
  13
  └── 适用：小数据量、要求强一致性的场景

  “这两种策略本质是一致性和性能的权衡：

  分批次写入用短事务换取性能，代价是失去原子性，需要配合失败重试 + 幂等设计来保证最终全部成功；

  事务包裹用长事务换取强一致性，代价是长时间持有行锁，数据量大时会导致大量阻塞。

  实际生产中，我会根据数据量和一致性要求来选择——小数据量强一致用事务包裹，大数据量用分批写入加重试幂等。”

• 什么是行锁，这里面什么情况是行锁，什么情况是锁表

  维度	行锁	表锁
  锁定范围	只锁定被操作的行	锁定整张表
  并发度	高（不同行互不影响）	低（同一时刻只能一个事务写）
  加锁开销	大（需要维护锁的数据结构）	小（一次性锁整表）
  死锁概率	较高（多行加锁顺序不同）	较低
  支持引擎	InnoDB	MyISAM、InnoDB（特定场景）

  锁表：

  • 条件列没走索引，where age = 25

    需要每个条件都走到索引吗？

    不需要。只要有一个索引命中即可。

  • between导致的间隙锁，WHERE age BETWEEN 20 AND 30; 导致该区间的记录被锁

• 什么是幂等和非幂等？

  SQL

  1
  -- ❌ 非幂等：重试会插入重复数据
  2
  INSERT INTO t_user (id, username) VALUES (1, '张三');
  3
  
  4
  -- ✅ 幂等：重试不会产生重复
  5
  INSERT IGNORE INTO t_user (id, username) VALUES (1, '张三');
  6
  -- 或
  7
  INSERT INTO t_user (id, username) VALUES (1, '张三')
  8
  ON DUPLICATE KEY UPDATE username = VALUES(username);

  但很多情况下id是根据函数自动生成的

  ——这会导致ignore失效，那如何保证幂等性，不重复插入？

  方案	核心思路	优点	缺点
  应用层预生成 ID	ID 生成动作提到重试循环外	简单直接	需要改造调用代码结构
  序列单独查询后固定使用	把”取值”和”使用”分离	兼容传统数据库序列	取值这一步本身也要防止被重复调用
  业务唯一键兜底	不依赖 id，依赖业务字段	最稳妥，不受 id 生成方式影响	需要额外设计并维护一个唯一索引字段

  HTTP

• 那如果业务要求的是需要一次性全部成功呢，而非部分成功（后续补充完成失败的记录）

核心思路：把”写入”和”提交”分离#

既然大事务不可行，分批写入又破坏原子性，那就把整个过程拆成两个阶段：

1
阶段一：数据准备（可以失败、可以重试、不影响生产表）
2
阶段二：原子提交（一次性、快速、要么全成功要么全回滚）

---

方案一：临时表 + 原子切换（最推荐）#

原理#

先把所有数据写入一张临时表/暂存表，这个阶段可以分批写入、可以失败重试，因为不影响生产数据。等全部数据准备完毕后，再用一个事务做原子性的 INSERT…SELECT，从临时表导入正式表。

1
-- 第一步：创建临时表（结构和正式表一致）
2
CREATE TABLE t_user_temp LIKE t_user;
3

4
-- 第二步：分批写入临时表（可以失败重试，不影响生产）
5
-- Java 代码分批 insert into t_user_temp ...
6
-- 这一步失败了直接 truncate 重来，毫无压力
7

8
-- 第三步：原子提交（一个事务，从临时表导入正式表）
9
START TRANSACTION;
10
INSERT INTO t_user SELECT * FROM t_user_temp;
11
COMMIT;
12

13
-- 第四步：清理临时表
14
TRUNCATE TABLE t_user_temp;

为什么可行？#

阶段	特点	风险
写临时表	分批写入、可重试、不影响生产	无风险，失败直接重来
原子提交	单条 INSERT…SELECT，一个事务	事务时间短，因为只是表间数据搬运

关键点：第三步的 INSERT...SELECT 虽然也是一个事务，但它只是表到表的数据搬运，不涉及网络传输、业务计算，速度非常快，即使百万级数据也能在几秒内完成，锁持有时间可控。

Java 代码示例#

1
@Service
2
public class BatchImportService {
3

4
    @Autowired
5
    private UserMapper userMapper;
6

7
    public void importAllOrNothing(List<User> userList) {
8
        // 阶段一：分批写入临时表（可重试）
9
        userMapper.createTempTable();
10
        int batchSize = 1000;
11
        for (int i = 0; i < userList.size(); i += batchSize) {
12
            List<User> batch = userList.subList(i, Math.min(i + batchSize, userList.size()));
13
            userMapper.batchInsertTemp(batch);  // 写入临时表
14
        }
15

16
        // 校验：临时表数据量是否等于源数据量
17
        int tempCount = userMapper.countTempTable();
18
        if (tempCount != userList.size()) {
19
            userMapper.truncateTempTable();
20
            throw new RuntimeException("数据准备不完整，已回滚");
21
        }
22

23
        // 阶段二：原子提交（一个事务）
24
        userMapper.atomicCopyFromTemp();  // INSERT INTO t_user SELECT * FROM t_user_temp
25

26
        // 清理
27
        userMapper.truncateTempTable();
28
    }
29
}

展开收起

1
<!-- 原子提交：一个事务完成 -->
2
<insert id="atomicCopyFromTemp">
3
    INSERT INTO t_user (username, age, email)
4
    SELECT username, age, email FROM t_user_temp
5
</insert>

---

方案二：预校验 + 事务包裹#

原理#

大事务之所以危险，很大程度是因为中途失败导致长时间持有锁后还要回滚。如果能在进入事务前把所有可能失败的因素排除掉，事务本身就会非常快。

1
@Service
2
public class BatchImportService {
3

4
    @Transactional(rollbackFor = Exception.class)
5
    public void importWithPreCheck(List<User> userList) {
6
        // 阶段一：预校验（事务外完成，这里只是举例）
7
        // - 检查主键是否冲突
8
        // - 检查外键引用是否存在
9
        // - 检查字段格式是否合法
10
        preValidate(userList);
11

12
        // 阶段二：事务内快速写入（因为已排除失败因素，几乎不会失败）
13
        int batchSize = 1000;
14
        for (int i = 0; i < userList.size(); i += batchSize) {
15
            List<User> batch = userList.subList(i, Math.min(i + batchSize, userList.size()));
16
            userMapper.batchInsertUsers(batch);
17
        }
18
    }
19

20
    private void preValidate(List<User> userList) {
21
        // 批量查询已存在的主键，检查冲突
22
        Set<Long> existingIds = userMapper.findExistingIds(
23
            userList.stream().map(User::getId).collect(Collectors.toList())
24
        );
25
        for (User user : userList) {
26
            if (existingIds.contains(user.getId())) {
27
                throw new BusinessException("主键冲突: " + user.getId());
28
            }
29
            // 其他校验...
30
        }
31
    }
32
}

展开收起

适用场景：数据量中等（几万到十几万条），失败原因主要是数据本身的问题（主键冲突、格式错误等）。

---

方案三：Seata 分布式事务（微服务场景）#

你的笔记里提到了 Seata，如果涉及跨库、跨服务的原子性，就需要分布式事务框架。

flowchart LR A[订单服务] -->|Try: 预留资源| B[库存服务] A -->|Try: 预留资源| C[账户服务] B -->|Confirm: 确认扣减| D[完成] C -->|Confirm: 确认扣减| D B -.->|Cancel: 回滚| E[失败回滚] C -.->|Cancel: 回滚| E

Seata 有几种模式：

模式	原理	适用场景
AT 模式	自动生成回滚SQL，对业务无侵入	单体应用跨库、大多数场景
TCC 模式	手写 Try/Confirm/Cancel 三个方法	高性能、跨服务
Saga 模式	长事务，通过补偿回滚	流程长的业务
XA 模式	数据库原生XA协议	强一致性要求极高

---

方案四：Saga 补偿事务（长流程场景）#

如果流程很长（比如订单 → 扣库存 → 扣余额 → 生成物流），不适合用一个事务包裹，可以用 Saga 模式：

1
正向流程：  创建订单 → 扣库存 → 扣余额 → 生成物流
2
                    ↓ 某步失败
3
补偿流程：  取消订单 ← 恢复库存 ← 恢复余额

每一步都是独立事务，失败时按反序执行补偿操作。不是数据库层面的回滚，而是业务层面的补偿。

---

总结对比#

方案	原子性	性能	复杂度	适用场景
临时表 + 原子切换	✅ 强	✅ 好	中	单表大数据量导入（最推荐）
预校验 + 事务包裹	✅ 强	⚠️ 中等	低	中等数据量、失败原因可预判
Seata AT/TCC	✅ 强	⚠️ 中等	高	跨库跨服务
Saga 补偿	✅ 最终一致	✅ 好	高	长流程业务

---

• 关于其重试机制

  1
  重试机制设计
  2
  ├── 1. 什么时候重试？（触发条件）
  3
  ├── 2. 重试几次？（次数限制）
  4
  ├── 3. 每次间隔多久？（退避策略）
  5
  ├── 4. 重试时如何避免重复数据？（幂等保证）
  6
  └── 5. 全部失败后怎么办？（兜底处理）

OpenFeign#

声明式 HTTP 客户端，用接口方式调用远程服务

1
<dependency>
2
    <groupId>org.springframework.cloud</groupId>
3
    <artifactId>spring-cloud-starter-openfeign</artifactId>
4
</dependency>

• EnableFeignClients
• FeignClient

生产上对数据库数据问题如何排查#

1
生产数据问题
2
├── 1. 数据丢失（记录莫名消失）
3
├── 2. 数据错误（字段值不对）
4
├── 3. 数据重复（脏数据）
5
├── 4. 数据不一致（多表/多系统间数据对不上）
6
├── 5. 性能问题（慢查询、死锁）
7
└── 6. 数据库连接问题（连接池耗尽、超时）

如何处理Git冲突#

ry-with-resource