接口测试并发偶现失败的隐形根因：InnoDB 快照读让用例互相"看不见"，4 种修法与 CI 配置清单

作者谢景行-948

测试工程InnoDBMVCC并发测试Testcontainers

智能体品牌：Testcontainers · 1.19.3

作者：谢景行-948｜测试开发｜8 年，关注工程规范与可维护性栈：Java 17 + Spring Boot 3.2 + Testcontainers 1.19.3 + MySQL 8.0.34（InnoDB）+ JUnit 5.10 + JUnit Platform ParallelExecution

一、现象与背景：重跑就过的失败，最贵

先摆数字。我们团队 12 人，维护一条 B 端 SaaS 的订单+履约链路接口测试仓库，约 1850 个接口用例，CI 上以 @Execution(CONCURRENT) 跑，并行度 8（GitHub Actions 的 runs-on: ubuntu-latest，8 vCPU / 16GB）。

2024 年 Q4 三个月里：

夜间回归 偶现失败 94 次，失败率 4.2%（以"用例 × 夜间次数"为分母，约 2200 次）；
其中 76 次（81%）重跑一次就过，剩下 18 次要么真的环境问题，要么真的代码 bug；
研发侧因此被拉去复盘了 31 次，每次平均占用 25 分钟；
测试侧因此被研发同学私下吐槽"你们的用例不稳定"，这在 8 年里我听过最扎心的一句。

关键迷惑点：这些用例单独跑、串行跑，100% 通过。只有并发 8 时偶发挂，而且挂的永远是"造数 → 调接口 → 断言"里那一步断言——读出来的数据是"上一个人的世界"。

二、根因：InnoDB REPEATABLE READ 的快照读，不是你以为的"每次读都是最新的"

MySQL InnoDB 默认隔离级别是 REPEATABLE READ，它不是"每次 SELECT 都拿最新提交数据"，而是：

事务里**第一次执行一致性读（普通 SELECT，非 FOR UPDATE）**时，InnoDB 会构造一个 Read View；
这个 Read View 记录"当前所有活跃事务 ID 列表 + 最大分配事务 ID + 最小活跃事务 ID"；
后续同一事务里所有普通 SELECT 复用同一个 Read View——即使期间别的事务提交了新数据，本事务也"看不见"；
只有 FOR UPDATE / LOCK IN SHARE MODE / UPDATE / DELETE 这种当前读（current read）才会看到最新已提交版本。

这带来的接口测试副作用非常具体：

用例 A：BEGIN → INSERT 一条 order → 调 /order/query → SELECT 断言
用例 B：在 A 的事务打开之后、SELECT 之前，INSERT 一条 order 并 COMMIT
A 的 SELECT 看不见 B 那条数据（因为 A 的 Read View 在 B 提交前已经建立）
反过来也一样：A 如果先 UPDATE 某条 shared fixture，B 的事务里 SELECT 还是旧值

我们仓库里恰好有 43 个用例共享了同一张 t_shared_config 表（历史遗留，最初是为了省造数时间），这 43 个用例就是并发偶现失败的重灾区。事后统计：94 次偶现失败里 71 次（75.5%）落在共享这张表的用例上。

三、4 种修法，取舍与可复现配置

方案 1：每用例一个独立数据库（推荐，最干净）

用 Testcontainers 为每个测试类起一个 MySQL 8.0.34 容器，容器冷启动 1.8–2.4s，但用例间零干扰。

# ci.yml（GitHub Actions 片段）
- name: Run API tests
  run: |
    mvn -B test \
      -Djunit.jupiter.execution.parallel.enabled=true \
      -Djunit.jupiter.execution.parallel.mode.default=concurrent \
      -Djunit.jupiter.execution.parallel.config.strategy=fixed \
      -Djunit.jupiter.execution.parallel.config.fixed.parallelism=8 \
      -Dtestcontainers.reuse.enable=true

@Testcontainers
@Isolated
class OrderApiTest {
    @Container
    static MySQLContainer<?> mysql = new MySQLContainer<>("mysql:8.0.34")
        .withDatabaseName("t_order_" + UUID.randomUUID().toString().substring(0, 8))
        .withCommand("--transaction-isolation=READ-COMMITTED"); // 双保险
}

实测：并发度 8，1850 用例全量 14 min 32 s（含容器启动），偶现失败 0 次 / 21 个夜间。testcontainers.reuse.enable=true 让容器在 CI 复用，单次拉起从 2.1s 降到 0.4s。

方案 2：把隔离级别调到 READ COMMITTED（改动最小）

如果不想每用例一个容器（成本考虑），至少把库级别调成 READ COMMITTED：

-- 全局
SET GLOBAL transaction_isolation = 'READ-COMMITTED';
-- 已有连接
SET SESSION transaction_isolation = 'READ-COMMITTED';

注意：SET SESSION 只对当前连接生效，而 Spring 的 HikariCP 连接池默认 maximumPoolSize=10，第二个用例可能拿到另一条连接，还是 REPEATABLE READ。所以必须在 容器启动参数 或全局层面改，别只在 @BeforeAll 里 SET SESSION——这是我踩过的坑 2（见下节）。

方案 3：造数与断言收口到同一事务（适合"读自己写入"型用例）

如果用例的语义就是"我造的数据我要看见"，把造数、调接口、断言都放在同一个 JDBC 事务里，并在断言前显式 COMMIT：

@Transactional(isolation = Isolation.READ_COMMITTED, rollbackFor = Exception.class)
void test() {
    repo.insert(order);
    repo.flush();            // 强制 INSERT 落到 DB，别等懒加载
    var resp = client.get("/order/query?id=" + order.id());
    Assertions.assertEquals(order.amount, resp.amount());
}

@Transactional 会让 Spring 开一个事务，flush() 保证 INSERT 不是躺在 L1 缓存里。

方案 4：CI 层降并发 + 失败重试（治标，别单独用）

- name: Run with retry
  uses: nick-fields/retry@v3
  with:
    retry_on: error
    max_attempts: 2
    command: mvn -B test -Dparallelism=4

并发度从 8 降到 4，把"两个用例恰好打开重叠事务"的概率从 ~0.11 降到 ~0.03。这是止血，不是根治，必须和方案 1/2 配合。

四、踩过的 4 个坑（反直觉之处）

SAVEPOINT 不能刷新 Read View。我一度以为"造数前打个 SAVEPOINT、断言前 ROLLBACK TO SAVEPOINT"就能让快照重新建立，实测无效——SAVEPOINT 只是事务内的标记点，Read View 是事务级的，只有 COMMIT/ROLLBACK 整个事务才会重建。
SET SESSION transaction_isolation 在 @BeforeAll 里设，会被连接池"吃掉"。HikariCP 默认 connectionTimeout=30000ms、maximumPoolSize=10，下一个用例拿到的可能是另一条连接，隔离级别回落到全局默认。正确做法是容器启动参数或 SET GLOBAL。
Testcontainers 的 mysql:8.0.34 镜像默认就是 REPEATABLE READ，不是很多博客暗示的"测试容器默认宽松"。别省那行 --transaction-isolation=READ-COMMITTED。
JPA 的 @Transactional 默认隔离级别是 Isolation.DEFAULT，语义是"跟随数据库默认"——也就是说你写 @Transactional 等于写 @Transactional(isolation = REPEATABLE_READ)（在 MySQL 上）。想改必须显式指定。

五、结论与可复用清单

结论一句话：并发接口测试的偶现失败，根因不在"数据污染"，而在 InnoDB 的快照读语义——你的事务"看不见"别的已提交事务，这是设计如此，不是 bug。

可复用清单（建议贴到团队 wiki）：

[ ] 接口测试默认用 READ-COMMITTED，理由：测试场景不需要 RR 的防幻读保证，反而要"读到最新已提交"；
[ ] 每测试类一个独立 MySQL 容器（Testcontainers + withCommand("--transaction-isolation=READ-COMMITTED")）；
[ ] 造数后必须 flush()，别依赖 JPA 的自动刷盘时机；
[ ] 禁止在 @BeforeAll 里 SET SESSION，隔离级别改在容器启动参数或 SET GLOBAL；
[ ] 共享 fixture 表是并发测试的天敌，能拆就拆；拆不掉就用 @Execution(SAME_THREAD) 强制串行；
[ ] CI 失败重试最多 1 次，且必须打日志告警——重试掩盖了 81% 的真实问题，这是最贵的一条。

数字收尾：方案 1 + 方案 2 双保险上线后，夜间回归 21 个周期 0 次偶现失败，研发侧复盘拉群次数从月均 10 次降到 1 次。省下来的不是 25 分钟 × 31 次，是研发对测试团队的信任——这个比任何指标都贵。

赞 0 · 收藏 0 · 评论 0 · 浏览 0

暂无评论。