serializable隔离级别通过将select转为lock in share mode、写操作加排他锁及范围查询使用临键锁来强制串行，导致阻塞、超时与事务排队；需用显式加锁和并发场景验证锁等待与失败率。

在 JDBC 中测试 MySQL 的 SERIALIZABLE 隔离级别，核心是验证它如何通过加锁机制强制串行执行，从而暴露明显的性能开销——比如阻塞、等待超时、事务排队。这不是单纯“设个参数就能跑”，而要设计能触发锁冲突的并发场景。

明确 SERIALIZABLE 在 MySQL 中的真实行为

MySQL 的 SERIALIZABLE 并非完全模拟“单线程执行”，而是将所有普通 SELECT 自动转为 SELECT ... LOCK IN SHARE MODE（读共享锁），写操作加排他锁，且范围查询会锁住间隙（gap lock）。这意味着：

• 两个并发事务同时查同一行，可能不冲突；但一个查、一个改同一行，后者会被阻塞
• 即使只查不改，若涉及范围条件（如 WHERE id BETWEEN 1 AND 10），InnoDB 会加临键锁（next-key lock），导致插入新记录也被阻塞
• 锁持有时间延长至事务结束（COMMIT/ROLLBACK），不是语句结束

用 JDBC 构建可复现的阻塞测试

关键不是“测速度”，而是观察阻塞是否发生、等待多久、是否超时。推荐以下最小闭环测试：

Alibabacloud Sdk Client Initialization For Java

在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。

下载

• 准备一张简单表：CREATE TABLE test_lock (id INT PRIMARY KEY, val VARCHAR(10)) ENGINE=InnoDB; 插入几条数据（如 (1,'a'),(2,'b'),(3,'c')）
• 在两个独立线程中，分别用 Connection.setTransactionIsolation(Connection.TRANSACTION_SERIALIZABLE) 设置隔离级别
• 线程 A：开启事务 → 执行 SELECT * FROM test_lock WHERE id = 2 FOR UPDATE（显式加锁更易观察）→ Thread.sleep(5000) → COMMIT
• 线程 B：开启事务 → 立即执行同样 SELECT ... FOR UPDATE 或 UPDATE test_lock SET val='x' WHERE id = 2
• 观察线程 B 是否卡住，以及是否抛出 SQLException（如 Lock wait timeout exceeded）

量化开销：不只是“慢”，而是“等”和“失败”

SERIALIZABLE 的开销主要体现在：

• 锁等待时间：用 System.nanoTime() 记录线程 B 从执行 SQL 到返回/抛异常的时间差
• 超时率：把 wait_timeout 或 JDBC 的 socketTimeout 设为 2 秒，反复运行 100 次，统计失败比例
• 并发吞吐断崖下降：用 JMeter 或自写多线程循环，对比 RC 和 SERIALIZABLE 下每秒成功事务数（TPS）——通常 SERIALIZABLE 会降到 RC 的 1/5 甚至更低

避免常见误区

直接用 SELECT * 测试 SERIALIZABLE 很难看到效果，因为：

• MySQL 默认可重复读（RR）下，快照读（普通 SELECT）本就不加锁；SERIALIZABLE 虽转为带锁读，但若无并发写，不会暴露阻塞
• 没关自动提交（conn.setAutoCommit(false)）会导致每个 SQL 自成事务，锁瞬间释放，测不出持续阻塞
• 没指定主键或索引条件，可能升级为表锁，结果失真（应确保查询走索引）

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南